Known CVEs vs Zero-Day Candidates: What CA9 Should Find
How CA9 separates reachable known Python CVEs today and how a defensive agent can surface unknown vulnerability candidates in owned code.
Key points
- CA9 catches known dependency CVEs by proving whether vulnerable packages, submodules, and covered paths are used.
- Unknown vulnerability discovery needs a different workflow: source-to-sink analysis, code review evidence, and defensive patch suggestions.
- A useful agent should report vulnerability candidates with confidence and context, not claim that every suspicious pattern is exploitable.
What CA9 catches today
CA9 starts with known vulnerability data from scanners such as Snyk, Dependabot, Trivy, pip-audit, and OSV.dev. It then checks the Python repository to decide whether the affected dependency is actually reachable.
That means CA9 is strongest when a team already has CVE data but does not know which alerts deserve immediate engineering time.
- Reachable CVEs where the affected package is imported.
- Vulnerable submodules that appear in application imports.
- Runtime-covered code paths backed by coverage data.
- Installed but unused dependencies that can be documented as false positives.
Why zero-day candidates are different
A zero-day candidate is not a database match. It is a suspicious behavior in owned code that may become a vulnerability after review, reproduction, and patching.
For Python applications, useful signals include user-controlled input flowing into dangerous sinks, missing authorization checks, unsafe file handling, insecure deserialization, SSRF-prone URL fetches, and command execution paths.
What a defensive agent should produce
The agent should behave like a security reviewer for authorized repositories. It needs to connect entry points, data flows, sanitizers, sinks, tests, and ownership context before it raises an issue.
The output should be evidence-first: file paths, functions, reachable routes or jobs, why the candidate matters, and a defensive fix path for maintainers.
- Candidate vulnerability class and confidence.
- Reachability evidence from route, job, or call graph context.
- Patch suggestion and regression test idea.
- Clear assumptions so reviewers can reject weak findings quickly.
The combined CA9 workflow
Known CVE reachability and unknown vulnerability discovery belong in the same queue, but they should stay separate in the evidence model.
CA9 can keep known CVEs grounded in scanner reports while a CA9 Agent surfaces defensive vulnerability candidates from first-party code review. Together, they answer both questions teams care about: which known alerts are real, and what risky code has not reached a CVE database yet?