[delusional]

Can't you sort of do that by pinning on the commit SHA already? It's bad that that's not the ONLY way to do it, but at least it's something.

[dboreham]

You can also fork all the dodgy actions you consume.

[Halan]

Not really a solution at enterprise level and it exposes to the risk of likely not patching them as often

[neallindsay]

Yes but SHA1 collisions are easy enough to engineer, so even then compromise is probably possible.

(I don't know how hard it is to push a different object to an existing SHA on GitHub—I'm guessing that you probably have to remove all references to the original object at that SHA?)

[SAI_Peregrinus]

SHA1 collisions are easy, but nobody has publicly revealed a second-preimage attack. With a collision you create two inputs that hash to the same output, with a second-preimage attack you are given one existing input & have to find a second input that hashes to the same output. Collisions are much easier since you can control both inputs.

[neallindsay]

That's a good point. Setting up a benign release first that you have engineered a same-hash malicious release you can swap in later is a higher bar than gaining control of a repo and immediately replacing a popular release.

[Halan]

Yes and I do that and Dependabot supports it but most people wouldn’t bother