The bummer about lots of supply chain work is that it does not address the attacks we see in the wild like xz where malicious code was added at the source, and attested all the way through.<p>There are gains to be had through these approaches, like inventory, but nobody has a good approach to stopping malicious code entering the ecosystem through the front door and attackers find this much easier than tampering with artifacts after the fact.
Valuably you also get demonstrable _insecure_ status - half the pain for our org of log4js was figuring out where it was in the stacks, and at which versions. This kind of accounting is really valuable when you're trying to figure out if and where you are affected.
> it offers integrity and reproducibility like no other tool (btw. guix also exists)<p>This rubs me the wrong way. They acknowledge that alternative tools exist, but willfully use the wrong-er statement in pursuit of a vacuous marketing idiom.
This solves the problem of provenance and possibly build integrity. Given an artifact, it will allow identifying exact source from which each components are built.<p>But it still implicitly assumes that the source is secure and trusted. This is where a lot of problem happens when the source is compromised and malicious code is added.
I wish we would use terms like "verifiable" or "reproducible" rather than "secure", which is quite difficult to evaluate out of context of usage.
Nothing is demonstrably secure, only not demonstrably insecure. This is - hey our builds come with a bunch of resources you can use to try to prove they're insecure, but you probably can't - but it's an advertisement.
This seems to only address a few of the nine threats to the software supply chain, mainly "(D) External build parameters" and maybe the content-addressable storage addresses some of the distribution phase threats: <a href="https://slsa.dev/spec/v1.1/threats" rel="nofollow">https://slsa.dev/spec/v1.1/threats</a><p>There are still many other ways that a dependency can be exploited before or after the build phase.
Classical Nih<p>"It's easier to do ThingA with Nix because you don't have to do ThingB!" (proceed to explain how to do ThingB but with Nix)<p>> You don't need to maintain your own forks and patchsets<p>... but you need to maintain your own nix packages and build scripts which is basically same amount of work
This still doesn't fix the "trusting trust" attack: which Guix actually can, and which can bootstrap sideways to build other distros.<p>It also doesn't do anything which regular packaging systems don't (nix does have some interesting qualities, security ain't one of them): I.e. that big list of dependencies isn't automatic in any way, someone had to write them, which in turn makes it exactly the same as any other packaging systems build-deps.