top of page

Software Bill of Materials: Build Trust Through Transparency


What is a SBOM?

A Software Bill of Materials (SBOM) is a formal and machine-readable comprehensive inventory of components, libraries, and dependencies used to create a software application. A well defined SBOM includes both the supplier / manufacturer developed components and third-party components (including purchased software and open-source software), and the upstream software dependencies that are required/depended upon by proprietary, purchased, and open-source software.

A SBOM helps facilitate risk management processes by providing a mechanism to identify software and devices that might be affected by vulnerabilities in the software components, both during development and after it has been deployed.


It includes information on origin, versions, licenses, and other attributes and is a key transparency component in securing the software supply chain.


SBOM benefits for software and device suppliers

  1. Regulatory Compliance: As an example, FDA recommends that premarket submissions include SBOM documentation. Executive Order 14028 is mandating SBOMs for software being sold to the US Government.

  2. Visibility: Easier for developers to understand dependencies across components and deliverables.

  3. Easier to monitor for vulnerabilities: Reduces detection and remediation time. This means quicker response to zero-day vulnerabilities.

  4. Decrease license compliance risk: Manage software licensing (including constraints on use) for included components.

  5. Mitigate component risk: EOL implications, Build “Reject” / “Allow” list of components.

  6. Facilitates open source software usage: Reduce anxiety about using OSS, Increase speed of development, decrease risk.

SBOM benefits for software and device consumers

  1. Addresses reporting and compliance requirements

  2. Risk based decision making

  3. Quicker identification and mitigation to zero-day vulnerabilities

  4. High Assurance: Understand provenance of software components


20 Questions to consider as you build your Software Bill of Materials initiative:


Design

  1. What is the driver of your SBOM program as a software producer?

    1. Baseline inventory of your software dependencies

    2. Customer requirement

    3. Validation of software integrity

    4. Regulatory compliance

    5. License compliance

    6. Vulnerability monitoring and management

    7. All of the above (recommended)

  2. What is the driver of your SBOM program as a software consumer?

    1. Check for “SBOM drift” – Unexpected changes in the contents due to malware

    2. Legal and license compliance

    3. Security analysis

    4. Policy compliance

    5. Customer requirements

    6. Regulatory compliance

  3. When do you generate your SBOM as a producer?

    1. During Build (recommended)

    2. After build process using binary analysis

    3. Not sure

  4. What is the format of your SBOM?

    1. SPDX (most common)

    2. CycloneDX

    3. SWID

    4. Text file

Create

  1. Do you produce SBOM for each product identifying component dependencies?

    1. Yes, for all (recommended)

    2. Only for on-premise software

    3. Only for on-premise and cloud based software

    4. Have not determined the product type scope for SBOM generation process

  2. What dependencies are included as part of the SBOM creation?

    1. Direct dependencies only

    2. Transitive dependencies (recommended)

  3. What is the included as part of your SBOM generation process?

    1. Libraries

    2. Frameworks

    3. Third party components

    4. All of the above (recommended)

  4. Is your SBOM compliant with NTIA minimal requirements for data to be included in the SBOM? (The requirements are higher for FDA pre-market approvals)

    1. Yes (NTIA requirements)

    2. No

    3. Not sure

  5. Do you request SBOMs from suppliers or generate it yourself?

    1. Generate it internally

    2. Request from supplier

    3. Do both (recommended)

    4. Neither

  6. Is SBOM generated automatically as part of your DevOps toolchain?

    1. Yes (preferable)

    2. No

    3. Possibly in the future

  7. How do you validate that SBOM is complete?

  8. Which tool do you use to generate the SBOM as part of the build process?

    1. Microsoft

    2. CycloneDX Maven Plugin

    3. Kubernetes BOM

    4. SPDX SBOM

    5. Syft

    6. Other

    7. Don’t generate SBOM as part of build process.

  9. Which tool do you use to generate the SBOM as part of the post build process?

    1. Synopsys BlackDuck

    2. Jfrog Xray

    3. Snyk

    4. Contrast

    5. FOSSA

    6. MergeBase

    7. other

Manage

  1. Do you have a central repository to manage and store all SBOMs (supplier, internal and externally delivered) across your organization for visibility and compliance purposes?

    1. Yes

    2. No

    3. In process of building

    4. Possibly in the future

  2. What resource do you use to map SBOM components to known vulnerabilities?

    1. Open Source Vulnerability (OSV) database

    2. Github advisory database

    3. NVD

  3. Are you hesitant to share SBOM with your customers due to proprietary information concerns?

    1. Yes

    2. No (industry resistance is declining)

    3. Not sure, still evaluating

  4. Do you generate SBOMs for each build and compare for differences to identify possible tampering?

    1. Yes (Recommended for Malware detection)

    2. No

    3. Possibly in the future

  5. Which tool do you use to consume the SBOMs from your suppliers?

    1. Cybeats

    2. Rezilion

    3. Anchore

  6. How do you securely deliver your SBOMs?

    1. Signed SBOMs (recommended)

    2. Use a decentralized service like SCITT or OSF?

    3. Email

    4. Not sure

Customer Transparency

  1. Do you include exploitable vulnerability information with your SBOM?

    1. Include VEX file (in early stage of adoption)

    2. No

    3. Sometimes


16 views

Σχόλια

bottom of page