For 95% of software will never happen unless SBOMs make the company money.
The world needs a software bill of materials
81–90 of 138 posts
Re: The world needs a software bill of materials
#82Earlier quoted context omitted.
I like this approach more because it incentivizes fulfillment of the risk interface without precluding flexibility in how that might be accomplished. I agree with your conclusion that a significant factor in improvements in safety have been seen in other industries with this approach -- align the incentive of not externalizing the risk and I think you'll see a lot of the misbehavior disappear because it's no longer p…
This is not a bad idea, but I am thinking whether this will only shift who is making money off the software from one big corporation to another. Maybe a combination of both - royalties to ensure developers are paid and insurance to ensure big corporations become conscious of their responsibilities.
The ultimate point of the insurance market is to provide an incentive for quality. Use of components which the insurer regards as low-risk will be cheaper to insure.
What would the insurer regard as low-risk? Typically, they would use two things:
1) Past experience - have they seen this piece of software regularly exploited?
2) Formal assessment in an underwriters' lab - do relevant experts consider the software to be well-constructed? Here open-source software has a real advantage, because the underwriters can review the source code directly, or pay others to do so. They have access to any automated tests and code coverage assessments, and so might assign a lower risk score to a project with more tests. They might even assign lower risk to projects written in languages that are known to produce safer code, so with all other things being equal a Rust codebase would be cheaper to insure than a C++ one.
This is entirely compatible with a system of bounties or rewards for anyone who moves the project in the direction of safety and high-quality maintenance. By concentrating the risk associated with poor software quality on the insurer, we get around the problem where many different companies use the software but are unwilling to pay for its maintenance. The insurer has a greater incentive to care than they do, and so would be more willing to pay developers.
I admit that this is a back-of-a-napkin sketch, but the incentives do seem to line up correctly.
Re: The world needs a software bill of materials
#83Earlier quoted context omitted.
I think on balance it actually hurts more than it helps. The author lists Equifax as a case where an organization “failed to update a web server in timely fashion (a few months)” but a software bill of materials would not have made it any more or less obvious that they were running vulnerable web software an attacker could get a foothold in, and could have made it easier for an attacker to exploit that foothold, pivo…
PII?
Personally identifiable information. It’s a term of art that is extremely common, at least in any large software company, that deals with customer data in any way. I’m not sure if it’s usage in the broader industry/common speech (although I swear I’ve occasionally seen it in news reports)
Re: The world needs a software bill of materials
#84Ramblings on these topics...
Exposing SBOM on every piece of delivered software will just make a hackers job easier and quicker... Since by design they are machine readable, SBOMs will make querying for specific vulnerabilities trivial.
This is not a top-down problem! Any upper layer can be compromised by a lower layer (os, build tool, library, reporting tool, etc.) this problem can only be solved Botton up : from verified OS, to verified (bootstrap) build tools of that OS, to every library installed on that OS, etc. We currently have decades of software resting atop of unverified libraries resting atop of unverified operating systems, all built with unverified tooling.
We can't even build verification tools that are, themselves, verified! And if we could, can we even say they verify every potential vulnerability? (mitm, boundaries, race conditions, cpu cache, etc.)
I know there is research at some universitys into formally verified OS's, but it's a long way off IMO.
This is the problem of our time. But, unfortunately, the industry seems consumed with velocity and cleverness over stability and security.
Re: The world needs a software bill of materials
#85Earlier quoted context omitted.
Just 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, an…
I didn't follow your argument. Could you elaborate?
Right 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.
Re: The world needs a software bill of materials
#86The idea of SBOM, or BOM is not a new one. Maven already has one for years now called BOM files [1]. So am I right in assuming that the author's suggestion is to make this BOM file public like the ingredients in food product as some people have suggested? If so, I can see a quick static analysis tool that can spit out the vulnerabilities just by parsing the BOM. So, really there's nothing to do much _technically_ here other than releasing out in the open the BOM. And then displaying ugly warnings about any software's BOM to either shame them or actually hurt their bottom line by lost revenue due to those vulnerabilities.
[1]https://maven.apache.org/guides/introduction/introduction-to...
Re: The world needs a software bill of materials
#87At least on first reading, I find this unpersuasive. He correctly lists a variety of problems. But he doesn't explain how his proposed solution, listing all the components of a technological product, would make a practical difference. Creating a list is valuable only if people a) read the list, b) recognize problems, and c) do something based on that. And for some of the examples he gives, it seems pretty obvious to…
I think on balance it actually hurts more than it helps. The author lists Equifax as a case where an organization “failed to update a web server in timely fashion (a few months)” but a software bill of materials would not have made it any more or less obvious that they were running vulnerable web software an attacker could get a foothold in, and could have made it easier for an attacker to exploit that foothold, pivo…
FYI - Compliance regulation in the US government almost never works, our government sucks at it. If you want to regulate a company like EquiFax, you have to stick to investigations and prosecutions, which the US government is quite good at. Companies can take the risk, but if they violate the law it should be big fines and jail time for the executives.
Re: The world needs a software bill of materials
#88The idea of SBOM, or BOM is not a new one. Maven already has one for years now called BOM files [1]. So am I right in assuming that the author's suggestion is to make this BOM file public like the ingredients in food product as some people have suggested? If so, I can see a quick static analysis tool that can spit out the vulnerabilities just by parsing the BOM. So, really there's nothing to do much _technically_ her…
Also, I wonder how can we realistically implement this for SaaS?
Re: The world needs a software bill of materials
#89Earlier quoted context omitted.
I didn't follow your argument. Could you elaborate?
Right 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.
I 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.
Re: The world needs a software bill of materials
#90Earlier quoted context omitted.
Right 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.
I 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…
I 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.