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.

@malwarejake
But we have a SLA/policy that says ALL critical/high/medium vulnerabilities MUST be remediated in 30/60/90 days lest we shall feel the wrath of...something. /s

@malwarejake 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.

@malwarejake 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.

@malwarejake 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.

@malwarejake 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