Hacker News new | ask | show | jobs
by btown 32 days ago
At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? Particularly for frontend packages, meaningful security fixes seem less likely than supply chain attacks these days.

It's a sad state of affairs, for sure - but is there a reason we can't just switch our frontends to static BOMs, and trust that NPM at least gets their "you can't republish to an old version" bare-minimum constraint right?

4 comments

> At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update?

But then the compliance team gets annoyed because some CVE with a CVSS score of 3.1 that has a patch available sits unfixed.

I wonder if the only thing that will solve this is an insurer or regulator saying that: "A system that automatically pulls updates for dependencies without human review, where said updates are not protected by multi-factor authentication by their respective maintainers, shall not be considered secure."

That would wake NPM up at least to the notion that it's absolutely reasonable to require OSS maintainers to press a button on their phones when releases go out, and that's a good thing not a bad thing.

Pretty much what the EU Cyber Resiliency Act says re: OSS due diligence, actually.
The core problem is companies skimping on maintenance.

They don’t want to pay engineers to do the analysis manually, and they don’t want to pay for someone to figure out a better automated system.

Would anyone be surprised at their car having problems if they cheaped out on oil changes?

Enforce a “seasoning” period, for example don’t let any pull pull versions newer that 30 days. Perhaps with an exception for versions that address known CVEs.
Yes. This is partially why other ecosystems don’t see as many supply chain attacks.
> and trust that NPM at least gets their "you can't republish to an old version" bare-minimum constraint right?

... Does NPM not create full lockfiles, with hashes and pinned transitive dependencies and everything?

Yes, and the problem here is that most projects have automated systems that automatically update those lockfiles on every upstream release of a library, under an assumption that minor releases are either security patches or bugfixes that would immediately be useful to the consuming project.

IMO this is built on a pre-ShaiHulud, pre-AI set of assumptions, and should be evaluated from first principles with today's security situation.

My point was the "with hashes" part. You aren't in fact "trusting" NPM to ensure that old versions aren't replaced if the package installer is verifying the hash.