Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users.

It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.

It usually takes some time for an updated dependency to actually get shipped to users in a release, by which time there's a good chance the attack has been noticed.

> Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users.

Developer machines are quite juicy targets. They tend to have all sorts of credentials lying around, so it often isn't too difficult to escalate from that to compromising AWS/GCP/etc.

On top of that there's very little preventing a compromise. Developers are inherently expected to run untrusted code, and the usual Linux / MacOS laptop probably isn't even running any kind of anti-virus protection. Want to compromise the downstream app? Now you also need to pass Play Protect & friends.

> It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.

Yes, we really should. It is frankly a miracle that it has taken so long for fetch-time / install-time code execution to start blowing up in our faces. If we are spending so much effort on run-time isolation, why are we completely ignoring all those practices during development?

How do we know they don't? Who is going to read the source for all these micro packages?

You might assume we are able to detect all malicious behavior at runtime. But "stuxnet" and more recently, the xz compromise say otherwise. What if a not-so-popular crate deep in the dependency chain subtly introduced a LPE in it's code?