No. Software of any size contains flaws nobody has found yet, and new advisories arrive for old code every day. A viable goal is narrower: no known exploited vulnerabilities, no reachable high-risk flaws left open past a set deadline, and clear statements for everything else.
Why is zero not achievable?
Because "zero" depends on what you know. A scanner can only report flaws that have been published. Dependencies you did not choose bring in code you did not write. Yesterday's clean report can be wrong tomorrow without a line of your code changing, since the advisory database changed.
CISA's Secure by Design guidance does not promise zero either. It asks manufacturers to take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. Those are commitments about behavior, not claims of perfection.
What target works instead?
Three measurable ones.
Zero known exploited vulnerabilities in what you ship or run. The CISA Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation. It is a short, concrete list, and matching your inventory against it is achievable.
A deadline for reachable flaws. Set a time to fix for findings where vulnerable code is actually called. EPSS adds a daily estimate of the probability a CVE is exploited in the next 30 days, which helps you order the rest.
An honest status for everything else. CISA's VEX minimum requirements describe a way to say whether a product is affected by a given vulnerability. "Not affected" with a reason is a legitimate answer, and it saves customers wasted effort.
What is the path?
Reduce what you carry. Every dependency is exposure, so remove unused ones and prefer fewer, well-maintained ones. Keep an SBOM per build so you can see what you ship. Automate the fix for the routine cases, and keep your base images and build tools current.
Then publish status. A customer who receives "we have 40 open findings" cannot judge risk. A customer who receives "zero known exploited, three reachable and scheduled, thirty seven not affected, with reasons" can.
Constructed example: a team scans its main service and gets 212 findings. Matching against KEV leaves one. Reachability analysis shows nine of the rest are called in the application. The team fixes the KEV item and the nine within its deadline, writes not-affected statements for the other 202 with the reason for each, and reports the number to leadership as "known exploited: 0, reachable open: 0, not affected: 202". Nobody claims zero vulnerabilities, and the claim is more useful than that.
What should you say when a customer demands zero?
Explain what you measure instead and why. "Zero vulnerabilities" cannot be verified by anyone, including you. "Zero known exploited, zero reachable high-risk open past deadline" can be checked against public catalogs and your own data.
Offer evidence: a recent SBOM, your KEV match result, your reachable findings and their ages, and your not-affected statements with reasons. Most security reviewers accept a clear, checkable commitment over a promise nobody can keep, and many prefer it.
What to do
- Define your target as zero known exploited and zero reachable high-risk flaws past deadline.
- Match your inventory against the KEV catalog automatically.
- Add reachability so you fix what can be hit.
- Set time to fix by severity and exploitation evidence.
- Remove unused dependencies each quarter.
- Write VEX style statements for findings you judge not affected, with reasons.
- Report these numbers, not raw finding counts.
Safeguard offers SBOM and dependency scanning, reachability analysis, policies and gates and autonomous remediation with fix pull requests off by default, which together support these targets.
What does the trade off look like in time?
Fixing everything immediately is not free. Each rushed upgrade risks a regression, and teams that chase every score burn out and start ignoring alerts. A deadline tied to exploitation evidence concentrates effort where it reduces risk most, and leaves lower risk items to the normal release cycle. That is not neglect. It is how you keep the commitments you made realistic enough to keep.
Quick check
Can a scanner prove there are no vulnerabilities?
No. It reports known issues in what it can see. Unknown flaws and missed components remain.
Is a not-affected statement a way to hide findings?
Only if it has no reason. A statement with a stated justification, reviewed and dated, is evidence.
Sources
- CISA, Secure by Design
- CISA Known Exploited Vulnerabilities Catalog
- FIRST: Exploit Prediction Scoring System (EPSS)
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
Last reviewed: 18 October 2026.
