Comment by baobun
12 hours ago
I still don't see how lockfiles can't be SBOM.
They contain for each dependency name, version, (derivable) URL and integrity checksum, plus of course the intra-dependency relationships.
This can all be verified at any point in the lifecycle without running any of the code, provided a network connection and/or the module cache. What's missing?
> With authenticode, the "catalog" can be signed
You could trivially sign any lockfile, though I've never seen it. I think it could be neat and it might have a chance to catch on if there was more support in tooling for it. The NPM registry does support ECDSA package sigs but I guess signatures for this use should be distributed on other channels given how much of an antipattern uploading lockfiles to registry is considered in the npm community and that's an uphill. In the context of SBOMs I guess there's already a slot for it?
I don't think you've addressed the requirement of having to execute the software, that was my main objection.
Another matter is that most software I know of doesn't even use lock files. Furthermore, there are lots and lots of software that would need to be updated to support your scheme, but updating them just isn't practical. It would have to be relegated to the type of software that gets regularly updated and its authors care about this stuff. I mean, we can't even get proper software authors to host a security.txt on their website reliably. It needs to work for "old" software, and "new" software would need to spend time and effort implementing this scheme. How can we get people that won't even sign their executable to sign a lock file and participate in the verification process?