SBOMs for patched software versions

One of the fundamental tenets of the SBOM faith is that the developer must produce a new SBOM whenever anything in the code of the product has changed; even if the change is just a patch being applied, there needs to be a new SBOM. I myself have repeated this teaching many times. Of course, it’s also enshrined in the Minimum Elements document.

However, a recent conversation with the Director of Project Security of one of the largest software developers in the US has changed my thinking. There’s something special about patches that makes a new SBOM almost impossible in most cases. The only real solution to the problem is for the developer to do a complete version upgrade whenever there’s been a new patch issued (or even better, they don’t issue a patch; they just require all users to upgrade. But that would mean a lot more work for both the developer and their customers).

Of course, given that nowadays there are very few developers that are issuing a new SBOM with every major version upgrade, let alone with every patch, this isn’t currently a problem. When it becomes a problem, I’ll just count it as an indication that SBOMs have truly arrived – somewhat like the “problem” that too many wealth managers will call you if you just won the lottery. We should all have such problems.

Here is what my friend said:

1. Typically, a developer will issue multiple patches between version upgrades. The patches usually aren’t cumulative. This means that, if there have been five patches since the last upgrade, applying the fifth patch won’t also get you the previous four patches. If you want all five, you need to apply each one. Of course, when the next version upgrade comes out, you’ll receive all five patches “baked in” to the upgrade. But it’s certainly not a good idea not to patch and to just wait for the next upgrade!
2. If the developer wants to issue a new SBOM after say the fourth patch, they need to make an assumption about which of the previous three patches were applied by the user. Of course, assuming those patches weren’t automatically applied, it’s certain that different combinations of the previous three patches may have been applied by different customers (and some customers might not have applied any of them); moreover, it would be a huge waste of time for the developer to poll their customers whenever they release a new patch, to find out which of the previous patches they’ve applied.
3. What should the developer assume when preparing the SBOM? The only thing they can assume is that all possible combinations of the three previous patches have been applied by at least one of their customers. So, completeness requires preparing an SBOM for each possible combination of patches that might have been applied.
4. The number of ways you can group any number of items is the factorial of the number; three factorial is 3 X 2 = 6. Since there’s also a possibility that a user didn’t apply any of the three patches, this means the developer would have to create seven SBOMs, in order to cover all the possible cases. This will be a lot of work, especially when you consider that the developer will have to develop multiple SBOMs with each new patch that they issue (except for the first patch issued after an upgrade. That’s because there are zero previous patches, and zero factorial is zero).
5. Seven SBOMs might sound doable to some people; let’s not spend time discussing that question. How many SBOM’s does the developer need to prepare if there have been five previous patches? That’s 121 SBOMs. Seven previous patches? 5,041 SBOMs. And how about ten previous patches? That’s about 3.6 million. Producing that many SBOMs will probably take more than a few weekends, I’m afraid.

Clearly, the developer can’t be expected to produce a new SBOM whenever they release a patch, except perhaps an SBOM that assumes all previous patches were applied. So, please don’t try to force your developer to follow SBOM dogma and produce a new SBOM whenever the software changes. To start, count yourself quite lucky if the developer promises to provide one SBOM with every major version upgrade. Just that will be a lot better than what you have now. Here’s the mathematical rule that allows me to say this: Any positive integer is greater than zero.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.