What do you do with CVEs you can't fix? Auditor wants proof they're 'not exploitable'
One-person security/platform team at a small fintech, going through SOC 2. Patching what has a fix is fine. The problem is the stuff I can't fix, because there's no patched version, or the fix breaks something. Inspector/Trivy keeps flagging it, Vanta keeps…
One-person security/platform team at a small fintech, going through SOC 2. Patching what has a fix is fine. The problem is the stuff I can't fix, because there's no patched version, or the fix breaks something. Inspector/Trivy keeps flagging it, Vanta keeps showing it red, and technically every one needs a documented risk acceptance. Most of these aren't even exploitable in our setup, sometimes it's a vulnerable function never called, transitive dep we don't use, requires network access that doesn't exist. But "trust me it's fine" doesn't fly, and writing a proper exception per CVE takes forever. So, people who've been through this what do you actually show the auditor for "not exploitable"? Is there a way to automate this discovery/evidence gathering? Or does everyone just eat the busywork / quietly ignore them and pray?
已收录讨论
Why is it not fixable? What is the lifecycle of that component? Is it beyond eol? That becomes your responsibility to use something else. Is it new and a patch might come out soon? That’s not unusual and becomes case by case. Is it something that someone else found and the developer disagrees that it’s a vulnerability and is refusing to fix? That might be an acceptance. Not exploitable by code path is something infused tools try to do. Snyk or others etc. exploitability in general is tracked pretty publicly and tools consume that too
Scanner logs showing the module isn't loaded is basically what I've been doing so far. How do you package that though, screenshot per CVE? And does it survive the next image rebulid or are you reproving it every scan?
The documented-acceptance route is where I'm at. What actually goes in yours, just CVE + reason + revisit date, or more? And curious if auditors ever pushed back on one. Also haven't tried asking vendors to confirm exploitability, ours come mostly from AWS or opensource projects in GitHub libs.
Yes not all of the "not-fixable" is the same. On the tooling: Snyk reachability etc gives you the verdict, but does anything you've seen turn that verdict into the actual paperwork, the written acceptance, suppressing it in the scanner, clearing it in Vanta? Or is that last mile still manual?
Spot on. When I was more close to VM I used to see .dll's being left behind all the time by poor uninstalls and was always getting pushback that the app was uninstalled by people who didn't understand that the DLL could still be leveraged by an attacker. Same goes for the "we don't use that dependency" argument. You don't, but an attacker could. This is exactly how privilege escalation is done many time. Attacker gets on with limited rights but then finds a weak component that allows them to elevate.
We are 15 in total at the company, and that includes sales, ops, legal, executive etc - the tech dept is like 5 SWEs and me. I'd love to be a lot of people, but there aren't.
Yeah managing risk is key here. Spot on. Listing the exploit + the patch or risk mitigation is enough to show what you're doing to fix that
Security is like an ogre. It has layers! (Shrek)
Depends on why you're telling them its not exploitable. Are no exploits created for it yet or do you have other mitigations in place? Is there a specific module in your product that isn't enabled that has the vulnerability? I normally tell my auditors that we've either accepted the risk on something and documented it as a finding, or came up with a remediation plan. Also, sometimes the vendor of your product can help validate if its exploitable.
I have a few of those. Mainly on IPMI interfaces on older servers that cannot be patched. Remediation is to accept the risk and place those interfaces on a restricted VLAN.
I've run into this conundrum with vendors and certain Log4j issues. They wave it off, saying "We don't use that feature". If I get that in an email, I then forward it to our cybersecurity team and that will mark it complete. This is not as bad as the vendor who was trying to wave off .NET EOL findings. Sorry, buddy, you need to get to a newer version of .NET.
This.
Compensating controls is what you're looking for. Network isolation. Access control. Disabling the impacted components that are exploitable. Just because you can't patch it doesn't mean you can't mitigate the risk.
OP needs a security champion team, and the security champions need to be accountable for informing your SBOM and VEX statements. Those are the artifacts you provide your auditor. SOC2 is the easiest level of assurance to obtain. All you need to prove is that you have a process or you are developing a process.
You are confusing cyber sec with risk. You need a risk register with who owns the the risk and how are they mitigating the risk.
not saying you’re wrong, but the number of times that I’ve heard “this isn’t exploitable” from a feature team.. they’re usually right about 10% of the time in my experience. food for thought.. if they’re truly only in dead code, then remove the affected code from your product, disable the features in your dependency, etc etc
"Not exploitable" is not how I would word it. In the end you need to demonstrate how you manage this risk (and why it is very low - note: it is never non-existant)- e.g., "Yes we know this thing exists, we have logged it here at dd.mm.YYYY, Manager xyz signed it off on dd.mm.YYYY, and we are reviewing it monthly/quarterly/bi-annual" "We did an assessment and concluded the risk is low because [describe how you came to this conclusion] and have implemented a compensating controls [deactivated a feature/monitoring procedures etc.] - these are performed by [Role]" Provide evidence for this (you described how and what, so show that this is done).
Slap compensation for those? Give them scanner logs demonstrating the module is not active or loaded? Tell them to pay for a pentest (lol)
This is what a risk register is for. List the vulnerability and the treatment. If you can’t patch, or mitigate directly in some other way state the compensating controls. If it truly can’t be exploited, you could accept the risk. But I am guessing the actual case is that it can’t be exploited in the current configuration, in which case your change management policies are the compensating controls.
Remediation of a vulnerability (or more generally, a risk) does not require patching it. You have 4 strategies: Avoidance. Mitigation. Transfer. Acceptance. If you can't fully patch, you want to mitigate (for example, by placing specific rules in your WAF), reducing your risk to your baseline (say LOW), then accepting. You just need to document the process and show evidence to the auditor.
Ask your auditor. In general, a risk acceptance is the correct approach, with the caveat that the risk acceptance needs to have a maximum timeline with a plan to revisit it to determine if a fix is available.
Make it an exception and record it - best effort is the first thing an auditor looks for
Err, welcome to information security. Confirm your vulnerability management policy is sound and your methodology for classifying vulnerability risk levels is appropriate. Create an exceptions procedure and register. Proceed with risk assessment of the vulnerability (which should capture mitigations including defence in depth and determine residual risk level) and provide recommendation to owner/executive. Document sign off of any exception acceptance, with an agreed revisit date. E.g. 12mths. Revisit, rinse and repeat. You should maintain an exception for any approved non-conformity. Once someone has to sign or own an exception, quite often you might see the risk eliminated in the next sprint :)
https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf
Risk register is how we handle these. Someone must own up to the risk to justify its business case.