Wolf480pl
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
@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.
Nadia 🏳⚧
@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.
Haelwenn /элвэн/ :triskell:
Wolf480pl
@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.
Haelwenn /элвэн/ :triskell:
Wolf480pl
@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...
Simon Michalke
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.
Simon Michalke
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
@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
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.