Zero exit code returned when vulnerability detected

[washeck]

Checklist

• I agree to the terms within the Safety Code of Conduct.
• I have searched existing issues to ensure this bug hasn't been reported before.

Safety version

3.7.0

Python version

I am using the binary installation of safety so python version should not matter (but it is 3.13 in our project)

Operating System

Docker image based on Debian 12.12

Bug description

When I run safety scan, it finds a vulnerability but returns zero exit code.

Steps to reproduce

$ safety --disable-optional-telemetry --key XXXXX scan /myproject --output screen
Safety 3.7.0 scanning /myproject/app/projectname
2025-11-07 08:48:04 UTC

Account: API key used
 Git branch: master
 Environment: Stage.development
 Scan policy: None, using Safety CLI default policies

Python detected. Found 1 Python pyproject.toml file and 1 Python environment

Dependency vulnerabilities detected:

📝 pyproject.toml:

 django==5.1.13 [2 vulnerabilities found]                                                                                                                                                
  -> Vuln ID 81269:                                                                                                                                                                      
     CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow ...                                                                   
  -> Vuln ID 81270:                                                                                                                                                                      
     CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input ...                                                                   
 Update django==5.1.13 to django==5.1.14 to fix 2 vulnerabilities                                                                                                                        
 Versions of django with no known vulnerabilities: 6.0b1, 6.0a1, 5.2.8, 4.2.26                                                                                                           
 Learn more: https://data.safetycli.com/p/pypi/django/eda/?from=5.1.13&to=5.1.14                                                                                                         

✅ .venv/pyvenv.cfg: No issues found.

Tested 349 dependencies for security issues using default Safety CLI policies
11 vulnerabilities found, 9 ignored due to policy.
1 fix suggested, resolving 2 vulnerabilities.

$ echo ?
0

Additional context

No response

[github-actions]

Hi @washeck, thank you for opening this issue!

We appreciate your effort in reporting this. Our team will review it and get back to you soon.
If you have any additional details or updates, feel free to add them to this issue.

Note: If this is a serious security issue that could impact the security of Safety CLI users, please email security@safetycli.com immediately.

Thank you for contributing to Safety CLI!

[jmccreight]

I have this same issue. Just spent an hour trying to figure out what is going on here. I wrote a custom parser to get the correct behavoir. Caveat emptor but better than the bug ATM

check_vulnerabilities() {
    local output="$1"
    local summary=$(echo "$output" | grep -E '[0-9]+ vulnerabilit.* found, [0-9]+ ignored')
    if [ -z "$summary" ]; then
        # No summary line found means no vulnerabilities
        return 0
    fi
    local found=$(echo "$summary" | grep -oE '^[0-9]+')
    local ignored=$(echo "$summary" | grep -oE '[0-9]+ ignored' | grep -oE '[0-9]+')
    found=${found:-0}
    ignored=${ignored:-0}
    local unignored=$((found - ignored))
    if [ "$unignored" -gt 0 ]; then
        return 1
    fi
    return 0
}

   CONDA_OUTPUT=$(python -m safety --stage cicd scan --target "$CONDA_SCAN_DIR" | tee >(cat - >&5))
    echo ""

    if check_vulnerabilities "$CONDA_OUTPUT"; then

[jmccreight]

I really cant believe that this bug has been open for 5 months. I was about to email your team because, False negatives ARE a potential "serious security issue", at least for anyone relying on accurate return values to detect security vulnerabilities in an automated fashion. That appears to be an intended application, I'm sure a good chunk of your "used by" repos are in that boat.

But I dont need to email you, you've already seen the issue.

I picked up "safety" this afternoon, to discover a bug for my intended purposes that has been open for quite a while. Not inspiring me to keep using it. Hopefully, I'm misunderstanding something.

For completness, part of my code:

CONDA_OUTPUT=$(safety scan --target "$CONDA_SCAN_DIR" 2>&1)
ret=$?
echo "$CONDA_OUTPUT"
echo "return value: $ret"

and its output:

Safety 3.6.2 scanning /private/var/folders/rf/pj_9dt9x55b9gfnv34f3xktc0000gn/T/tmp.1IrvUYdKLi
2026-03-30 22:38:47 UTC

Account: API key used
Project: tmp-1irvuydkli
 Environment: Stage.development
 Scan policy: fetched from Safety Platform, ignoring any local Safety CLI policy files

Python detected. Found 1 Python requirement file

Dependency vulnerabilities detected:

📝 requirements.txt:

 cryptography==46.0.5 [1 vulnerability found]                                                                                                                                              
  -> Vuln ID 90749:                                                                                                                                                                        
     Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incompl...                                                                     
 Update cryptography==46.0.5 to cryptography==46.0.6 to fix 1 vulnerability                                                                                                                
 Learn more: https://data.safetycli.com/p/pypi/cryptography/eda/?from=46.0.5&to=46.0.6                                                                                                     

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Apply Fixes
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Run `safety scan --apply-fixes` to update these packages and fix these vulnerabilities. Documentation, limitations, and configurations for applying automated fixes: 
https://docs.safetycli.com/safety-docs/vulnerability-remediation/applying-fixes

Alternatively, use your package manager to update packages to their secure versions. Always check for breaking changes when updating packages.
Tip: For more detailed output on each vulnerability, add the `--detailed-output` flag to safety scan.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Tested 404 dependencies for security issues using policy fetched from Safety Platform
1 vulnerability found, 0 ignored due to policy.
1 fix suggested, resolving 1 vulnerabilities.

Project dashboard: https://platform.safetycli.com/codebases/tmp-1irvuydkli/findings?branch=feat_precommit_safety
return value: 0

[washeck]

@jmccreight This project is unfixable. I reported a few bugs here and it's always pain. Whats even worse, even though we pay for Safety, it just does not report the vulnerabilities so I fix company projects based on Github advisories from my pet projects.

Fortunatelly, Astral is adding uv audit command, so once it is stabilized, we will just stop using this project.

(to stay on topic: we had to add parsing of the safety scan text output to our CI due to the status code bug)

[yeisonvargasf]

Hey @washeck, apologies for the delayed response here.

Looking at your scan output, I can see the issue:

Scan policy: None, using Safety CLI default policies

The safety scan is designed to work with a policy file that defines how findings are handled, including which severities affect the exit code. When running without a configured policy, the default behavior may not match your expectations.

That said, I completely understand why this feels broken — if the CLI finds vulnerabilities and prints them to the screen, a zero exit code is confusing regardless of policy configuration. So I'm going to review and change the default exit code behavior when no policy file is present, so that it does the intuitive thing out of the box.

In the meantime, setting up a scan policy (locally or via Safety Platform - Platform one overrides local one) will give you full control over severity thresholds and exit code behavior.

Appreciate the report and the patience.

[yeisonvargasf]

Hey @jmccreight,

The cryptography vulnerability (Vuln ID 90749) is classified as LOW severity — you can check the details at https://getsafety.com/vulnerabilities/90749

The exit code behavior is controlled by your scan policy, specifically the fail-scan-with-exit-code settings, which define the minimum severity and CVSS thresholds that trigger a non-zero exit code. If your policy isn't configured to fail on LOW severity findings, that would explain the exit code 0 despite the vulnerability showing in the output.

I'd recommend reviewing your fail-scan-with-exit-code values — the policy file structure is documented here: https://docs.safetycli.com/safety-docs/administration/safety-policy-files#safety-policy-file-structure

Note that Safety Platform policies override local ones, so make sure you're checking the right one. If you're using Platform, you should go to https://platform.safetycli.com/organization/policies

The default threshold skips LOW severity findings because many users prefer less noise in CI, but you can adjust it to suit your requirements.

Let me know if you need help with the policy setup.