I audited my own security tool for every place it said "you're safe" when you weren't. I found 10.

I maintain depquiet, an open-source (MIT) triage layer for pip-audit, uv audit and npm audit. It drops the alerts that only reach your dev tooling and tells you which of the rest you can actually fix.

A triage tool has one job it must never get wrong: it must not hide a real alert. So this week I went through every feature with one question: where can depquiet say "you're protected" or "this doesn't matter" when that isn't true?

I found 10 places. All are fixed in v0.40.4. Here they are, because if you build security tooling, you probably have some of the same.

1. --fail-on high let every Python alert through

pip-audit and uv audit report no severity. depquiet filled the gap with a placeholder, moderate, and then compared that placeholder against --fail-on high as if a scanner had measured it. On a real project (pallets/flask), two ACTION alerts: exit 1 without the flag, exit 0 with --fail-on high. And the README recommended --fail-on high.

Now an alert with no severity counts as meeting any threshold, with a note on stderr.

2. The same placeholder was shown everywhere

Even after the gate fix, "moderate" still appeared in the terminal, the Job Summary, the HTML report, the JSON, GitHub annotations, SARIF and the exported SBOM's CycloneDX ratings. SARIF marked those alerts as warning, so code scanning merge protection set to block on errors let them through.

Now it says unknown everywhere, and an ACTION alert with no severity is a SARIF error.

3. --fix "fixed" vulnerabilities by installing into the wrong environment

In a uv project scanned with pip-audit, --fix ran pip install pkg==fix with depquiet's own interpreter. The project's uv.lock did not change, and the report said ✅ Fixed.

Now it runs uv lock --upgrade-package and says what blocks the fix when uv refuses. Python projects without a lockfile are never pip-installed; you get the requirement to raise instead.

4. --license checked depquiet's environment, not your project

For Python, the license scan listed what pip list saw where depquiet runs. On flask it reported 187 packages, including playwright, pytest and depquiet itself. A GPL dependency of your project that was not installed next to depquiet was never read, and the check could PASS.

Now it reads your lockfile (78 packages on flask, matching its uv.lock) and each license from your own virtualenv or PyPI for that exact version. An unread license is UNKNOWN and fails.

5. --kev never matched uv audit findings

The CISA KEV catalog lists CVE ids. uv audit names advisories by GHSA id and pip-audit by PYSEC or GHSA, with the CVE as an alias, and depquiet dropped the aliases. So an actively exploited vulnerability in a dev-only package was never escalated.

Now aliases are kept and KEV matches any of them.

6. A comment turned a policy rule into "filter everything"

action: filter match: severity: [low, info] # noise only 

The trailing comment broke the list, the severity condition was dropped, and the rule filtered a critical alert with EPSS 0.9. The same happened with a typo (severty:), an unreadable epss_below, and severity: medium, the value my own README documented (internally it is moderate).

Now comments are stripped, medium means moderate, and a rule with anything unreadable is skipped with a warning instead of widening.

7. Temporary suppressions became permanent

In .depquiet-ignore, expires: 2025-06-01 # temp, 2025/06/01 or 2025-13-01 was read as "no expiry". Now an unreadable date counts as expired.

8. .depquiet.yaml slips weakened the scan

kev: true # exploited turned KEV off. always_flag: [lodash] # core left lodash unprotected. epss_threshold: 5 (meant as 5%) was accepted, which filters every alert with an EPSS score. Now comments are stripped, EPSS must be between 0 and 1, and unknown keys are reported.

9. Fix versions from the wrong release line

Scanners list every release line that has the fix (0.3.81, 1.2.22). depquiet took the first one listed, which could be older than what you have installed. Now it takes the nearest fix above your version.

10. The PR comment cleanup deleted human comments

The GitHub Action removed any PR comment starting with "## 🔍 depquiet", whoever wrote it. Now it only removes its own.

And one number I had to correct

Two days ago I published that 54% of the fixes scanners suggest can't be installed. That was an upper bound: my first run checked only one fix per package. The exact per-alert figure, on 18 public uv projects, is 502 of 991 (51%). The more useful finding came with it: in 58 of the 72 blocked upgrades (81%), the blocker is a pin in the project's own pyproject.toml. "Update to X" usually really means "widen your own pin". Data, script and every resolver message.

The pattern

Almost every bug had the same shape: a missing or unreadable value was replaced by a default that sounded safe. "No severity" became "moderate". "Unreadable date" became "no expiry". "Unknown key" became "no condition". "Not installed here" became "not a dependency".

The fix was the same each time: when the tool doesn't know, it has to say so, and treat "unknown" as the risky case, never the safe one.

If you build security tooling, it's worth grepping for your defaults.

pip install depquiet, or the GitHub Action samuelrojas-dev/depquiet@v0. Issues and disagreements welcome: github.com/samuelrojas-dev/depquiet.