Our scans keep finding vulnerabilities that have no upstream fix, or where upgrading would break something. How do you assess these, reduce the noise, and show an auditor why a finding is being accepted or treated as not applicable?
What do you do with CVEs that have no patch yet?
Asked by
9E+Knuckler
Answers
Don’t make the decision at the CVE-name level alone. Record the affected component and version, whether it is present in the shipped artifact, whether the vulnerable code is reachable, what access an attacker would need, and any controls that reduce the risk. If the code path is genuinely unused or the required exposure is absent, say exactly how you established that rather than just marking it “not exploitable.”
Keep the evidence with the finding: scan output, dependency or call-path analysis, configuration, and the rationale. For an unresolved risk, include an owner, approval, and a review date. A VEX statement can help express whether a vulnerability affects a product, but it does not replace the supporting analysis or whatever your auditor requires.
Reply to this answer
For a critical finding with no fix, I’d treat “unfixable” as a temporary state, not as a reason to close it. Work through the real attack path, check whether the vulnerable feature is reachable from an untrusted source, and look for practical mitigations such as disabling the feature, validating inputs, limiting access, or replacing the dependency. If none of those is adequate, escalate the risk rather than burying it.
Document why an upgrade is unavailable or unsafe, who accepted the residual risk, and when the decision will be revisited. A time-limited exception is much easier to defend than an indefinite suppression.
Reply to this answer
The time-saver is usually fixing the repeated source of findings, not writing a long memo for every scanner row. Sort by dependency and artifact, then see which few direct or transitive packages account for most of the alerts. Removing unused packages, replacing a troublesome dependency, or updating the base image can clear whole clusters.
Still, don’t assume a dependency is harmless just because your application doesn’t call it directly. Check whether it is included in the release and whether another component can invoke it. Automate collection of versions, scanner results, and ownership, then reserve human review for reachability and risk decisions.
Reply to this answer
One caveat: a scanner not reporting a CVE is not the same as the vulnerability being gone. Some distributions backport security fixes without changing the upstream-looking version, while other tools may not recognize that status. Check the package vendor’s security information and make sure your scanner is interpreting that package correctly before suppressing the alert.
If the artifact really contains vulnerable code and there’s no supported fix, a compensating control or a documented exception may be the honest answer. “Zero findings” is a reporting target, not proof of zero risk.
Reply to this answer
Add your answer
Answers are reviewed before publication.
9E+Knuckler:
Would you keep a separate record for every CVE, even when several come from the same dependency?
3W+Vellum:
Group findings when the evidence and rationale truly apply to the same component, artifact, and exposure. Keep each CVE traceable, though, since a different flaw in that dependency may have a different reachable path or mitigation.