Are these real findings, or a situation in which fixes have been backported? At one place I worked, the corpsec guys were wildly incompetent and would try to bury me in "CVEs" in my systems that were nothing but "vulnerable" software versions with all of the "identified" vulnerabilities fixed by Debian backported patches.
If you're not a security person, the unspoken subtext here: the overwhelming majority of these "CVEs" do not matter to the project, and a very large number of them don't matter at all. They're pro-forma findings, like ReDOS in code paths that are rarely used, or, even more commonly, "prototype pollution" issues.
I'm convinced you can tackle 5-10 "CVEs" a day, make a little dashboard, put some pretty graphs on it, and send it to your exec team and probably get accolades. Nevermind that the CVEs had nothing to do with your product.
I don’t say it’s the case there (it probably isn’t, you probably need hardware access or root), but sometimes those sorts of things do actually matter because there’s a way of causing them to be run anyway.
This is why it’s good to exclude things you don’t need. The less there is, the fewer places there are for problems to lurk.
Because it's written in Javascript and there are classes of highly-situational and not-especially-meaningful vulnerabilities that broadly impact the entire ecosystem ("prototype pollution" is the canonical example) that get counted individually in every occurrence in every NPM package.
It's not a real number, and, worse, it obscures the real figure of merit (/demerit). The Node ecosystem does have a real problem with its culture of sprawling dependencies. But it's not the first-order issue with this "1400" number.
When node was new there were many browsers (different rendering and js engines, not just chrome reskins) and standards and "proto standards" were moving very fast. Different browsers and versions would have very different support for CSS directives, tag behavior, etc. This was a real pain in the ass to make a site consistent across different browsers - every other line of code would require a full switch statement based on browser and version it seemed, and all of these things would need updating every time some browser had an update.
The answer to this was something called polyfills, a library that did something as simple as element.center() with just 500 lines of code to make it consistent on all browsers, and all the places you want to center that element are updated by the polyfill authors and your code doesn't need to be touched.
All the sites that weren't using good polyfills broke (or at least looked terrible) for days every time there was a new $browser update.
Since thats the javascript environment node was born into, the style was carried over by inertia and habit, for better and worse.
Because it's written by a type of dev that thinks everything should use JS because that's what they used for 6 months while working at a FAANG company before getting laid off and since they worked at a FAANG company clearly they know better than you so if you attack them for using an extremely poor language you just aren't a seriously person so please shut up while I go fishing for some VC funds.
It's like asking why Claude Code is written with react, because the devs getting paid >$500k a year clearly know better d'uh.
https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exp...
This is why it’s good to exclude things you don’t need. The less there is, the fewer places there are for problems to lurk.
Scanning companies should be sophisticated enough to distinguish invalid CVEs and back ported fixes.
It's not a real number, and, worse, it obscures the real figure of merit (/demerit). The Node ecosystem does have a real problem with its culture of sprawling dependencies. But it's not the first-order issue with this "1400" number.
The answer to this was something called polyfills, a library that did something as simple as element.center() with just 500 lines of code to make it consistent on all browsers, and all the places you want to center that element are updated by the polyfill authors and your code doesn't need to be touched.
All the sites that weren't using good polyfills broke (or at least looked terrible) for days every time there was a new $browser update.
Since thats the javascript environment node was born into, the style was carried over by inertia and habit, for better and worse.
It is pretty much the lowest common denominator for code.
It's like asking why Claude Code is written with react, because the devs getting paid >$500k a year clearly know better d'uh.
> NanoClaw is a secure, lightweight alternative to OpenClaw.
Yes, this is mostly a joke, I am able to understand the difference between base distros.