Software Bill of Materials Questions and Answers
Because of the relative newness of the SBOM concept, questions abound. Here we provide answers to some of the most commonly asked.
What is included in a software bill of materials?
The SBOM, to meet the federal government requirements, should contain three elements: data fields, automation support, and practices and processes.
- Data Fields. To enable sufficient identification of all components and track them across the software supply chain, these minimum elements are required: Name of supplier, name of component and version, SBOM author and timestamp, other unique identifiers (such as from the NIST CPE Dictionary) and dependency relationships. The last item is very important because every time a developer includes a third-party dependence, whether an in-house component or open source, that module often has its own dependencies that the SBOM should spell out. Additional recommended information includes license information and a cryptographic hash of the component.
- Automation Support. To track the component data closely and continuously, the SBOM should be capable of automatic generation and the result must be machine-readable. Acceptable formats for the federal government include SPDX, CycloneDX and SWID tags, which have the additional benefits of being human-readable and somewhat interoperable.
- Practices and Processes. To ensure that SBOMs are updated and delivered adequately, this section includes frequency of update/recreation, depth (number of levels included), known unknowns (where the SBOM does not include a full dependency graph), how the SBOM is distributed or accessed, access control and methods for accommodating occasional incidental errors.
How does having this information benefit my agency?
An SBOM gives you visibility. This is especially important when deploying critical services or delivering software in environments with strong compliance requirements. The SBOM allows your agency to control risk by enabling early identification and mitigation of vulnerable systems. It also plays a key role in the vulnerability scanning process, so your scanner does not need to try to compute or guess the nature of the components.
In addition, the SBOM helps software vendors provide you recommendations for patching and provide auto-remediations, helping with your prioritization efforts.
REVIEW: Why EDR is a key feature to creating a zero-trust environment.
Doesn’t the SBOM provide a roadmap for an attacker?
While it may prove useful to the hacker, it more importantly provides your agency a roadmap for defense. When a broad-brush attack such as WannaCry hits, the SBOM levels the playing field and provides you with early warning. Keep in mind that hackers don’t need specific knowledge of which agencies are using a particular component. They can perpetrate broad attacks that hit multiple agencies, by exploiting known vulnerabilities. Also, the SBOM does not need to be made public. In fact, the Executive Order cited above says there is no requirement to make the SBOM public.
What should I look for when reading an SBOM? Are there any red flags?
First, make sure the SBOM contains the information necessary to meet federal government requirements. Beyond that, make sure the SBOM is not too shallow. It’s relatively easy to produce the root-level SBOM that covers the first level of dependencies, but discovering transitive dependencies becomes more difficult since some components may not have an SBOM in place.
Further, beware of SBOMs that are not digitally signed and/or versioned. Because a hacker can edit an SBOM without leaving a trace, these omissions call into question its authenticity and integrity.
Finally, there may be applications for which no complete SBOM yet exists, since the process is relatively new. You may need to use scanning tools to do a “best guess” at the SBOM.
Take the First Step With an SBOM
As with any new process, mistakes will be made, dependencies will be incompletely specified and formats will be somewhat incompatible. Nevertheless, SBOMs are a valuable first step in securing the supply chain. They can make life easier by providing a look under the hood of your software and services to understand your vulnerabilities, and they give you a roadmap to fix them.
Keep this page bookmarked to keep up with all of FedTech's Cybersecurity Awareness Month coverage, including featured articles on incident response plans.
