5 ms·
We need SBOMs, but these are not enough. We need supply chain attestations, but these are not enough. What we need is the combination of asset data, process dat
by jacques_chester 6y ago
We need SBOMs, but these are not enough. We need supply chain attestations, but these are not enough. What we need is the combination of asset data, process data and to acknowledge that our knowledge of both is always incomplete and subject to change. I call this need a "universal asset graph" and I've been nagging folks for years to get us to it.
The sigstore project is the biggest foundation stone of what I'd wish for, at least in terms of creating a robust shared log of observations (a leader of that effort, dlor, is in this discussion). But we still have a very, very long way to go as an industry.
- Ericson2314 6y agoJust look at Nix. Here's the thing, having the sellers of unfree software compile the code for is a terrible skeuomorphism from the way traditional products are made. The final integrator should be the one building the code even for propriety0 and unfree software, whose secretiveness should be enforced with contracts not obfuscation and baking in specific dependencies. The fact that the finally compilation graph, and the IP procurement graph have some similarities should just be a coincidence.
- jacques_chester 6y agoI didn't follow your argument. Could you elaborate?
- Ericson2314 6y agoRight now I'd you buy property software, you get a binary of some sort. That's neither composible or auditable. You should get the source code and a reproducible build, that you can modify and integrate with other things. Kinda like licensing closed source game engine parts, or getting hardware design libraries (IP as they say) for making your own system on a chip.
- jacques_chester 6y agoI think I follow now. Source availability is preferable but it will take a while to become normal. It will be even longer bit-for-bit reproducibility is a commercial norm. SBOMs still give us value in the meantime. If I buy product X, which asserts using dependency Y, then when a vulnerability is asserted for Y, I can pester the vendor to show that they have updated. At this point if they claim to upgrade but haven't, that becomes fraud. The economic incentives vs our current anything-goes world are differently weighted.
- Ericson2314 6y agoI kind of buy that, but I think it's important that SBOMs be designed such that it is clear what the gold standard is. The worst outcome is a standard that enforces a bunch of annoying metadata even in the all source and build steps are public case. The other problem is I don't think people without reproducible builds can deliver a correct SBOM. There must be some severe penalties for missing dependencies or something to steer people towards reproducible builds whether or not they are sharing source and packaging.
- jacques_chester 6y agoI think it helps to think of SBOMs as extracts or projections from an underlying knowledgebase which is updateable. There's certainly no sense in saying that any SBOM is truly final. Merely "this is our best knowledge at time X".
- Ericson2314 6y agoSure, but does a bunch of "best effort" guesses without enforcement or auditability actually converge? My experience trying to package things in Nixpkgs by upstreams that don't care about knowing their dependencies says no. Remember that sloppiness is infectious: if I can't wrangle my deps there is little marginal benefit from trying to keep my own packages in good shape. Also Docker being total snake oil. All these things tell me it's loosing battle without a severe course correction.