The world needs a software bill of materials

Let me tell you a secret (not really):

- supply chain attacks are not new

- sophisticated attacks are not new

- what made microsoft call it the most sophisticated attack was *not* because of it using a supply chain attack, or waiting or any of the major bullet points listed when speaking about it but the combination of them and all the small details skipped

- through it might be the first sophisticated attack using supply chains *which we know of and which got a lot of press/success*.

- Neither new are attack which are possible at massive, potential global scale, even without supply chain attacks. So there has been a long time a lot potential for people losing, trust. There is a reason why many tech affine people don't trust governments or large institutions which sensitive data, we know the even the largest institutions will not always manage to keep our data safe.

- "does not take the coordinated effort of thousands of engineers in a nation-state" all sophisticated large scale attacks do *not* need thousands of engineers. Most times it's done by teams with noticeable less then 100 people. Nation-scal agressors are not that because they have so many (evil;) programmers but because they have access to nation-scale resources, like access to internet infrastructure, vulnerabilities known by the secret service or just money they can use for probing or obfuscating DDOS attacks. Lastly governments can have an easier job to bring a lot of expertise together, by bringing very qualified people together, not very many.

- "load external modules" has nothing to do with supply chain attacks, while it sometimes can make thinks simpler if you can affect the source-code (which is what supply chain attacks are about) you can do everything you need without any "module loading".

- "few risks unique to the software domain", I would say more than a few, and they are well known since over a decade

- "others are proprietary", which is a problem as it undermines many ways a user can try to detect/catch supply chain attacks. Non of which are perfect, like non would have cough this attack. But it still makes attacks of this kind harder.

- "Dependency hell" the only real problem, libraries with non-clear and brittle and to much much changing interfaces, at the same time surprisingly language dependent.

- "easier automated than what defenders need to do.", I wouldn't be sure about it, the same way attackers can scan for problem you can do so (and if you find something fix it). Tools like fuzz testing and other kinds automatic software analysis are widely underused.

- "96% of all software products included third-party software components and commercial" it tries to make this look like a problem but actually the only way to avoid security vulnerability (and build modern software) is by using external tools. If everyone would implement e.g. their own crypto there would be more vulnerabilities and automatic scanning for them would *still* work as people tend to make similar mistakes when writing similar code.

- "and now also by nation state actor", not it should be "and since the beginning". Just look at crypto wars, or how currently the US/EU governments again try to undermine software security for questionable reasons.

- "a bill of materials protects best against supply chain vulnerabilities when it is set up as a holistic cross-domain effort"... no it doesn't. There is nothing in a bill of materials which is able to prevent supply chain attacks. I have no idea why the author believes it. At best it can make it easier to catch if a known-to-be-vulnerable dependency is used. But supply chain attacks are about about making a dependency vulnerable without anyone knowing and *by changing it*. Not just by adding code. I guess this is build on the misconception that not having "loading of external modules" would help against supply chain attacks. It doesn't. It just makes it negligible harder.

-by the way open accessible source does imply a bill of materials (being derivable form the source) and allows you to automatically run software analysis tools on the source code etc.

- "medical industry has been targeted for years" and banking systems, operating systems, mail programs and games have been attacked even longer. The medical industry is interested in this to *avoid legal problems by using absurdities like software being "certified" to be secure (e.g. by using SBOM's) and similar*. A concept which is known to not actually work but tends to work to avoid legal responsibility. If they would care they would push for open accessible source, proper bug bounty programs and similar.

- "What needs to be done?" (In my opinion:) Push for at least open accessible source (!= open source). Push for more usage of software analysis tools. Push for proper bug bounty programs (many existing ones are questionable). *Enforce legal liability IF it's clear the software "seller" didn't care for making and keeping the software secure.* (I.e. Liability if negligent). Push for using additional protection which reduce attackers gain even if there are vulnerabilities. E.g. migrations like address layout randomization and shadow stack, sandboxing, dropping privileges, etc. WebASM might play a major role in this. Push for responsible choice of language, libraries and tooling. Push companies to take more responsibility for open source tools they use (!= open accessible source).

Lastly sometimes (not seldom) they *way* you use a certain dependency and for what you use it is making a *extreme* difference wrt. security. One example would be alternative hash algorithms in the rust eco system. Use them for certain internal use-case and all is fine. Use them at the wrong place and they enable hash map based DOS attacks. Another example would be openssl which you can use responsible, but also can use in horrible insecure ways.

In the end a SBOM is a thing which *should* be cheap to create (potentially automatized) but will only yield a slim improvement in general. It is IMHO *by far* not the most important step to do, but I guess it's one of the most easiest steps to do.

So why not, but don't believe it will make any major difference.

Are people publishing on Medium in order to earn money now or just that the large migration to a free platform is yet to occur?

My dream, a OS with a good proper well designed single capability system with reasonable defaults.

Not the mess Linux has which supports capabilities for some privileges but not so much for others, which has bad defaults and which is supper fragmented. I mean for a full cover you need to correctly combine root/sys capabilities with seccomp with bpf with cgroups with polkit with some pctrl settings with linux kernel parameters and even then you probably still need to throw in selinux and I still missed at least file permissions when writing this...

Which lets be honest is just ridiculous.

An SBOM as part of a contractual requirement when purchasing software seems totally reasonable to me if the receiving organization already has the practice of checking a lot of versions and making sure they're sufficiently up to date. But the hard part there isn't the creation of the SBOM, it's a) actually using the SBOM, b) having enough contract power that if the SBOM turns out to be incomplete, out of date, or a lie, the purchaser can do something about it, and c) the purchaser doing something about it.

Nutritional labels only work in practice because a) plenty of people read and care about them, b) there are regulatory agencies that set standards and enforce compliance, and c) if they are too far off, an expensive class action suit is a real possibility.

My concern with starting with SBOMs is that since they're orders of magnitude harder to read and evaluate, and since many, many companies are already bad at tracking their own software patch status, approximately nobody will actually use them. Again, I look at the Equifax breach: it happened not because they didn't know what a vendor was up to, but because their internal processes weren't sufficient to turn knowledge into results.

It's certainly possible. But I think it's equally likely that applied naively, we'd see more breaches as public SBOMs make it clearer what attacks will work where.

There's also a real question of net value for effort. Security is one consideration people balance, but it's far from the only one. Starting with SBOMs as the focus assumes too much about what people care about and how much work they'll do.

I'd much rather people start with some user-focused approach and then making use of particular technologies (like SBOMs) as needed to advance people's actual goals.