Software supply chain security, SBOMs, and Biden's cybersecurity executive order

The Biden administration’s May 12 executive order on cybersecurity outlined the most comprehensive government policy yet to protect public and private resources from cyber attack, and laid out a number of requirements for federal information systems going forward.

A number of sections of the order require the federal government to modernize security practices, including establishing a review board, developing playbooks, and improved sharing of threat information between agencies (and from private service providers to the agencies they serve).

Section 4, however, addresses software supply chain security. It orders NIST to establish standards, procedures, or criteria regarding:

secure software development environments, including such actions as:

using administratively separate build environments;

auditing trust relationships;

establishing multi-factor, risk-based authentication and conditional access across the enterprise;

documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;

employing encryption for data; and

monitoring operations and alerts and responding to attempted and actual cyber incidents;

generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;

employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;

employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;

providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;

maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;

providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;

participating in a vulnerability disclosure program that includes a reporting and disclosure process;

attesting to conformity with secure software development practices; and

ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

The order also requires contract language ensuring suppliers conform to the NIST requirements, including SBOM. And it further seeks to establish security labeling programs for consumer IoT and software products/services.

SBOM: software bill of materials

The executive order defines the software bill of materials (SBOM) as:

[A] formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.

There are multiple SBOM formats. The NTIA (National Telecommunications and Information Administration) recognizes these three in a recent report:

SPDX is a LinuxFoundation-sponsored SBOM format. This ZDNet story has a lot more coverage of SBOM in the context of the executive order.

Menu

SBOM: software bill of materials