Context
AG009 (known vulnerable dependency) was removed — see docs/RULE_IDS.md for the retirement record. It bundled three hand-maintained advisories and read only requirements*.txt and package.json. Measured across five real agent projects (browser-use, langgraph, modelcontextprotocol/python-sdk, openai-agents-python, crewAI — 4,750 files) it fired zero times.
Two honest options existed: maintain a real advisory database, or delegate. Delegating was chosen. A stale, near-empty vulnerability database invites false confidence, and maintaining a real one is a data-operations commitment this project has not made.
But users still want one report. Losing dependency findings from the SARIF that goes to GitHub code scanning is a real regression in unified reporting, even though the rule itself was worthless.
Proposed shape (not yet implemented)
Detect pip-audit and osv-scanner on PATH. When present, invoke them, parse their output, and normalise into Finding so they flow through the existing JSON/Markdown/SARIF reporters unchanged.
This keeps unified reporting without owning advisory data.
Constraints
- No new runtime dependency. Subprocess invocation and
json parsing only. If a tool is absent, say so in the report and carry on — never fail the scan for a missing optional tool.
- New rule IDs.
AG009 is retired permanently and must not be reused (docs/RULE_IDS.md). Allocate fresh IDs, likely one per source tool.
- The scan-completeness invariant applies. If an external tool is invoked and fails, that is a scan error:
ScanResult.completed must go false and the exit code must be 2. A dependency scanner that silently failed would be exactly the false confidence this removal was meant to avoid.
- Untrusted input still. The scanned repository must not be able to influence which binary is invoked or with what arguments.
- Needs corpus coverage in
tests/corpus/ before any accuracy claim reaches the README.
Out of scope
Owning, vendoring, or shipping advisory data in any form.
Context
AG009(known vulnerable dependency) was removed — seedocs/RULE_IDS.mdfor the retirement record. It bundled three hand-maintained advisories and read onlyrequirements*.txtandpackage.json. Measured across five real agent projects (browser-use, langgraph, modelcontextprotocol/python-sdk, openai-agents-python, crewAI — 4,750 files) it fired zero times.Two honest options existed: maintain a real advisory database, or delegate. Delegating was chosen. A stale, near-empty vulnerability database invites false confidence, and maintaining a real one is a data-operations commitment this project has not made.
But users still want one report. Losing dependency findings from the SARIF that goes to GitHub code scanning is a real regression in unified reporting, even though the rule itself was worthless.
Proposed shape (not yet implemented)
Detect
pip-auditandosv-scanneronPATH. When present, invoke them, parse their output, and normalise intoFindingso they flow through the existing JSON/Markdown/SARIF reporters unchanged.This keeps unified reporting without owning advisory data.
Constraints
jsonparsing only. If a tool is absent, say so in the report and carry on — never fail the scan for a missing optional tool.AG009is retired permanently and must not be reused (docs/RULE_IDS.md). Allocate fresh IDs, likely one per source tool.ScanResult.completedmust go false and the exit code must be 2. A dependency scanner that silently failed would be exactly the false confidence this removal was meant to avoid.tests/corpus/before any accuracy claim reaches the README.Out of scope
Owning, vendoring, or shipping advisory data in any form.