Hot take: the cybersecurity industry wastes an incalculable amount of effort "remediating vulnerabilities" in code because a library used has some "vulnerability" that can't actually be exploited in the way it's used in the application.
1. Not all dev teams have the skill to evaluate this; not all orgs trust the evaluations of the dev teams
2. If you're not using it in a vulnerable fashion today doesn't mean that you won't use it in a vulnerable way tomorrow. There's no way to check this at scale and allowing you to whitelist it today means a false negative tomorrow
as someone who manages both vulnerability research teams who find / exploit vulnerabilities and product teams responsible for remediating vulnerabilities, I agree with this a thousand percent.
@Jake Williams is triaging a vulnerability report easier than upgrading the library to a non-vulnerable version, especially if there's going to need to be future upgrades?
it can really detract and draw attention away from vulnerabilities that are created by implementers on the ground, which don't show up in scanners or CVE listings.
I work at a vendor in the application security space; most companies struggle to deal with vulnerabilities that have a patch available and are being actively exploited. Only the top, most-staffed security organizations ever get past addressing critical-severity vulnerabilities at an enterprise scale.
It's one of the most quintessential demonstrations of the blue team having to be perfect all the time (patch/update everything) and the red team having to get lucky once (exploit one vuln). It's a bad paradigm with no good solution.
I'll also add that these are just the known vulnerabilities. You're obviously still not safe, even if you've somehow remediated every vulnerability or triaged it to where you're confident it's not exploitable.
Cisco have a bunch of vulnerabilities in a bunch of their stuff. But one thing I can appreciate about their advisories is how clear they (usually) are on exploitability and they'll be really up front & say if you just turn off x feature then your risk is reduced. Makes managing the priorisation of remediation a lot saner.
Nothing like fighting Node CVEs in our AWS CDK projects, and having to go back and recreate old projects for a build time tool that only ever creates yaml
but counterpoint, is including a 13 year old DLL in your code that has lots of vulnerabilities (whether you 'use it that way' or not) really a sign of a good code quality process?
We've been chasing a bunch of these lately and as others have noted, getting a vendor to confirm 'we don't use it that vulnerable way’ is like pulling teeth. Getting them to explain why they can't update to a current, non-vulnerable version, is nigh-on-impossible.
And meanwhile we have to explain why the vuln counts have skyrocketed due to another new CVE for that same damn DLL in it's (almost) latest version
Jack Coates 🐀
in reply to Jake Williams • • •FlorianTischner
in reply to Jake Williams • • •true, but necessary:
1. Not all dev teams have the skill to evaluate this; not all orgs trust the evaluations of the dev teams
2. If you're not using it in a vulnerable fashion today doesn't mean that you won't use it in a vulnerable way tomorrow. There's no way to check this at scale and allowing you to whitelist it today means a false negative tomorrow
Caitlin Condon
in reply to Jake Williams • • •silverwizard
in reply to Jake Williams • •Luke Georgalas likes this.
GreenDotGuy
in reply to Jake Williams • • •resolude
in reply to Jake Williams • • •I work at a vendor in the application security space; most companies struggle to deal with vulnerabilities that have a patch available and are being actively exploited. Only the top, most-staffed security organizations ever get past addressing critical-severity vulnerabilities at an enterprise scale.
It's one of the most quintessential demonstrations of the blue team having to be perfect all the time (patch/update everything) and the red team having to get lucky once (exploit one vuln). It's a bad paradigm with no good solution.
I'll also add that these are just the known vulnerabilities. You're obviously still not safe, even if you've somehow remediated every vulnerability or triaged it to where you're confident it's not exploitable.
Jimmy
in reply to Jake Williams • • •SensibleOtter
in reply to Jake Williams • • •pejacoby
in reply to Jake Williams • • •but counterpoint, is including a 13 year old DLL in your code that has lots of vulnerabilities (whether you 'use it that way' or not) really a sign of a good code quality process?
We've been chasing a bunch of these lately and as others have noted, getting a vendor to confirm 'we don't use it that vulnerable way’ is like pulling teeth. Getting them to explain why they can't update to a current, non-vulnerable version, is nigh-on-impossible.
And meanwhile we have to explain why the vuln counts have skyrocketed due to another new CVE for that same damn DLL in it's (almost) latest version