How Software Bill Of Materials (SBOMs) Support Secure Development

A Software Bill Of Materials, or SBOM is a list of all the "ingredients" required to build and run your software application, along with all the relevant metadata about those ingredients. In other words:

• A complete list of software supply chain dependencies, including all transitive dependencies including shared libraries such as those written in C and other languages.
• Details about each open source and commercial software component, such as the author/vendor, software license, release version, etc.
• A machine-readable format (SPDX) that can enable organizations to automate SBOM consumption, and integrate it with their existing processes.

Like a standard manufacturing Bill Of Materials (BOM), SBOMs are meant to provide detailed information about how to build a product from its component parts. In manufacturing, the BOM lets manufacturers more easily identify and trace defective and non-compliant parts. Similarly, SBOMs let developers more easily identify and trace vulnerable or non-compliant components.

The de-facto industry standard for SBOMs is the Software Package Data Exchange (SPDX) standard, which many consider the "official" standard for SBOMs. However, you should be aware that SPDX is still an evolving standard managed by the Linux Foundation, with the latest release being v2.2.2.

SBOM Legislation

For buyers, SBOM support indicates that the vendor they want to purchase from is serious about supply chain security. This is set to become more and more important due to the recent implementation of US legislation, including the May 2021 Presidential Executive Orderand the Department of Homeland Security (DHS) Software Supply Chain Risk Management Act of 2021 (H.R. 4611). Both directives specify that new and existing US government contractors must provide certification that each software component provided in their contract is free of known vulnerabilities and defects affecting the security of the end product or service.

While these pieces of legislation are only aimed at vendors selling to US government agencies today, what the US government puts forth as a standard today all too often becomes an industry standard in fairly quick order.

The two directives also go so far as to specify the responsibility of the vendor and purchaser:

• Software developers are responsible for maintaining source code security
• Software buyers and operators must:
  • Perform vulnerability and license analysis
  • Evaluate a software product's risk
  • Review potential risks from newly discovered vulnerabilities

Note that compliance with these new mandates also means documenting processes. Security, development, and compliance teams will need to agree on the processes, practices, and documentation that will enable them to implement SBOM compliance.

Risk Management with SBOMs

For many organizations, SBOMs are a new requirement that R&D must learn to effectively incorporate into their Software Development Life Cycle (SDLC) in order to be able to attest to:

• Security Risk
  • For example, outstanding component vulnerabilities should not pose a significant security risk with respect to running the software application.
• License Compliance
  • For example, the overall license of the software application should not be compromised by the individual licenses of the components from which it is built.
• Maintainability
  • For example, individual components should have a history of being well maintained, and should also be reasonably up to date.

Keep in mind that an SBOM does not provide a list of component vulnerabilities, generate a risk or compliance score, or even indicate the datedness of components. However, it does provide key information in a programmatically consumable way (typically JSON, CSV, SPDX or other formats) that can be fed into those processes. For example:

• The name and version of a component listed in an SBOM can be referenced against vulnerability databases like the US Government's National Vulnerability Database (NVD).
• The licenses listed in an SBOM can be compared to the overall license for a product's codebase in order to identify (for example) non-commercially licensed components in a commercially licensed product.
• The name and version of a component can also be used to compare against public repositories to identify how recent a release may be, or whether it's multiple releases behind.

In this way, both the software vendor and the purchasing organization can programmatically pull in an SBOM and generate a risk analysis report specific to their organization's needs.

Programmatic SBOM Generation

The ActiveState Platform's GraphQL API provides programmatic access to detailed information about the runtime environment for your software applications. If you have a configuration file for your Python, Perl or Ruby application, you can simply:

1. Create a runtime environment on demand in just a few minutes.
2. Use the GraphQL API to generate an SBOM for that runtime, which shows:
   • Supplier- the name of the software vendor/author
   • Version- the published version of the component
   • Name- the name of the component
   • Relationship- which component is dependent upon other component(s)
   • License- the high-level license of the component

This feature allows customers to understand and identify all the components in their runtime environments (packages, libraries, dependencies, etc) in order to allow security and compliance personnel to track and audit the software, and satisfy their cybersecurity, legal, and compliance requirements. Reports are generated in either a light-weight JSON, or a signed heavier-weight ISO Standard SPDX v2.2.1 format.

See how it works:

Next steps:

If you'd like to learn more about how you can programmatically generate an SBOM for your software application, Contact Sales

Continue reading:

• Read our blog: President Biden: Secure Your Software Supply Chain
• Read our Data Sheet: Improve Open Source Security With a Bill of Materials
• Read our blog: How to work with GraphQL in Python