Early in 2020, threat actors penetrated the software systems of SolarWinds and injected malicious code into its servers. Around March, the company, which provides a platform solution for managing information technology resources, began sending out updates infected with the bad code to its customers. That code created back doors to those customers' information technology systems, allowing more malware to be installed on them.
Before SolarWinds realized what had happened, 18,000 of its customers had installed the infected software on their systems. In an era when data breaches expose millions of records, 18,000 may not sound like a lot, but the number doesn't tell the whole story. Many of those customers were high-profile Fortune 500 companies and government agencies overseeing highly sensitive information. They included Microsoft, Cisco, Intel, and Deloitte, as well as parts of the Pentagon, the Department of Homeland Security, the National Nuclear Security Administration, and the US Treasury.
Wanting to prevent federal agencies from being victimized by similar supply chain attacks in the future, the Biden administration in May 2021 issued an executive order (EO) on cybersecurity, with subsequent guidelines released in July by the US Commerce Department's National Telecommunications and Information Administration (NTIA).
Among the provisions in the EO is a requirement that federal agencies purchasing software be provided a software bill of materials (SBOM) for that software or that the BOM be published at a public website. By requiring an SBOM from software providers, the EO recognizes how software is put together today and acknowledges that, while most organizations make great efforts to keep their physical supply chains secure and safe, they do very little to evaluate the safety and security of their software supply chains.
Here's what your team needs to know.
Defining SBOMs
The EO defines an SBOM as "a formal record containing the details and supply chain relationships of various components used in building software."
The order explains that software developers and vendors often create products by assembling existing open-source and commercial software components. The SBOM enumerates those components in a product.
The SBOM is like a list of ingredients on food packaging, the order notes, and is valuable to both the software builder and the buyer. An SBOM allows the builder to make sure any open-source and third-party software components it's using are up to date. If the components contain any vulnerabilities, the software builder can quickly respond to them.
Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Once a buyer becomes an operator of the software, it uses an SBOM to quickly and easily determine whether it is at potential risk of a newly discovered vulnerability.
The EO also offers a couple of tips for agencies that want to get the most out of the SBOMs they receive from software vendors. Make sure the SBOM is in a widely used machine-readable format in order to reap the benefits of automation and tool integration.
SBOMs will also be more valuable to an agency if they can be collectively stored in a repository where they can be 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," the EO states.
Elements of an SBOM
Following a mandate in the executive order, the NTIA on July 12 further refined what should be in an SBOM when it released its "Minimum Elements for a Software Bill of Materials" (PDF).
"An SBOM provides those who produce, purchase, and operate software with information that enhances their understanding of the supply chain," the agency explained in a statement.
"Though an SBOM won’t solve all software security problems, it offers the potential to track known newly emerged vulnerabilities and risks, and it can form a foundational data layer on which further security tools, practices, and assurances can be built," it added.
The document defines the essential pieces that support basic SBOM functionality and provide a foundation for an evolving approach to software transparency. It also looks beyond minimum SBOM elements to future features and advances that could become priorities for further work.
Minimum elements are organized around three broad areas:
1. Data fields
This area covers baseline information about each component that should be tracked in an SBOM. The goal of these fields is to enable sufficient identification of these components to track them across the software supply chain and map them to other beneficial sources of data, such as vulnerability databases or license databases. Fields includes supplier, component name, component version, any unique identifiers, dependency relationships, author of data, and timestamp.
2. Automation support
Automation is important not only to generate accurate and comprehensive SBOMs, but also for sharing the information created for them. It creates the ability to scale across the software ecosystem, particularly across organizational boundaries. Taking advantage of SBOM data will require tooling, which necessitates predictable implementation and data formats. SBOMs must be in one of three data formats identified in the document: Software Package Data eXchange (SPDX), CycloneDX, or Software Identification (SWID) tags.
3. Practices and processes
These are necessary to integrate a SBOM into the secure development lifecycle. It includes practices such as frequency (if the software component is updated with a new build or release, a new SBOM must be created to reflect the new version of the software) and depth (all top-level components, with all their transitive dependencies should be listed in the SBOM). It should also include processes such as distribution and delivery (appropriate access permissions and roles must be in place so SBOM data is available in a timely fashion to only those who need it).
A new foundation
Although the executive order and NTIA document apply only to contractors doing business with the federal government, the potential exists for a broader impact. SBOMs aren't new to the industry, but a clear definition of what should be in them has been missing in the past.
By establishing guidelines for SBOMs that could be adopted across the software industry, the US federal government may be able to establish a foundation for better securing software supply chains everywhere.
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
