SBOM is a formal record containing the details and supply chain relationships of various components used in building a software product. SBOM is compared to the Bill of Materials (BOM) for physical goods; however, given the nature of software development (continuous development and updates), SBOM reflects the state of a software product only at a specific point in time.
The SBOM can track and assure its component supply chain (open source or commercial components in the product and their integrity) and evaluate any legal or cyber security risks, such as using an incorrect license or an end-of-life component. SBOM can also be stored as a formal record for monitoring for new zero-day vulnerabilities.
Since its beginning in 2019, the Cybersecurity and Infrastructure Security Agency (CISA) has sought a system to protect Federal Agencies from software supply chain attacks. SBOM has been recommended as a potential solution and was formalized with the White House Executive Order 14028. The initiative has been making its way through different Federal Agencies such as FDA for medical devices, FTC for connected devices, and OMB for software purchases in Federal Agencies. SBOM is also a key pillar of the National Cybersecurity Strategy Implementation Plan for transparency and end-of-life tracking. SBOM compliance is an umbrella term for ensuring organizations can prepare to produce and share SBOM.
SBOM Compliance requires three parts:
1. Build Product SBOM with each release/patch of the product
2. Sign and attest the accuracy of the produced SBOM
3. Share SBOM with the relevant customer or agency
CISA recommends one of the three open formats: CycloneDX, SPDX, and SWID for building SBOM. SBOM generation will vary by the development setup, build environment, and underlying development practices. SBOM can be generated from source code or build and release pipelines. SBOM can also be built by analyzing binary artifacts (SCA) or underlying manifests for artifacts such as container images. CycloneDX and SPDX tools pages are great starting points for several open-source and commercial tool generation tools spanning many development environments.
Some agencies require SBOM to be signed to ensure the integrity of the content. SBOM signing ensures the content of the SBOM has been reviewed and confirmed by the software builder. SBOM can be signed with open source tools such as co-sign for container images or using a commercial certificate such as RSA certificates from CA.
SBOM lists all open source and commercial components and their relationships included in the SBOM along with their versions, licenses, and validating information such as hashes. This should be treated as a sensitive document and shared with care. However, compliance has not explicitly asked for any specific method of sharing, so it is theoretically possible to share via Email or as a Shared document. Interlynk recommends using sharing mechanisms that are verifiable and trackable.
CISA recommends SBOM be used for integrity checking and monitoring applications agencies use for new zero-day vulnerabilities and end-of-life software. This requires SBOM to include a minimum set of elements (NTIA Minimum Elements) and appropriate product and component names (PURL and CPE). Therefore, building SBOM that includes sufficient product and component names, verifying identifiers, and relationships among components is important.
Interlynk is being built by experts in these emerging technologies, and we are happy to answer any questions you might have. Feel free to reach out to us at hello@interlynk.io or via interlynk.io
