We're taking a very different[1] approach at Chainguard.

Essentially: building the world from GitHub repos on SLSA L2 hardened infra and delivering directly to our customers to bypass the registry threat vector (which is where vast, vast majority of attacks occur—we'll be blogging about this soon with more data).

[1] https://www.chainguard.dev/unchained/announcing-chainguard-l...

▲

vlovich123 9 hours ago | parent [-]

Doesn't really sound very different and I don't see how it helps here. This attack is just a vanilla library that you hope someone adds as a dependency and you attack the users of whoever runs the code. I fail to see how Chainguard helps at all here (not to mention this is Rust and not whatever "build 3p packages" means in a JS world).

▲

prdonahue 8 hours ago | parent [-]

It's the same principle as a company blocking access to domains registered in the past 30 days. Doing so eliminates a huge percent of phishing/malware as these domains are typically identified and taken down otherwise blocked in that window.

In this particular case, the bogus libraries had been out there for months. But if in addition to a delay, you mirror just the most common subset of packages with some opinionated selection criteria and build directly from source, you eliminate most of these attacks. (The same is true across whatever language ecosystems, including JS as you mention npm, etc.)

Is this 100% infallible? No, but security is a risk reduction game.

	▲	vlovich123 6 hours ago \| parent [-]
		Ok. So basically the “in addition” means the techniques you’re highlighting you do aren’t enough and are basically arguing for manually curation of the registry which obviates all other techniques. Aside from the fact it doesn’t scale, xzutils famously faced a directed attack that would have passed through manual curation too.