What fields should be in an SBOM?

Starting in August, federal agencies will have to comply with the provision in Section 4(e) of Executive Order number 14028, that requires agencies to start asking for SBOMs from their suppliers of software and intelligent devices. In addition, many private sector organizations are starting to put serious thought into how they will use SBOMs, once they become available from their suppliers and once the appropriate tools or services are available to utilize them. In all of these discussions, the question is always asked, “What fields should be included in an SBOM?”

The easy response to this question is, “Whatever fields are needed to achieve your purpose for using SBOMs. By the way, what are you planning to use SBOMs for?” Since the most important purpose for using SBOMs currently – and the only one that’s addressed in the Executive Order – can be described as “Managing risks that arise in procurement and use of software, which are related to components included in that software”, the answer to this second question is, “Whatever is required to manage risks arising from procurement and use of software.” Of course, at this point, the questioner isn’t much closer to having an answer to their question than when they started.

We can imagine a different Q&A occurring between a federal agency and a software developer. The agency says, "We need you to start providing us with SBOMs by this August." The developer asks, “What do you need in those SBOMs?” The agency asks, “What fields can you provide?” The developer points out that the SPDX SBOM format offers about 70 fields, and CycloneDX has more than 100, but it’s certain that the agency won’t need anywhere near this many fields. So which ones do they want included in the SBOM?

At this point, the agency is likely to ask what they’re “required” to have. The answer to that is that there isn’t a mandatory requirement for what the SBOM contains. The Executive Order simply required federal agencies to ask for “SBOMs”, but it also required that the National Technology and Information Administration of the US Department of Commerce identify “minimum elements” for an SBOM. The NTIA put out an excellent report on this topic last summer.

Besides listing seven minimum fields for an SBOM, the report contains a lot of other good recommendations. However, it also goes to great pains not to make those actually look like recommendations, so there’s been almost zero (that I’ve seen) written about them; I hope to remedy that deficiency soon. Meanwhile, it seems that most people who are following developments with SBOMs have heard of the minimum fields.

I’ll agree that each of those seven fields – Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp – should be included in every SBOM. But saying that these are what “should” be included is like saying that a car should include an engine, a steering wheel, four wheels, a drive train, and a place for the driver to sit. This car (plus some other basic items, of course) would perhaps get you from point A to point B, but it doesn’t fulfill the purposes that most of us are looking for in a car. What’s needed that goes beyond the minimum?

The real answer to this question is that what’s needed beyond the minimum fields are simply what the supplier and the user agree on. After all, SBOMs are a “good” (really, more of a service) that’s exchanged in the marketplace. If the supplier and the user agree on 60 fields that the user wants and the supplier can provide these, great. By the same token, if the supplier and user agree that only the seven minimum fields are needed, that’s great, too – although I would question how much the user will be able to accomplish in the way of software component risk management, with just those seven fields.

However, it’s also very unsatisfying to say something like, “Whatever the supplier and the customer agree on is fine.” I say this for two reasons:

1.      In many cases (and just about all cases when the supplier is a huge organization, but the user isn’t), there won’t be any negotiations on this – or any other – question. The user either accepts what the supplier is offering or they find a different supplier and product.

2.      When there is real negotiation, the user will almost always have no idea of what they need, since they probably only have a vague idea of how they’ll use the SBOMs. The fact is that there isn’t much written now about how SBOMs can be used for software component risk management purposes.

However, there are at least two documents that suggest additional data fields that users and suppliers should consider:

A.     The Minimum Elements document linked above identifies, on pages 14 and 15, three additional fields regarding software components: Lifecycle Phase, Other Component Relationships, and License Information.

B.     Fortress Information Security[i] published in April an excellent white paper that provides guidelines for using SBOMs. In addition to the seven minimum data fields, the paper recommends (starting on page 12) that these fields be included: Product Supplier Name, Component Type, Component CPE Name, Package URL (a software identifier that is important now and will likely become even more important in the coming years), Component Version String, Component Download Location, Licenses, Cryptographic Hash of the Component, and Document Digital Signature/Code Signing.

Which of these should you ask for? In general, if you’re not sure which of these you need, you should ask for them all; they’re all useful to have, although a couple of them, like Lifecycle Phase and Component Hash, may be difficult for suppliers to produce, in some cases.

If the supplier pushes back on one (or more) of these and you don’t have a strong reason why you want to have it, then don’t demand it. As you get more experience using SBOMs, you’ll get a better idea of what you need and don’t need, to meet your own requirements.

I hope to write another post soon, that discusses the other items in Minimum Elements, which aren’t as obvious – but are probably more important – than the seven minimum fields.

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.

---

[i] Fortress is one of my clients, although I was not one of the direct authors of this document.