The NTIA Minimum Elements Report describes a number of practices regarding SBOMs that might qualify as “best practices" in a lot of people’s lexicons. However, it seems both NTIA and CISA are forbidden from using the superlative form of any adjective, so the report’s title uses the less imposing “minimum elements” phrase.
Despite the fact that the Report
states, “The minimum elements should not be interpreted to create new federal
requirements”, some software security practitioners – and not just those at
federal agencies - have glommed onto them as de facto requirements they
need to include in every software contract they write. And indeed, the document
makes it more likely that people will make this mistake by the fact that the
word “must” (underlined, no less!) is used at various places in the document.
But, dismissing the question whether
or not the report really provides “binding requirements”, the more important
question is whether the report in fact describes best practices, which might be
suited to ask for in software contract negotiations. That is, if the Report
says a supplier must do something, should you really try to force your
supplier to do it?
My answer to that question is,
“Sure, if you don’t care whether the supplier tells you to go pound sand and
find another supplier that can provide as functional a product, with as good
support, at an equivalent price.” I say that because, in requiring your
supplier to follow all of the provisions in the Minimum Elements Report, you’re
really asking the supplier to commit to performing impossible tasks. Here’s one
of the more egregious examples, which I know has caused a lot of suppliers heartburn.
Let’s look at the “minimum data fields”
in the table on page 9 of the report. Most software security practitioners
would probably assume this phrase means that each of these fields must be included
in the SBOM, for every component. For three of the fields (the first, sixth and
seventh), compliance is trivial, since they only require one response that
applies to the entire SBOM. However, for the second through fifth fields, it’s just
about certain that the supplier will be way out of compliance if you take the provision
literally and require them to provide a response for every field.
Fields 2 to 5 all have to be filled
in for every component in the product. Let’s look at the fifth field,
Dependency Relationship. Essentially, this refers to a possible “parent/child”
relationship between two components in the product (and the product itself is a
component, bearing the august title of “primary component”); of course, the “child”
component is itself a component of the “parent”. Let’s do some arithmetic
regarding this field:
1.
The average software
product includes around 150 components, although there are many products that
have thousands or even tens of thousands of components.
2.
You may wonder why a
supplier wouldn’t be able to provide a response in this field, for any
component of their product. After all, isn’t the supplier supposed to know every
component in their product? That means they should also know the relationship
of every component to every other component – with the three possibilities being
child, parent, and not applicable (when neither component is a parent of the
other).[i]
3.
Let’s look at
“Dependency Relationship”. That sounds simple, right? If a component is
included in the software your organization buys, you should not only know how
the component is identified (name, version string, etc.), but you should also know
what relationship that component has to other components. However, keep in mind
that a Software Composition Analysis (SCA) tool will list components in a
product, without providing a “dependency graph” that describes their
relationships. In order to truly understand all the relationships between components
in their software product, a supplier needs to have an SBOM for every component.
4.
To make it easier to
describe what we’re working with when it comes to component relationships,
people often talk about “tiers” of components within a product. The first tier consists
of components that are direct dependencies of the product itself. These are the
components the supplier has themselves included in the product. The product is
the parent, and each first tier component is a child.
5.
The remaining tiers – second,
third, etc. – all consist of components that are children of the components in
the previous tier. For example, the second tier consists of components that are
children of first tier components. In fact, this isn’t an exact description,
since sometimes Component A is a child of Component B, while B is also a child
of A – so there’s no good way to define tiers. But, the concept does help in
making high-level statements.
6.
In practice, it will
usually be extremely difficult to obtain an SBOM for any component that isn’t a
direct dependency of the product itself. In other words, while it will be
difficult (at least currently) to obtain an SBOM for any component other than
the ones in the “first tier” of components, it will be well-nigh impossible to
obtain an SBOM for any component on a tier lower than the first one. The main
reason why this is the case is that the supplier of the product, even though
they’re the direct “customer” of every supplier of a first-tier component, has
no direct relationship to any of the lower-tier[ii] suppliers.
7.
How do we estimate the
number of components in the product? That’s simple: Every component can be
assumed to itself have 150 components, since a component can often be a
standalone product on its own. Thus, the product contains 150 X 150 components,
or 22,500 in total.
8.
Now, how do we
estimate the number of dependency relationships among those components, since
that’s what this field is calling for? That’s also simple: Since every component
has one “parent” and 150 “child” components, there will be 22,500 * 151
relationships, which is approximately 3.4 million. However, since you can’t
count both the parent/child and the child/parent relationship of the same two
components as different, this means we have to divide this number by two,
yielding 1.7 million relationships.
9.
Thus, in order to completely
fill in this field as “required” by the Minimum Elements Report, the supplier of
a typical software product or intelligent device has to obtain 22,500 SBOMs and
use them to identify 1.7 million dependency relationships. If we assume that obtaining
each component’s SBOM (or perhaps creating it using a software composition
analysis tool) takes just one hour (a wild underestimate, of course), and if we
assume that identifying each relationship takes just one minute (also not at
all realistic), this will require 22,500 + 28,050 hours, which equals about four
years. Of course, that’s for one SBOM with 150 components, not one SBOM with
10,000 components; using rough calculations, the latter will take…a lot longer.
The moral of this story is that,
if a supplier of a typical software product with 150 components commits (perhaps
in a purchase agreement) to listing all Dependency Relationships of each
component, they’ll be committing to do the impossible. In fact, of six “must” items
that I count in the Minimum Elements Report, five of them will almost always be
impossible to fulfill completely.
What this means is that, if your
organization wishes to start obtaining SBOMs from your software suppliers, you
will be shooting yourselves in the foot if you try to require the suppliers to comply
with specific rules, including what’s in the Minimum Elements Report.
Instead, if the supplier doesn’t
already have a specific program for producing and distributing SBOMs to customers,
you need to have a discussion with the supplier about what they know they can
do at this point. You can ask questions like,
·
How often can they
provide an SBOM? If they can provide one with every major new version, that
would at least be a start.
·
Do they have a rough
idea of the number of minimum data fields they’ll be able to fill in? Even if they
say they can only provide information on a small number of first-tier
components, that’s a lot better than not providing any information on any
components. Call it a win for now.
·
What format will they
use for the SBOM? If they can provide it in one of the two primary
machine-readable formats, that is good. However, machine-readable SBOMs, require
a machine (consisting of hardware and software) to utilize them. There are literally
no examples of what I call a “complete” SBOM consumption tool currently
available, although there are a few open source products like Dependency-Track and Daggerboard
that do at least part of what a complete tool would do. Since there are vendors
that provide services that utilize SBOMs for vulnerability management purposes,
you should explore what you can get from them. You would just need to have the
supplier provide their SBOM (and any accompanying VEX documents) to the service
vendor.
·
What fields will the
supplier include in their SBOM, besides the minimum ones? An SBOM with just the
seven minimum fields won’t be terribly useful; there are a number of fields
that will be needed for specific use cases. You and the supplier need to discuss
what specific fields they will add to the minimum ones. This
white paper from Fortress Information Security (a company for which I consult)
contains good suggestions on additional fields you may want to ask for.
A supplier may tell you they can’t
provide SBOMs at all. Especially if you’re part of a federal agency, you
shouldn’t accept such a statement. If the supplier is concerned about software
security, they should be producing SBOMs for their own use, meaning they can’t
plead some sort of technical challenge. And if they aren’t using SBOMs now to learn
about vulnerabilities in their products, why is your organization still buying
from them? There’s no
real question in the software developer community nowadays that it’s
essential to track component vulnerabilities using SBOMs.
I do want to point out that a
number of suppliers are worried about providing SBOMs, since they think they
will give away IP if they do. This probably isn’t a valid objection in most
cases, but at this point, the last thing you want to do is try to force the
supplier to do something they think will jeopardize their business. You should
tell them they don’t need to fill in any field for which their answer might
contain IP.
At this point, with few suppliers regularly
distributing SBOMs to customers, the important thing is to get your supplier to
distribute something, even if it consists mostly of empty fields. We can
save perfection for later.
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] I should point out that neither the CycloneDX nor SPDX formats uses the words “parent/child” to describe component relationships. But since the two formats use different terms to describe relationships (CycloneDX takes a somewhat different approach to describing these relationships), and since most people have an intuitive understanding of “parent/child”, I’ll use those terms here.
[ii] You may notice that there are two completely contradictory metaphors used, when discussing component relationships. One metaphor is that of ground layers, with the product itself on the top and the components found in multiple layers below the product; in this sense, the tiers that are farther from the product itself are referred to as “lower”. The other metaphor is the dependency tree, whose roots are in the ground and branches spread into the sky. The product is essentially the base of the tree, and the components are on branches which themselves branch off. Every branch is a different “layer” or “tier”. In this sense, the more distant tiers are “higher” than the product itself.
Don’t hold me to either one of these metaphors. Just
think of distance of a component from the product itself; the farther away it
is, the higher the number of its tier.
No comments:
Post a Comment