Addressing software supply chain risk
Secure software supply chain recommendations
Review, summary, highlights, and analysis of USG based on ongoing analysis and summarization of cross-USG policy on software supply chain security.A joint initiative brought to you by Manifest, OP4, SelecTech and TestifySec
EXEcutive summary
The goal of this document
Executive Order 14028, OMB memos, and various DoD and FCEB agency policies and guidelines are creating a burning platform for USG cybersecurity practitioners to require SBOMs from their vendors and industry partners.This document represents recommendations from public- and private-sector experts based on a review and analysis of software supply chain policy, guidance, and regulation across USG.This document will:
(1) provide highlights of ongoing relevant regulation, guidance, and policy across USG
(2) outline policy-based and policy-backed recommendations for entities across USG to enact compliant software supply chain security programs and policies, and procure COTS tooling to facilitate these initiatives.
Recommendations for software
supply chain solutions
SBOMs across USG
This document represents recommendations from public- and private-sector experts based on a review and analysis of software supply chain policy, guidance, and regulation across USG.Executive Order 14028, OMB memos, and various DoD and FCEB agency policies and guidelines are creating a burning platform for USG cybersecurity practitioners to require SBOMs from their vendors and industry partners.Such efforts should be automated wherever possible, scalable to the largest agencies/branches, and combined with other artifacts such as Secure Software Development Attestation Forms (SSDAF).
Considerations for tooling
SBOM Market Research
In an effort to aid USG practitioners charged with implementing SBOM programs, we have developed the below research guide informed by our collective years of experience with SBOM management, software deployment within USG, and industry guidelines:
Recommendations
Implications for acquisition and program management
Our reading of these legislative artifacts (with full analysis on subsequent pages) suggests that there are several implications for those subject to SBOM legislative requirements:1. Require SBOMs for all new and existing software vendors. This should include companies on SBIRs, STTRs, or any other innovation grant.Policy guidance should stipulate the preferred SBOM formats (e.g. CycloneDX and SPDX), and the requirements that SBOMs should be generated and provided by vendors any time new software is provided. This includes upgrade, patches, hot-fixes, etc.2. Include SBOM vulnerability analysis as part of vendor evaluations. SBOMs provide quantitative data about the security practices of the vendor, and the risk taken on by USG in procuring that software. Vendors with products that have less risky SBOMs should be favored during procurement.3. AO's should also require SBOMs as part of any ATO package, including for internally-developed software. SBOMs are part of recent DoD DevSecOps best practices, and are being built into Rapid-ATO and Continuous-ATO processes.
policy deep dive
executive order 14028
Executive Order 14028 ("Executive Order on Improving the Nation’s Cybersecurity"), signed by President Biden on May 12, 2021, contained many provisions across a variety of cybersecurity fields and practices.Its full text is available here, and a table summarizing key software supply chain provisions is below:
| Section | Text | Consortium Interpretation and Recommendations |
|---|---|---|
| 4.f | "Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM." | Affected agencies shall take note of the minimum SBOM elements, available here. Affected agencies shall ensure they have capabilities in place to assess the compliance of vendor SBOMs with these minimum required elements. |
| 4.g | "Within 45 days of the date of this order, the Secretary of Commerce, acting through the Director of NIST, in consultation with the Secretary of Defense acting through the Director of the NSA, the Secretary of Homeland Security acting through the Director of CISA, the Director of OMB, and the Director of National Intelligence, shall publish a definition of the term “critical software” for inclusion in the guidance issued pursuant to subsection (e) of this section. That definition shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised." | Affected agencies may want to familarize themselves with NIST's definition of critical software, available here |
| 4.p | "Following the issuance of any final rule amending the FAR as described in subsection (o) of this section, agencies shall, as appropriate and consistent with applicable law, remove software products that do not meet the requirements of the amended FAR from all indefinite delivery indefinite quantity contracts; Federal Supply Schedules; Federal Government-wide Acquisition Contracts; Blanket Purchase Agreements; and Multiple Award Contracts." | Affected agencies may want to develop processes and adopt capabilities to assess vendor compliance with SBOM requirements. |
policy deep dive
OMB Memo 22-18
OMB Memo M-22-18, issued on September 14, 2022, introduced the concept of a Secure Software Development Attestation Form. We within this consortium use the acronym SSDAF for short.Its full text is available here, and a table summarizing key software supply chain provisions is below:
| Section | Text | Consortium Interpretation and Recommendations |
|---|---|---|
| II.1 | "Consistent with the NIST Guidance and by the timelines identified below, agencies are required to obtain a self-attestation from the software producer before using the software... The agency must obtain a self-attestation for all third-party software subject to the requirements of this memorandum used by the agency, including software renewals and major version changes." | Affected agencies may want to begin adopting policies and tooling to solicit and collect self-attestations for all third-party software subject to the requirements. |
| II.1.a.ii | "If the software producer cannot attest to one or more practices from the NIST Guidance identified in the standard self-attestation form, the requesting agency shall require the software producer to identify those practices to which they cannot attest, document practices they have in place to mitigate those risks, and require a Plan of Action & Milestones (POA&M) to be developed. The agency shall take appropriate steps to ensure that such documentation is not posted publicly, either by the vendor or by the agency itself. If the software producer supplies that documentation and the agency finds it satisfactory, the agency may use the software despite the producer’s inability to provide a complete self-attestation." | Affected agencies may need to institute programs to manage Plan of Action & Milestones (POA&M) for non-compliant vendors. |
| II.1.b | "The agency shall retain the self-attestation document, unless the software producer posts it publicly and provides a link to the posting as part of its proposal response." | Affected agencies may want to adopt a dedicated self-attestation form repository for the safeguarding and retention of these artifacts. |
| II.2.a | "A Software Bill of Materials (SBOMs) may be required by the agency in solicitation requirements, based on the criticality of the software as defined in M21-30, or as determined by the agency. If required, the SBOM shall be retained by the agency, unless the software producer posts it publicly and provides a link to that posting to the agency." | Affected agencies may want to begin requiring SBOMs from their software vendors based on criticality. Affected agencies may also want to adopt an SBOM repository for the consumption, retention, analysis, and persistent monitoring of those SBOMs. |
| II.2.e | "Evidence that the software producer participates in a Vulnerability Disclosure Program may be required by the agency." | Affected agencies may need to confirm with their vendors that they participate in a Vulnerability Disclosure Program. |
| II.2.f | "Agencies are encouraged to notify potential vendors of requirements as early in the acquisition process as feasible, including leveraging pre-solicitation activities." | Affected agencies may need to inform affected vendors and adapt their procurement processes, including with contract language or other communications. Affected agencies may want to consider SBOM and Secure Software Development Attestation Form solutions that offer playbooks, informal guidance, or other support for the collection of these artifacts from third parties. |
| III.A.1 | "Within 90 days of the date of this memorandum, agencies shall inventory all software subject to the requirements of this memorandum, with a separate inventory for “critical software.” " | Affected agencies may need to (if they haven't already) categorize their software by criticality. Guidelines for what constitutes critical software is defined in M-21-30 and itself refers to NIST's definition, available here. |
| III.A.2 | "Within 120 days of the date of this memorandum, agencies shall develop a consistent process to communicate relevant requirements in this memorandum to vendors, and ensure attestation letters not posted publicly by software providers are collected in one central agency system." | Affected agencies may need to (if they have not already) develop a process for communicating with vendors. Affected agencies may want to consider SBOM and artifact solutions that have vendor artifact upload portals. |
| III.A.3 | "Agencies shall collect attestation letters not posted publicly by software providers for “critical software” subject to the requirements of this memorandum within 270 days after publication of this memorandum." | Affected agencies may want to begin collecting secure software development attestation forms from critical software vendors. |
| III.A.4 | "Agencies shall collect attestation letters not posted publicly by software providers for all software subject to the requirements of this memorandum within 365 days after publication of this memorandum." | Affected agencies may want to begin collecting secure software development attestation forms from all software vendors. |
| III.A.5 | "Within 180 days of the date of this memorandum, agency CIOs, in coordination with agency requiring activities and agency CAOs, shall assess organizational training needs and develop training plans for the review and validation of full attestation documents and artifacts." | Affected agencies may want to begin training personnel on the review and validation of attestation documents and artifacts. Affected agencies may want to consider solutions that contain document review and approval/rejection capabilities. |
policy deep dive
M-23-16
OMB Memo M-23-16, issued on June 9 2023, revised timelines and provided additional clarity on M-22-18.Its full text is available here, and a table summarizing key software supply chain provisions is below:
| Section | Text | Consortium Interpretation and Recommendations |
|---|---|---|
| Appendix A | "Agencies shall collect attestation letters for “critical software” subject to the requirements of M-22-18, as amended by this memorandum." | Affected agencies may want to begin collecting secure software development attestation forms from critical software vendors. |
| Appendix A | "Agencies shall collect attestation letters for all software subject to the requirements of M-22-18, as amended by this memorandum." | Affected agencies may want to begin collecting secure software development attestation forms from all software vendors. |
technical deep dive
SBOM Minimum elements
An SBOM benefits creators, buyers, and users of software by offering insights into the software ecosystem and supporting a range of applications and stakeholders. This includes its use for managing inventory, vulnerabilities, and licenses by those who produce and manage software, as well as for conducting risk assessments, including license and vulnerability analysis, by buyers.
| Required Fields |
|---|
| Supplier Name |
| Component Name |
| Version of the Component |
| Other Unique Identifiers |
| Dependency Relationship |
| Author of the SBOM Data |
| Timestamp |
| Recommended Fields |
|---|
| Hash of the Component |
| Lifecycle Phase |
| Other Component Relationships |
| License Information |
Although including License Information isn't mandatory, it's widely regarded as a best practice, particularly for open-source software.An SBOM is pivotal for monitoring changes in software components, including alterations in their licensing agreements. This is because an SBOM provides a detailed inventory of every component used in the software, including their version numbers and licensing information.When a software component is updated and its license changes—a scenario that can significantly affect compliance and risk management—the SBOM can quickly alert users to these changes. By comparing the licensing information of each component between versions of the software, stakeholders can easily detect any modifications in the licensing terms. This capability is particularly useful in open-source software, where license compatibility is a major consideration for both compliance and the ethical use of open-source projects. The proactive detection of license changes through an SBOM enables organizations to adjust their usage practices or seek alternatives to maintain compliance and mitigate legal and operational risks.
policy deep dive
NIST Special Publication
800 NIST SP 800-204D
NIST Special Publication 800 NIST SP 800-204D Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines 2.1 identifies two primary risks associated with software supply chain security:
| Risk |
|---|
| SSC attacks such as but not limited to: (1) Subverting, removing, or introducing a step within the SSC to maliciously modify or sabotage the resulting software product (2) Stealing credentials from the build system to mint and sign unauthorized malicious software (3) Causing naming collisions |
| SSC security should also account for discovering and tracking software security defects rather than simply mitigating attacks |
For this process to work effectively, it's essential that the software bill of materials (SBOM) is provided to end users, enabling them to compile inventories of the software components used. This approach involves creating an SBOM from the initial commit, which helps in recognizing and addressing potential risks associated with both upstream and downstream dependencies.5.1 in the guidance calls for support in infrastructure for generating evidence such as SBOMs, directly in the CI pipeline itself.While license information is not “mandated” in either document, it may make sense to mandate the inclusion of license information when SBOMs are generated to assist with compliance.
policy deep dive
NIST SP 800-53r5
NIST SP 800-53r5 Security and Privacy Controls for Information Systems and Organizations contains several relevant sections for USG practitioners:
| CM | Content |
|---|---|
| CM-8 System Component Inventory | This section explicitly calls for an inventory which includes the following verbiage: “The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, hardware inventory specifications, software license information, and for networked components, the machine names and network addresses across all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include date of receipt, cost, model, serial number, manufacturer, supplier information, component type, and physical location.” |
| CM-10 Software Usage Restrictions | This section explicitly calls out that software usage will be in accordance with contractual law. Software Licenses and associated processes for the management of such licenses is mandated. |
| CP-9 System Backup | This section explicitly calls for backing up system level properties which includes licensing. |
When combining these three together the desired effect is:1) NIST SP 800-53r5 mandates the use of software license inventory and tracking.
2) SBOM Minimum Elements doesn’t require license in the minimum elements, but strongly encourages its inclusion.
3) NIST SP 800-204D provides a plausible path to automate the inclusion and policy enforcement of licenses. A disallowed license could, by policy, trigger a failure of the pipeline with a clear message that the expected agreed upon licenses have changed for software libraries. It also provides a path for consumers to receive license metadata for possible enforcement during delivery and deployment of artifacts in the CI/CD through the use of SBOMs enhanced with license information.A clear path is provided for producing license tracking, automated through CI/CD pipelines, and enforceable both at compile and deploy time. The guidance from NIST and NTIA clearly supports this path.
Stay Informed
Join the mailing list
If you are interested in scheduling a briefing or a discussion around software supply chain security initiatives within the United States Government, please get in touch using the link below.
Brought to you by Manifest, OP4, SelecTech, and TestifySec