I think SBOM is interesting but it is totally absurd to think that SBOM is a _complete_ solution and/or comprehensive mitigation to Sunburst.
It is starting to make me mad people say this.
There is money on the line to create or enhance profitable software, so why not sell it that way?
I do not believe Solarwinds staff do not manage their dependencies or handle software better or worse than other companies. One attack vector had software that was properly digitally signed (think about _that_) and required cleverly backdooring developer workstation and infecting pipelines, then wiping traces clean. To mimic "if you can dodge a wrench, you can dodge a ball" you can similarly say "if you can hack a build process to build digitally signed software to wipe your traces away, you can hack a SBOM process in a CD pipeline to say whatever the hell you want."
I am into rektor and sigstore, but even they must realize, like others, if you think about the event everyone is talking about and the real threat model, we are advocating for some speeds as a solid perimeter defense, these are not fortified walls of security design.
Technical people get this nuance, non-technical do not, so this kind of solution advocacy in these articles about Solarwinds as an example, really resonates with the latter, who make purchasing decisions and strategies. That is what worries me.
@ris has a key part of it right, imho, but you have to go bigger than that, and not think just open source (even as a FSFer, I say that).
> The solution to this problem is not bureaucracy. The solution is in the reproducible builds project, Guix and Nix.
My belief for 3 pieces, the third and most difficult is missing.
1. Yes, digitally signed SBOM (in regulation or software contracts, those in USG contracting will know this is coming down the pipe anyway, others will follow).
2. Requirements for reproducible builds and _not_ just open source software doing that (I am thinking a build escrow ecosystem will have to come soon so commercial entities can farm out in some way their pipeline to third parties to build the exact thing they sell, identically match, or huge flairs go up). Again, regulation and contracts will have to push this, but I wonder how crazy I sound when I write this.
3. So if 2 seems hard: we need more appsec competency on just on the dev side, but the build/deploy side. If you have industry security bodies (government, legal, energy, financial) or big employers themselves, they will _need_ to have people set up test labs with realistic deployments over time, watch how their software behaves, build a network of people, resources, and information exchanges. They need to be able to build the skilset, learn to find vulns and most importantly risky default misconfigurations combining multiple software packages individual vendors don't think about. They will need to discuss when software that is 1 month in use or 8 years of use for %80 of my industry sector's employer or 100% of one big employer's network through training and communication to go ask people through these exchanges "hey, these systems are acting weirdly. Is this weird, do others see this or know this mis-configuration could be exploited and people have seen this before?" I mean that kind of knowledge share.
If it does not, certainly re 2 and 3, SBOM will change some, but not all.