Cybersecurity Technology & Innovation

Buying Down Risk

May 3, 2022

Buying down risk: Software provenance and composition

By Trey Herr, Robert Morgus, Stewart Scott, and Tianjiu Zuo

The complexity of the software supply chain creates risk throughout the cybersecurity ecosystem. Developers stack applications onto existing software: any given product relies on various input/output pipelines, different modules and packages of code stored in or imported from proprietary libraries and open source repositories alike, and an ever-expanding web of products and services. Software is a patchwork of references, imports, original code, and copy-pasted programs. The maintenance practices of each segment can differ wildly. Engineers at massive corporations or a vibrant open source community might regularly review some programs, while long-inactive GitHub accounts or obscure third parties might have abandoned widely used components, and some software might have no clear maintainers at all.

Software supply-chain attacks, an increasingly common and devastating practice, prey on the challenge of identifying and securing the hundreds of components inside and interactions surrounding any given program. These attacks compromise easier-to-breach entities and programs connected to final targets, exploiting the supply chain’s weakest links. They can leverage access to government vendors to steal critical intelligence. They might abuse insecure open source programs to infiltrate a dizzying number of systems. Often, the distance between initial exploit and final victim delays detection for months.

Enter the software bill of materials

Developers can attach to software a Software Bill of Materials (SBoM) to their applications, providing information on component programs and dependencies, including authorship, versioning, program relationships, maintainers, update history, and hashes. Their widespread adoption would make tracking exposure to vulnerabilities relatively straightforward. SBoMs have received notable policy and industry attention. In response to Executive Order 14028, the US Department of Commerce, together with NIST and the National Telecommunications and Information Administration (NTIA) published “The Minimum Elements for an SBoMs” In July. NTIA itself has been working on SBoM development for years now, running two phases of an SBoM proof of concept with medical-device manufacturers and healthcare organizations across a wide multi-stakeholder effort led by Allan Friedman when he served as Director of Cybersecurity Initiatives for NTIA at the Department of Commerce. SBoMs, originally derived from car-manufacturing practices, have a presence in existing industries: the financial sector uses them to gauge the security maturity of software vendors, the energy sector has started including them in contracts, and original implementations helped businesses track licensing throughout supply chains. Throughout industry, there are three prevalent data standards for SBoMs as well as tools for converting among various formats including software package data exchange (SPDX), CycloneDX, and software identification tags (SWID).

Nonetheless, the ecosystem needs further adoption of SBoM and maturation of how the data is used to manage risk. Linux’s SBoM readiness survey indicated gaps in familiarity with, production planning for, and consumption of SBoMs throughout industry. Private-sector responses to NTIA’s SBoM request for information highlight many unaddressed corner cases and ambiguities in its current framing. NTIA’s published minimum elements do not fully address the challenges of comprehensive SBoM coverage and adoption, which include software lacking third-party code, firmware practices, the depth of dependency mapping required, the need for automated SBoM generation and consumption, unique identifiers, clarity on requirements for software-as-a-service (SaaS) providers as opposed to sellers of boxed software and software-license vendors, and more. Respondents also noted tooling gaps hampering SBoM adoption.

Extended applications

SBoMs can provide significantly greater baseline transparency into the software most widely used along with many possible security benefits for software vendors and consumers. Widespread adoption will permit both groups to determine more quickly whether a compromise affects their systems and how, leading to faster and more effective patching practices. Developers will have better insight into their product’s components, allowing for more deliberate security decisions. Customers will be able to outline specific security metrics by requiring or banning components from certain vendors, as well as requiring minimal SBoM completion levels and component-maintenance assurances. Aggregating multiple SBoMs, possibly from the open source ecosystem or within a sufficiently large corporation, would allow for the mapping of larger software environment entanglement. Such maps would provide useful information about critical dependencies used either widely in an ecosystem or in markedly critical systems and products, helping prioritize security decisions.

Recommendations

  1. Develop SBoM tooling: NTIA, which has already led the federal foray into the SBoM space, should coordinate industry input on specific tooling gaps for SBoM standards. Important functionalities to examine include automated generation, integrity signing, update practices, and open source repository offerings. NTIA’s SBoM Tool Classification Taxonomy is a natural starting point for this review, and industry should commit developers and resources towards filling these gaps and open-sourcing the resultant tools.
  2. Begin mapping critical software: Industry should begin generating SBoMs to map the dependencies of important, widely used products, services, and components and use the experience to produce further input and tooling requests. These activities should take place through a variety of mechanisms, including risk assessments led by the OpenSSF and through the JCDC at CISA. These efforts should include work to build a catalog of the most critical open source software, akin to the OpenSSF-supported Census II project with Harvard Laboratory for Innovation Science.
  3. Extend proof-of-concept (PoC) studies from SBoM generation to consumption: Industry and government should coordinate on testing the use of SBoMs for risk assessment and more effective and rapid incident response. CISA’sJoint Cyber Defense Collaborative (JCDC) should, with cooperation from NTIA and the GSA, undertake a proof-of-concept study of government product acquisition with SBoMs and the capabilities they provide for tracking vulnerability exposure and maintenance lifecycles. Large enterprises like Google and Microsoft should conduct similar internal studies in parallel with these efforts. NTIA should use the results of the aggregated research to generate an SBoM-user best-practices guide as a starting point for review and monitoring standards to continue filling tooling gaps.
  4. Identifying systemic risk: Beyond identifying security maturity, patching practices, and dependencies of individual programs and products, SBoMs could be useful in aggregate to identify ecosystem-wide linchpin dependencies that merit extra scrutiny. Leveraging a systemic risk strategy and assessment framework developed by ONCD, CISA, through its National Risk Management Center’s Systemic Cyber Risk Reduction Venture and other appropriate entities, should work with the Analysis & Resilience Center (ARC), a cross-sector nonprofit coalition for mitigating risk in US infrastructure, to coordinate a study of methods for identifying and mapping systemic risk with aggregated SBoM data from federal government and enterprise products across the software ecosystem and publish sanitized results.
    • Clearinghouses: This type of aggregate use-case review would require some centralization of SBoM data. Although this process is more straightforward for open source systems, there are valid concerns about SBoMs revealing proprietary information and providing attackers with a useful tool for identifying vulnerable targets, particularly among software-as-a-service vendors, whose products are otherwise difficult to scrutinize. Industry should work to identify solutions to this information problem; doing so would increase the supply-chain insight SBoMs could provide, potentially by analyzing in-house collections of SBoMs first in their cooperation with the study under ARC.

Related Experts: Trey Herr, Robert Morgus, and Stewart Scott