Oct 26 2022

Crucial Elements of Software Bill of Materials (SBOM)

Open-source components contained within applications could be creating security vulnerabilities. An SBOM helps you peek under the hood.

When it comes to cybersecurity, visibility is key. Security teams need to know exactly what software and services are in use and especially what components those applications contain. How much open source is in use in the applications the organization uses every day? Are there any known vulnerabilities in the open source or other code components?

Looking Under the Hood of Applications and Services

Unfortunately, many organizations lack this level of visibility and do not know the precise makeup of every component in use. Teams are often surprised at the extent to which their applications contain open source: in reality, 75 percent of codebases consist of open-source software. While open source helps programmer productivity, it is far from being secure. A recent analysis showed 84 percent of audited codebases contained at least one public open-source vulnerability.

The same level of visibility is not really a requirement for hackers: all they need to do is find a vulnerability and attack it. When they exploit the vulnerability, the impact can be felt across the globe. When a major attack is made public, teams can spend a lot of time and effort to determine if their apps and services will be affected.

CSAM Sidebar

SBOMS are Good Cybersecurity Practice and the Law

Security teams understand that best practices call for full knowledge of the exact contents of each application and service. A Software Bill of Materials (SBOM), a comprehensive list of package dependencies, files, licenses and other assets that make up a piece of software, is an extremely helpful asset; however, it’s not just good practice — it’s required by law. SBOMs can apply to container images, virtual machine appliance images and even hardware devices such as firewalls, in addition to software and packages.

The Executive Order on Improving the Nation’s Cybersecurity issued May 12, 2021, requires agencies to enhance cybersecurity and software supply chain integrity through, among other things, requiring vendors to provide federal purchasers with a SBOM for each product.

Click on the banner below to learn more about cybersecurity solutions.

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.

Jay Yuno/Getty images

Become an Insider

Unlock white papers, personalized recommendations and other premium content for an in-depth look at evolving IT