If CVE scanners are stupid, then what should I do instead?

Suppose I'm a sysadmin / devops at a small sofrware company. The devs write webapps with lots of dependencies, which they rarely update.

Is there anything I can do to meaningfully reduce the risk of a vuln in one of those dependencies getting us pwned, without that consuming all of my time?

@wolf480pl As a first step I'd have filters for low-risk vuln classes for client and server side. E.g. I see a large chunk of effort being spent on theoretical XSS scenarios that will likely never be exploited:

https://github.com/v-p-b/xss-reflections

@wolf480pl

It is a bad buzz word, but "zero trust" in its original form does make sense. Isolate the services enough from each other to avoid spreading if one of it gets pwned.

Also being picky what kind of software you use is really helpful. I always annoy my colleagues with "always use the latest major version automatically. What? You do not trust this software to not break on minor upgrades? Then we should not use it in the first place"

Stuff breaking on automatic upgrades is my favorite indicator for broken software that should be avoided.

@wolf480pl

Most of the "dependency hell" tools out there (npm, maven) so have integrated checks that warn you or there are plugins to update dependencies. Even if your team wants to stay fixed to a certain version, make the pipeline display big fat warnings if there is an update available. Insist that they immediately apply this update and push to prod.

@wolf480pl CVE scanners are (somewhat) useful, it's just that their output needs a lot of filtering. Raise only long-standing unaddressed issues, and filter out vulns that maintainers not have acked or fixed.
Help devs set some dependency automation (renovate, dependabot) so they don't have to do it by hand.

@nadia I tried filtering by CVSS score, leaving in only "Critical". There was a single-digit number of those per year. I would read the descriptions and linked writeups for each of them, and after that it usually turned out half of them are clearly not applicable or just pure bullshit.

For the rest I wasn't sure whether we're affected because I didn't know how the application uses them, so I opened tickets for the devs. It turned out half were not applicable either.

And it was a PITA.

@wolf480pl It is impossible to have any security with webshit due to the 7,800,000 dependencies.

If you want security, you need to have real software written instead.

@Suiseiseki it's impossible to have any meaningdul conversation with Suiseiseki due to 7'800'000 ways everything is either 100% good or 0% good and if you want to get from 0% to 1% you're a fool and should reconsider your career choices.

@nadia maybe the problem is spoons, not time

@nadia @wolf480pl > renovate, dependabot

Except those are pretty much a recipe for disaster because none would really check the diffs as that's not really their job to do so, plus it's not always just source code that's in the repos (like PyPI, npm, … allows to upload straight up binaries).

@lanodan @nadia also, that would mean more updates that we'd get if we cared about every bullshit CVE.

And more updates => more change => harder to figure out why things broke. On one hand, it's not my job to fix outages when it's clearly the app's fault. On the other hand, it's easier to know it's not the app's fault when the app still runs the same docker image as last week.

@simon_m I can't insist that the devs update every time there is a new version, because a) that'd be a crippling amount of extra work for them, and b) it drastically increases the rate of change, and the number of factors that change, making it harder to figure out why things broke.

Now, if I could make them avoid dependencies that break with minor updates, but only run all minor updates at designated times (ideally when there are no changes to the app itself) that'd be cool

@wolf480pl

You can make them add a pipeline that uses the updated versions to run the tests as well.

It does not have to block merging or so, but being there and catching issues with newer versions early on during normal development is incredibly useful.

@simon_m the thing with isolating services harder (also what @quad suggested) - maybe there are some things I could do here, but AFAIK the most valuable data is the one that all those services need access to. But maybe not all of them...