There's already an okay solution to supply-chain attacks against dependency managers like npm, PyPI, and Cargo: set them to only install package versions that are more than a few days old. The recent high-profile attacks were all caught and rolled back within a day, so doing this would have let you safely avoid the attacks. It really should be the default behavior. Let self-selected beta testers and security scanner companies try out the newest versions of packages for a day before you try them. Instructions: https://cooldowns.dev/

▲

edoceo 10 hours ago | parent | next [-]

More a case for something like this from Show HN three months ago

https://github.com/artifact-keeper

An artifact manager. Only get what you approve. So you can get fast updates when needed and consistently known stable when you need it. Does need a little config override - easy work.

I had my own janky tooling for something like it. This is a good project.

▲

Johnny555 10 hours ago | parent [-]

Does that really scale well? Thanks to cascading dependencies, even a medium sized project can import hundreds of dependencies. Can a developer really review them all to figure out if they are safe and that there's not security fix that was fixed in a newer version of the package?

	▲	jpollock 7 hours ago \| parent \| next [-]
		Yes, that is what is required. Every dependency needs an internal owner and reviewer. Every change needs to be reviewed and brought into the internal repository. If no one is willing to stand up and say "yes this is safe and of acceptable quality", why use it? It's a software engineering version of the professional engineering stamp.
	▲	edoceo 7 hours ago \| parent \| prev \| next [-]
		I love the sibling response from @jp... Also, IME we don't deep dive everything (should we?) For most stuff we make sure the latest is not-shit and passed test cases. We do have ceremony around version bumps.
	▲	8 hours ago \| parent \| prev [-]
		[deleted]

▲

10 hours ago | parent | prev | next [-]

[deleted]

▲

pjmlp 4 hours ago | parent | prev | next [-]

Even better, only use company vetted repos, everyone is forbidded to install directly from the Internet repos.

This naturally doesn't work outside corporations.

▲

b112 10 hours ago | parent | prev | next [-]

So you get security updates late too? Many vulnerabilities are in the wild for years before being noticed, and patched.

Once noticed, that's where the exploit explosion erupts, excited exploiters everywhere, emboldened... enticed... excessively encouraged, by your delayed updates.

▲

AgentME 8 hours ago | parent | next [-]

Presumably npm exempts security updates from its minimum release age, but even if it doesn't, I think the times where you need an important security update are relatively rare enough that handling the real cases on a case-by-case basis with whitelisting is fine. Outside of Next.js's React2Shell vulnerability last year, I'm not sure I've ever had a security update of a dependency written in a memory-safe language (ie. not C/C++) which I've installed through npm/PyPI/Cargo that patched a security vulnerability that had been making my application exploitable to others in practice. Almost all security vulnerabilities I've personally seen flagged through npm are about things I only use at build-time and are only relevant if a user can create and pass an arbitrary object to the function, which is rarely the case. Most security vulnerabilities I've encountered and fixed in working on web apps were things like XSS, SQL injections, and improperly enforced permissions, and they nearly always happened in the application's own code rather than inside a dependency.

	▲	wavemode 4 hours ago \| parent [-]
		> exempts security updates from its minimum release age If it does, doesn't that defeat the purpose? If a package is compromised, of course the compromiser will just label their new version as a "security update".

▲

ayuhito 10 hours ago | parent | prev | next [-]

At least with our Renovate config, all dependencies have a 7 day cooldown, but marked security updates are immediate.

Attackers can’t push a security update without going through the reporting process (e.g. Github CVE), so they can’t necessarily abuse that easily.

▲

ketozhang 8 hours ago | parent | prev [-]

You could still have security bumps happening (like dependabot).

▲

skydhash 10 hours ago | parent | prev [-]

IMO, the most sustainable version is either the linux distros/bsd ports/homebrew models. You don't push new libraries to the public registry, instead you write a packaging script that gets reviewed for every new changes.

Another model is Perl's CPAN where you publish source files only.

▲

microtonal 5 hours ago | parent [-]

Trust me, as someone who has contributed to such a package set, almost nobody is inspecting diffs between upstream versions when updating a package. Only the package definitions themselves are reviewed, but they are typically only version + hash bumps.

Reviewing upstream diffs for every package requires a lot of man hours and most packagers are volunteers. I guess LLMs might help catching some obvious cases.

	▲	skydhash 2 hours ago \| parent [-]
		Not really talking about upstream. Most supply attacks I’ve heard about are stolen secrets and artifacts uploading. They’re not about repositories or websites being taken over. As the packaging scripts are often in repos, you detect easily if people are trying to update where upstream points to.