On September 14, 2022, the Office of Management and Budget (OMB) issued much-anticipated guidance on the implementation of Secure Software Development Framework (SSDF) requirements for contractors (The “Guidance Memo”). In short: “Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the National Institute of Standards and Technology (NIST) Guidance.” In a prior article, we describe the practices and controls companies will need to implement as part of the SSDF.

The Guidance Memo mandates a two-pronged approach to ensuring software supplied to the U.S. Government is developed in a secure manner. First, for critical software, the Guidance Memo requires agencies to collect self-attestations by June 2023. As described in the Guidance Memo, for critical software, agencies may require third-party assessment of the software, to be conducted by a FedRAMP Third Party Assessor Organization (3PAO) or another assessor the agency deems fit.

For all other software, the Guidance Memo requires agencies to implement procurement practices requiring self-attestation by software suppliers that the software supplied to U.S. Government agencies is developed in compliance with the SSDF.  

The Guidance Memo directs agencies to apply guidance contained therein to (i) acquired software that is developed after September 14, 2022 (the “Effective Date”), (ii) usage of already acquired software that is modified by Major version changes after the Effective Date, and (iii) usage of software purchased through contracts renewed after the Effective Date.

Producers providing software to the U.S. government should carefully review the Guidance Memo to understand the rollout of SSDF requirements. Importantly, vendors should anticipate further guidance and/or communications from U.S. government customers by late December 2022 regarding whether software supplied is considered critical software. Software vendors should further review and implement the SSDF as quickly as possible, given the U.S. government’s intent to start collecting attestations for critical software by June 2023 and for all other software by September 2023. These due dates provided in the Guidance Memo for SSDF compliance represent a rapidly approaching schedule and should inspire immediate action from software producers.

Figure 1: Key Dates for SSDF Implementation Critical Events

Context

In May 2021, President Biden issued Executive Order 14028, “Improving the Nation’s Cybersecurity,” requiring an update to the Federal Acquisition Regulatory (FAR) to direct agencies to include cybersecurity requirements in acquisition contracts.

The Executive Order established four main initiatives relating to supply chain cybersecurity: (i) establishing best practices; (ii) identification of critical software; (iii) an update of FAR; (iv) and IoT security labeling. NIST, tasked with addressing the first initiative, published the SSDF in February of 2022 in NIST Special Publication (SP) 800-218.

Note, “software” under Executive Order 14028 includes “firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.” This definition is broader than the general industry understanding of the term, specifically as it pertains to firmware and items that contain software. It is important for manufacturers of products that contain software to engage with their supply chain to ensure it is complying with the SSDF.

NIST defines critical software as having one or more of the following attributes: “is designed to run with elevated privilege or manage privileges; has direct or privileged access to networking or computing resources; is designed to control access to data or operational technology; performs a function critical to trust; or operates outside of normal trust boundaries with privileged access.”

Figure 2 details the historical timeline of U.S. government publications related to the rollout of the SSDF.

SSDF Requirements

As discussed in our previous article, NIST SP 800-218v1.1, The Secure Software Development Framework (SSDF), was written to establish standards for secure development of software through the full Software Development Life Cycle (SDLC). The objective of the SSDF is to “shift security left” in the SDLC, and to incorporate security considerations early and often throughout the software suppliers’ internal software development processes.

The SSDF is organized along key practices, tasks supporting these practices, notional Implementation examples for such tasks, and references:

• Practices – There are 19 high-level organizational outcomes resulting from implementing various tasks, which are organized into the following four (4) groups.

  • Prepare the Organization (PO) – Practices designed to ensure that people, processes, and technology are prepared to perform secure software development.

  • Protect the Software (PS) – Practices designed to protect all software components from tampering or unauthorized access.

  • Produce Well-Secured Software (PW) – Practices designed to produce well-secured software with minimal security vulnerabilities.

  • Respond to Vulnerabilities (RV) – Practices to identify residual vulnerabilities in software releases and to respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

• Tasks – 42 specific activities to be performed by organization personnel to perform the 19 practices.

• Notional Implementation Examples – Examples of potential tools, processes, or other methods that could be used to implement a task.

• References – References to similar or source controls from other established frameworks such as NIST SP 800-53, ISO/IEC 27001, OWASP, NIST CSF, etc.

Self-Attestations and SSDF Compliance

Pursuant to the Guidance Memo, before agencies can use a software producer’s product, the software producer must provide a self-attestation that their software complies with the SSDF. It explicitly references a “conformance statement” as described by the NIST guidance. This includes:

• Software producer’s name;

• A description of which product(s) the statement refers to (preferably focused at the company or product line level and inclusive of all unclassified products sold to federal agencies);

• A statement attesting that the software producer follows secure development practices and tasks that are itemized in the standard self-attestation form;

• Self-attestation is the minimum level required; however, agencies may make risk-based determinations that a third-party assessment is required due to the criticality of the service or product that is being acquired, as defined in the M-21-30 memo.

The Guidance Memo notes the FAR Council plans to promulgate a rule that creates a standardized attestation form.

NIST has some resources on how to conduct a self-assessment:

• ABC's of Conformity Assessment (NIST SP 2000-01);

• Conformity Assessment Considerations for Federal Agencies (NIST SP 2000-02);

• Conformity assessment: vocabulary and general principles (ISO/IEC 17000:2020);

• Optional spreadsheet to organize compliance recordation.

Should the software producer not be able to comply with the SSDF in its entirety at the time of attestation, it must create a Plan of Actions and Milestones (POA&M) to achieve SSDF compliance. The software producer must clearly identify which provisions of the SSDF it cannot meet, explain how compensating controls mitigate risk, and indicate a timeline for remediation. Additionally, the producer must maintain the confidentiality of these conformity gaps and not post this documentation publicly. Limited in duration and scope, waivers may be granted in exceptional circumstances.

Impact on Software Producers

• Impacted software producers must react and respond to the requirements set forth in the NIST SSDF within the timeline listed above. To ensure success, the following steps are recommended to initiate the process for impacted companies.

Figure 3: Recommended Preparation for SSDF Compliance Self-Attestation

The engagement of company leadership is integral to successful SSDF compliance. Software producers can use several methods to organize compliance efforts including the development of a Change Management Board or a Compliance Program Office to ensure compliance goals are achieved. Companies should identify and engage stakeholders from all relevant business areas (e.g., engineering, supply chain, quality assurance, legal, etc.) when aligning development practices to SSDF requirements.

The Guidance Memo also clarifies that agencies have the discretion to require a Software Bill of Materials (SBOM) or other artifacts proving compliance, but they are not required to do so. An SBOM “provides those who produce, purchase, and operate software with information that enhances their understanding of the supply chain” (Source | NTIA).

Additionally, the National Telecommunications and Information Administration (NTIA), housed in the Department of Commerce, published minimum requirements for an SBOM pursuant to Executive Order 14028.

(Source|NTIA)

Claire Newsome, Senior Associate at Ankura, also contributed to this article.