Software Security in Supply Chains: Vulnerability Management

Vulnerabilities are discovered in a variety of sources. Software developers may find security bugs in already-deployed code. Security researchers and penetration testers may find vulnerabilities by scanning or manually testing software and accessible systems. Effectively identifying, triaging, remediating, and reporting vulnerabilities are central pillars of the EO. In its discussion of Zero Trust Architecture, the EO recognizes that the discovery of vulnerabilities is inevitable, and federal agencies should focus on managing those vulnerabilities efficiently and comprehensively.

Federal agencies should adhere to NIST’s existing Vulnerability Disclosure Program guidance in SP 800-216, Recommendations for Federal Vulnerability Disclosure Guidelines, which addresses reporting, coordinating, publishing, and receiving information about security vulnerabilities. Agencies should require their software suppliers to participate in a Vulnerability Disclosure Program or monitor them as potential risks. Agencies should also require a range of supplier activities and capabilities that enable the comprehensive and timely management of vulnerabilities. For example, agencies may require that suppliers disclose whether provided software components are vulnerable to exploitation through a vulnerability advisory report in an automated and machine-readable format (e.g., Vulnerability Exploitability eXchange [VEX]). Agencies should be able to accept vulnerability advisories in an automated format. 

Per [ISO/IEC 29147], the elements of a vulnerability advisory report include: 

Foundational Capabilities

• Acquiring entities should ensure that third-party suppliers demonstrate their adoption of SSDF V1.1 in the development of software (e.g., effective change control, automation, robust CI/CD, and DevSecOps practices to mitigate and report common vulnerabilities in accordance with RV practices). See the Attesting to Conformity With Secure Software Development Practices section for additional details.
• Acquiring entities should validate that third-party suppliers maintain a formal, publicly available means by which the public can notify the supplier of vulnerabilities.^[1]
• Acquiring entities and third-party suppliers should adhere to ISO/IEC 30111, Information technology — Security techniques — Vulnerability handling processes , and/or ISO/IEC 29147, Information technology — Security techniques — Vulnerability disclosure, as appropriate.

Sustaining Capabilities

• Acquiring entities should engage third-party suppliers who participate in coordinated vulnerability disclosure (CVD) programs to support the timely remediation of vulnerabilities.^[2]
• Acquiring entities should comprehensively integrate SBOMs, vulnerability databases, and other reporting mechanisms to ensure that they rapidly receive notifications of recently released vulnerabilities.

Enhancing Capabilities

• Acquiring entities should prioritize third-party suppliers who staff defined Product Security Incident Response Teams (PSIRTs) and/or internal research teams that are dedicated to the identification, triage, and remediation of vulnerabilities across the supplier’s product and service suite in support of SSDF V1.1 Prepare the Organization (PO) and RV practices.^[3]
• Where possible and appropriate, acquiring entities should require a vulnerability advisory report in an automated and machine-readable format (e.g., VEX).
• Acquiring entities should prioritize suppliers who utilize a formal bug bounty program to incentivize the discovery and proactive remediation of vulnerabilities before adversaries can utilize them, where feasible and legally appropriate.

Content:

• Introduction
• Guidance, Purpose, Scope, and Audience
• EO-Critical Software and Security Measures for EO-Critical Software
• Software Cybersecurity for Producers and Users
  • Attesting to Conformity with Secure Software Development Practices
• Software Verification
• Evolving Standards, Tools, and Recommended Practices
  • Software Bill of Materials (SBOM)
  • Enhanced Vendor Risk Assessments
  • Open Source Software Controls
  • Vulnerability Management
• Additional Existing Industry Standards, Tools, and Recommended Practices
• Frequently Asked Questions (FAQs)