• OVERVIEW
  • Q: What is an SBOM?
  • Q: Who should have an SBOM?
  • Q: Who uses an SBOM and for what?
  • Q: Can SBOMs be generated at different points in the software lifecycle? (NEW)
  • Q: I’m still learning how to make SBOMs. Is it necessary to try to produce all the SBOM types? (NEW)
• BENEFITS
  • Q: What are the benefits of an SBOM?
  • Q: How does an SBOM help in the event of a cyberattack?
  • Q: In addition to vulnerability management, how can SBOMs help me?
  • Q: How have bills of material and supply chain transparency been helpful elsewhere?
• COMMON MISCONCEPTIONS & CONCERNS
  • Q: Won’t SBOMs be a “roadmap to the attacker”?
  • Q: Does an SBOM require source code disclosure?
  • Q: Does a list of the software components I include expose my intellectual property?
  • Q: Does an SBOM increase my exposure to license violations?
  • Q: Does an SBOM enable patent or license “trolls”?
  • Q: Will SBOMs increase my licensing costs or licensing commitments?
• CREATION
  • Q: Who creates and maintains an SBOM?
  • Q: What should be included in an SBOM?
  • Q: What data formats exist for conveying SBOM data?
  • Q: Are there tools that translate between SBOM formats?
  • Q: When is an SBOM created, changed, or maintained?
  • Q: Some software components are made up of other software components themselves. Can an SBOM show that hierarchy?
  • Q: How deep in the dependency graph should an SBOM enumerate?
• DISTRIBUTION & SHARING
  • Q: If I make an SBOM, do I have to make it public?
  • Q: How will SBOM data be shared?
• ROLE SPECIFIC
  • Q: How can SBOMs be leveraged as a Purchaser?
  • Q: How can SBOMs help an engineer provide surveillance for deployed technology in the field for emerging vulnerabilities?
• RELATED EFFORTS / “How does SBOM relate to...”
  • Q: What is VEX? (NEW)
  • Q: What are some uses for VEX? (NEW)
  • Q: Does SBOM require VEX? (NEW)
  • Q: What do I need to include when I create a VEX document? (NEW)
  • Q: What formats exist for a VEX? (NEW)
  • Q: For a VEX statement that says a component is “not_affected”, how can a VEX provide additional information on why it is not affected? (NEW)
  • Q: How does SBOM relate to VEX? (NEW)
  • Q: How does SBOM relate to the Manufacturer Disclosure Statement for Medical Device Security (MDS2)?
  • Q: How does SBOM relate to OpenC2?
  • Q: How does SBOM relate to Manufacturer Usage Descriptions (MUD)?
  • Q: How does SBOM relate to DBOM?

OVERVIEW

Q: What is an SBOM?

A: A Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components used in building software.

These components, including libraries and modules, can be open source or proprietary, free or paid, and the data can be widely available or access-restricted. For details, see Section 2 of “Framing Software Component Transparency: Establishing a Common Software Bill of Material (SBOM)”: https://ntia.gov/sites/default/files/publications/ntia_sbom_framing_2nd_edition_20211021_0.pdf

Q: Who should have an SBOM?

A: In today’s world, software touches every part of our life and spans across industries, with much of it built on third-party code and open source software. Anyone who is concerned about better supporting their software products internally, supporting their customers, and positively differentiating themselves in the marketplace should consider creating SBOMs and providing them to support their customers. Over time, more SBOM requirements may emerge, such as the FDA’s mandate for medical device manufacturers in the draft Pre-Market Guidance for Cybersecurity: https://www.fda.gov/media/86174/download. For additional information on use cases and benefits of SBOMs, see: https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf

Q: Who uses an SBOM and for what?

A: Most SBOM usage fits under one or more of three perspectives: those who produce software, those who choose software, and those who operate software.

• For those who produce software, SBOMs are used to assist in the building and maintenance of their software, including upstream components.
• For those who choose or purchase software, SBOMs are used to inform pre-purchase assurance, negotiate discounts, or plan implementation strategies.
• For those who operate software, SBOMs are used to inform vulnerability management and asset management, to manage licensing and compliance, and to quickly identify software or component dependencies and supply chain risks.

Q: Can SBOMs be generated at different points in the software lifecycle? (NEW)

A: Yes. SBOMs can be built and are useful at many phases of the development and deployment lifecycle. SBOM types and lifecycle phases are captured and categorized for various creation/enrichment points and related stakeholder methods in this document: https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf

Q: I’m still learning how to make SBOMs. Is it necessary to try to produce all the SBOM types? (NEW)

A: No. All SBOM types are valuable. The various methods of SBOM creation or origin carry different advantages, but can be enriched and enhanced across the software lifecycle. For more information, see: https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf

BENEFITS

Q: What are the benefits of an SBOM?

A: Benefits of SBOMs accrue to both software suppliers and consumers, and are similar for both. They include:

• Identifying and avoiding known vulnerabilities
• Quantifying and managing licenses
• Identifying both security and license compliance requirements
• Enabling quantification of the risks inherent in a software package
• Managing mitigations for vulnerabilities (including patching and compensating controls for new vulnerabilities)
• Lower operating costs due to improved efficiencies and reduced unplanned and unscheduled work.

These benefits can be seen by those who develop software, those who select or purchase software, and those who operate software, across every sector. For a complete discussion of all the benefits, please see the Roles and Benefits for SBOM Across the Supply Chain Report: https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf

Q: How does an SBOM help in the event of a cyberattack?

A: When flaws or vulnerabilities are discovered in a given component, SBOMs are used to quickly identify software that is affected by the vulnerable component, to assess its usage, and to understand the risk introduced by the vulnerable component. The ability to identify vulnerabilities allows software suppliers to produce patches or provide other remediation options; allows consumers to apply mitigations independently of the software supplier; and allows the identification of software that is not affected. This enables focusing on the software that may be affected.

Q: In addition to vulnerability management, how can SBOMs help me?

A: With SBOMs, many parts of the organization – from procurement to operations – have the same understanding of their software assets. The benefits of increased visibility and accountability translate into providing more reliable services to their customers. Better visibility into software allows for additional business advantages such as consolidating assets, licensing clarity, reviewing impact of new policies and regulations and responding in a timely fashion to the ever-changing business environment.

Q: How have bills of material and supply chain transparency been helpful elsewhere?

A: Bills of Materials and supply chain management principles have been transformative to the automotive industry, the food industry, and general manufacturing for decades. Many of these principles were pioneered by Toyota in the 1940s and have been improved continuously across a growing list of industries. A key aspect of this revolution is transparency of the supply chain and knowledge of source, quality, and how to address defects efficiently . A promise of this SBOM initiative is to apply proven supply chain principles to modern software development. In fact, the financial sector has been experimenting with software supply chain transparency since as early as 2013.

---

COMMON MISCONCEPTIONS & CONCERNS

Q: Won’t SBOMs be a “roadmap to the attacker”?

A: Theoretically, yes. In reality, the defensive benefits of transparency far outweigh this common concern as SBOMs serve more as a “roadmap for the defender”. All information is dual-edged, but insufficient software transparency affords attackers asymmetrical advantages.

• First, attackers don’t need SBOMs; mass, indiscriminate attacks like WannaCry serve to remind us that foreknowledge is not a prerequisite to cause harm.
• Second, attackers and their tools can more easily identify software components; conversely, it is often quite challenging, disruptive, inefficient, and even unlawful for defenders to determine the same.
• Third, attackers of any single product can already find human-readable target components – licensing requirements have been increasingly requiring disclosure for decades.

SBOMs seek to level the playing field for defenders by providing additional transparency – at enterprise scale – with standard, machine-readable decision support.

Q: Does an SBOM require source code disclosure?

A: No. Your proprietary source code remains yours to share or to keep confidential at your discretion. Concerns about exposing the internals of your code’s operation are likewise unfounded, as these software components are just “a piece of the puzzle”, not anything close to the “whole completed puzzle” that represents your program.

Q: Does a list of the software components I include expose my intellectual property?

A: No. First, there is a big difference between knowing the 3rd party ingredients and the ultimate recipe or execution. Further, any intellectual property associated with these supply chain components belongs to those upstream, 3rd party, commercial and open source software suppliers. In fact, the licenses those suppliers attached to their components may obligate you to publicly disclose that you include their software in any form.

Q: Does an SBOM increase my exposure to license violations?

A: No. License obligations are incurred whenever licensed software is present and these obligations are independent of SBOMs. SBOMs provide inventory of software that may otherwise be hidden. They therefore make visible potential license violations, and the awareness necessary to mitigate them.

Q: Does an SBOM enable patent or license “trolls”?

A: See: “Does an SBOM increase my exposure to license violations?” above.

Q: Will SBOMs increase my licensing costs or licensing commitments?

A: No. The awareness gained by creating an SBOM allows the manufacturer to address unknown licensing commitments that may be lurking in your programs. This permits the manufacturer to address these issues, either through licensing fees or securing more favorable licensing terms, thus avoiding fines, lawsuits, and licensing commitments such as exposure of your proprietary code.

---

CREATION

Q: Who creates and maintains an SBOM?

A: An SBOM is created and maintained by the producers of software. “Producers” includes manufacturers, suppliers, and individual authors. Ideally, producers assemble SBOMs provided to them by their suppliers; in the absence of SBOM data, producers may have to generate the SBOM data for some components.

Q: What should be included in an SBOM?

A: An SBOM should contain some combination of the following baseline information: author name, supplier name, component name, version string, component hash, unique identifier, and relationship. Licensing, pedigree, provenance, should also be included, if available. For detailed information about SBOM baseline component information, see section 2.2 of “Framing Software Component Transparency: Establishing a Common Software Bill of Material (SBOM)”: https://ntia.gov/sites/default/files/publications/ntia_sbom_framing_2nd_edition_20211021_0.pdf

Q: What data formats exist for conveying SBOM data?

A: There are currently three SBOM formats in common use that support the baseline component information for SBOMs:

• Software Identification (SWID) Tagging https://csrc.nist.gov/projects/Software-Identification-SWID
• Software Package Data Exchange (SPDX) https://spdx.dev/
• Cyclone Dx https://cyclonedx.org/

Additional details about SBOM formats can be found in the Survey of Existing SBOM Formats and Standards: https://ntia.gov/sites/default/files/publications/sbom_formats_survey-version-2021_0.pdf

Q: Are there tools that translate between SBOM formats?

A: Yes. The SBOM community has emphasized the necessity for interoperability between different SBOM data formats. There are tools that translate between the SBOM formats, for example: https://democert.org/sbom/. For additional information about tools for each SBOM format, please see the related link to the draft Formats & Tooling documentation:

• Software Identification (SWID) Tagging http://tiny.cc/SWID
• Software Package Data Exchange (SPDX) http://tiny.cc/SPDX
• Cyclone Dx http://tiny.cc/CycloneDX

Q: When is an SBOM created, changed, or maintained?

A: A new SBOM should be created for every new release of a component. Changes to components require corresponding changes to SBOMs to be valid. For details on when to create an SBOM, see Section 4.2 of “Framing Software Component Transparency: Establishing a Common Software Bill of Material (SBOM)”: https://ntia.gov/sites/default/files/publications/ntia_sbom_framing_2nd_edition_20211021_0.pdf

Q: Some software components are made up of other software components themselves. Can an SBOM show that hierarchy?

A: Yes. SBOMs can provide hierarchical information. Each component that is included in an SBOM should have an SBOM of its own if it also includes components. The SBOMs supplied with each software component taken together represent all levels of the hierarchy required to sufficiently understand the software and its various parts. Such an SBOM is analogous to a manufactured product multilevel bill of materials. https://en.wikipedia.org/wiki/Bill_of_materials#Multi-level_BOM

Q: How deep in the dependency graph should an SBOM enumerate?

A: It depends on the intended audience and the medium of communication. In the case of a machine-readable SBOM, the minimum viable model is one layer deep with the goal of recursing up the supply chain. Many use cases (e.g. the FDA Premarket Submissions for Management of Cybersecurity in Medical Devices) would like to see it as complete as possible, but they understand that complete SBOMs will take time. For most use cases, more complete SBOMs result in greater value.

---

DISTRIBUTION & SHARING

Q: If I make an SBOM, do I have to make it public?

A: No. The act of making an SBOM is separate from sharing it with those who can use this data constructively. The author may advertise and share the SBOM at their discretion. In the case of publicly available open source software, it makes sense to make the SBOM public. In other cases, sector specific regulations or legal requirements may require more or less access to the SBOM. Moreover, SBOM data that is more broadly available is more likely to have a positive impact across the supply chain for the myriad benefits discussed above.

Q: How will SBOM data be shared?

A: Since SBOMs will be used by a wide range of software, in a diversity of contexts, there may not be a single way to share SBOM data. However, the data can be advertised, shared, and access-controlled (if needed) in a set of predictable and discoverable ways, including:

• Distributed with the source or binary
• Manufacturer website
• Some centralized or trusted third party’s website
• Full content from device (e.g. OpenC2)
• Pointer from device (e.g. Manufacturer Usage Description Specification: (https://www.rfc-editor.org/info/rfc8520)
• Human-readable files provided to the purchaser (e.g. OpenChain)

Note the sharing mechanism is independent of who the SBOM is shared with. CISA stakeholders continue to review how SBOM data can be shared effectively.

---

ROLE SPECIFIC

Q: How can SBOMs be leveraged as a Purchaser?

Having an SBOM informs and enables the following, prior to purchasing decisions:

• Catalog various parts of the software and their inter-relationships
• Understand chain of licensing of the software product
• Understand complexity of the software (dates, versions of various parts of the software)

Q: How can SBOMs help an engineer provide surveillance for deployed technology in the field for emerging vulnerabilities?

A: Periodic (ideally automated) comparisons against disclosed vulnerabilities (NVD, Vulners, etc.) can provide an early alert to a potential risk lurking in your environment. A subsequent investigation into the impact of the disclosed vulnerability upon your program can be performed so that, if necessary, a patch can be distributed to the field before your product is ever attacked. This improves customer satisfaction and can improve your position in the market. For additional benefits for engineers and other personas, see: https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf

RELATED EFFORTS / “How does SBOM relate to...”

Q: What is VEX? (NEW)

A: VEX is Vulnerability Exploitability eXchange. VEX provides additional information on whether a product may be affected by a specific vulnerability in software or an included component and, if affected, whether there are actions recommended to remediate. For more information see https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf

Q: What are some uses for VEX? (NEW)

A: VEX provides a lot of flexibility in how it is used to communicate vulnerability information to users. For example, a VEX may be used to assert the vulnerability status for all known vulnerabilities in a given product. Another example is to communicate that a single, high-profile vulnerability isn't applicable to a product. VEX consumers should communicate with their suppliers to understand the specific use that a particular VEX document is meant to achieve. For more information, see https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Aprill2022.pdf

Q: Does SBOM require VEX? (NEW)

A: No. As an inventory and information layer, SBOMs have independent value supporting plural use cases. https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf

Q: What do I need to include when I create a VEX document? (NEW)

A: A VEX document must contain document metadata and at least one VEX statement conveying the status of a vulnerability for one or more products. For details on these fields, see: https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex

Q: What formats exist for a VEX? (NEW)

A: Several formats exist:

• The Common Security Advisory Framework (CSAF), an OASIS standard, provides a VEX profile.
• The CycloneDX SBOM format has provisions for the inclusion of VEX.
• OpenVex is an open source VEX project
• The SPDX SBOM format is in the process of adopting provisions for the inclusion of VEX.

Q: For a VEX statement that says a component is “not_affected”, how can a VEX provide additional information on why it is not affected? (NEW)

A: The goal of VEX is to allow a software supplier or other parties to assert the status of specific vulnerabilities in a particular product. VEX documents may contain a justification statement of why the VEX document creator chose to assert that the product’s status is NOT AFFECTED. For example, for the status justification “component_not_present”, a product written in Python and Elixir does not have any Java code present; therefore, the product could not be affected by the Log4j vulnerability. See https://www.cisa.gov/sites/default/files/publications/VEX_Status_Justification_Jun22.pdf for more information.

Q: How does SBOM relate to VEX? (NEW)

A: An SBOM provides a list of components included in a piece of software. A VEX is an advisory notice that provides context around potential vulnerabilities . VEX can, but is not required to, use SBOM identifiers to refer to products and components. While they are designed to work together, VEX does not require SBOM and SBOM does not require VEX. Because of the increased transparency of SBOMs, VEX is a useful way to communicate with stakeholders at scale.

Q: How does SBOM relate to the Manufacturer Disclosure Statement for Medical Device Security (MDS2)?

A: The Manufacturer Disclosure Statement for Medical Device Security (MDS2) provides medical device manufacturers with a means for disclosing to healthcare providers the security-related features of the medical devices they manufacture.

The working group that established and modified the latest version of the MDS2 were both aware of and participants in the NTIA SBOM multistakeholder process. The SBOM section of the MDS2 was created with these parallel efforts in mind. Where the new MDS2 was published prior to the availability of formal SBOM documentation, it was designed to be flexible enough to accommodate any emerging guidance and standards from the NTIA SBOM multistakeholder process. For additional details, see: https://www.nema.org/standards/view/manufacturer-disclosure-statement-for-medical-device-security

Q: How does SBOM relate to OpenC2?

A: OpenC2 is a standardized language for the command and control of cybersecurity. OpenC2 has commands for obtaining the SBOM of a device, for analyzing the SBOM, and for taking appropriate actions based on the analysis (e.g. connect, patch, sandbox, or block). For additional details, see: https://openc2.org/

Q: How does SBOM relate to Manufacturer Usage Descriptions (MUD)?

A: Manufacturer Usage Descriptions (MUD) describe IoT devices, their capabilities, and their needs. An extension to those descriptions can inform local deployments on how to find an SBOM by pointing to a URL, indicating appropriate local mechanisms, or indicating a point of contact for further information. For additional details, see: https://csrc.nist.gov/publications/detail/sp/1800-15/final

Q: How does SBOM relate to DBOM?

A: DBoM is an open source common backbone for attestation sharing. Use cases include sharing attestations about supply chain data such as SBOMs among supply chain partners. For additional details, see https://dbom.io and/or visit https://github.com/DBOMproject for the open source DBoM Node code and associated documentation.