Press Release
Integrate a NIST 800-218 “Secure Software Development Framework” Aligned Software Security Program into Your Software Development Lifecycle (SDLC)
The NIST SP 800-218 standard, “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities” was created per direction in the May 2021 Executive Order (EO) 14028 on cybersecurity.
As mandated in the “cybersecurity EO,” the Federal Acquisition Regulation (FAR) Council will soon draft new regulations requiring all software suppliers to the US government to self-attest to compliance with NIST 800-218, released in February 2022.
If your company sells software to the USG, now is the time to carefully evaluate how well your current software security practices and policies align with the SSDF, identify gaps and begin closing them. You’ll also need to carefully document and map your SDLC processes against the SSDF, including documenting gaps and remediation plans (Plans of Action & Milestones). The latter effort is especially important since NIST 800-218 describes high-level best practices that are intended to be customized to your environment and is not a one-size-fits-all checklist.
What is NIST 800-218 designed to achieve?
NIST created its SSDF to achieve multiple goals:
✔ “Shift security left” so that security concerns are addressed sooner and at more points within the SDLC
✔ Reduce the number of vulnerabilities in released software
✔ Reduce the potential impact of unknown vulnerabilities in released software
✔Encourage good practices to reduce the potential for vulnerabilities in future releases
✔ Support software buyers in their due diligence process
Benefits of NIST 800-218 compliance
The ability to demonstrate compliance with NIST 800-218 will soon be a prerequisite for selling software to the USG. Realistically, new FAR (and probably DFARS) clauses will probably in place by early 2023. At that time, federal agencies will begin procuring software contingent on the vendor’s self-attestation or an attestation via a 3rd party of NIST 800-218 compliance.
For many orgs, aligning with the new model will be nontrivial, so there is no time to lose. Attesting to compliance is a claim made in the market, and a failure to back it up could result in prosecution under the whistleblower-friendly False Claims Act.
By moving towards NIST 800-218 compliance now, you can enjoy a competitive advantage as well as reduce the significant business risk associated with vulnerabilities in your software and inadequate protection for your code repositories and SDLC workflows.
A further benefit is that more and more organizations both within and outside the USG software supply chain will evaluate software purchases in relation to alignment with SSDF. Thus, aligning with NIST 800-218 now could help you grow your business and increase market share.
Helping orgs strategize cybersecurity initiatives is what we do.
For over 20 years, Pivot Point Security has helped hundreds of firms to reach their security goals. In this regard, a first step is often to “gap assess” the current environment and offer guidance on the most practical, efficient and cost-effective path to achieving compliance in alignment with your budget and timetable.
Among the benefits of our “as-a-service” model:
✔You can move forward at your own pace with the assurance that you have the staff and expertise you need, when you need it.
✔ You will have the benefit of a clear roadmap to help you stay on target.
✔ You’ll save time and money by leveraging expert guidance, proven processes and prebuilt templates and other artifacts.
✔ You can be confident you’re in compliance with NIST 800-218 and your contract clauses.
✔ You’ll achieve not just a “one-and-done” compliance snapshot but an operationalized process to help ensure ongoing compliance.
FAQ
How is the NIST SSDF organized?
To make the SSDF easier to understand and implement, NIST broke it down into four groups of requirements:
1.Prepare the Organization (PO)
Make sure that the people, processes and technology associated with software development are prepared to develop secure software.
2. Protect the Software (PS)
Protect software from unauthorized access or tampering within code repositories, build/version control tools, DevOps workflows, etc.
3. Produce Well-Secured Software (PS)
Deliver software that has been reviewed, tested and shown to contain minimal security vulnerabilities.
4. Respond to Vulnerabilities (RV)
Identify vulnerabilities in released software and respond appropriately to address them and prevent similar vulnerabilities in the future.
What will NIST SSDF compliance look like for software vendors?
Overall, NIST considers that, “The SSDF’s practices, tasks, and implementation examples represent a starting point to consider; they are meant to be changed and customized, and to evolve over time.”
As such, the SSDF is not a checklist to be rigidly adhered to, but instead provides guidance for planning and implementing a risk-based approach to secure software development in line with each firm’s specific risk profile, the risk profile of the software being developed, etc.
Since the SSDF identifies secure software development practices but doesn’t dictate how to implement them, the compliance focus is likely to be on the outcomes development teams can attest to, rather than on auditing the specific controls and procedures they’ve put in place.
To make the SSDF easier to understand and implement, NIST broke it down into four groups of requirements:
1.Prepare the Organization (PO)
Make sure that the people, processes and technology associated with software development are prepared to develop secure software.
2. Protect the Software (PS)
Protect software from unauthorized access or tampering within code repositories, build/version control tools, DevOps workflows, etc.
3. Produce Well-Secured Software (PS)
Deliver software that has been reviewed, tested and shown to contain minimal security vulnerabilities.
4. Respond to Vulnerabilities (RV)
Identify vulnerabilities in released software and respond appropriately to address them and prevent similar vulnerabilities in the future.
If our SDLC aligns with other software security guidance like the OWASP ASVS, BSIMM or ISO 27034, does that make us SSDF compliant?
Overall, NIST considers that, “The SSDF’s practices, tasks, and implementation examples represent a starting point to consider; they are meant to be changed and customized, and to evolve over time.”
As such, the SSDF is not a checklist to be rigidly adhered to, but instead provides guidance for planning and implementing a risk-based approach to secure software development in line with each firm’s specific risk profile, the risk profile of the software being developed, etc.
If you’ve already applied a trusted software security framework to your SDLC, that will certainly help you achieve SSDF compliance—but it might not get you all the way there. A key first step will be to “gap assess” your current SDLC, policies and procedures against the SSDF.
Who will need to comply first with NIST 800-218?
Overall, NIST considers that, “The SSDF’s practices, tasks, and implementation examples represent a starting point to consider; they are meant to be changed and customized, and to evolve over time.”
As such, the SSDF is not a checklist to be rigidly adhered to, but instead provides guidance for planning and implementing a risk-based approach to secure software development in line with each firm’s specific risk profile, the risk profile of the software being developed, etc.
It is likely that the USG will initially focus its SSDF compliance efforts on larger contractors. These Primes will then become an early driving force motivating their smaller subcontractors to achieve and attest to SSDF compliance via “flowdown” requirements in contracts.
We’re not SSDF compliant but we already have contracts for our software. Will we need to comply?
Overall, NIST considers that, “The SSDF’s practices, tasks, and implementation examples represent a starting point to consider; they are meant to be changed and customized, and to evolve over time.”
As such, the SSDF is not a checklist to be rigidly adhered to, but instead provides guidance for planning and implementing a risk-based approach to secure software development in line with each firm’s specific risk profile, the risk profile of the software being developed, etc.
Unfortunately for current contract holders, the “cybersecurity EO” that mandated the creation of NIST 800-218 and associated FAR changes also authorizes the new FAR clauses to include removing non-compliant software from a wide range of contracts where it is currently specified. Therefore, you will soon need to achieve NIST 800-218 compliance to keep your contracts.
How does the USG define “critical software” and why is that important for SSDF compliance?
Overall, NIST considers that, “The SSDF’s practices, tasks, and implementation examples represent a starting point to consider; they are meant to be changed and customized, and to evolve over time.”
As such, the SSDF is not a checklist to be rigidly adhered to, but instead provides guidance for planning and implementing a risk-based approach to secure software development in line with each firm’s specific risk profile, the risk profile of the software being developed, etc.
Critical software will be the first software types required to comply with the SSDF. According to the “cybersecurity EO,” critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these 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
✔ Operates outside of normal trust boundaries with privileged access
The above definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) purchased for, or deployed in, production systems and used for operational purposes. Other use cases, such as software solely used for research or testing that is not deployed in production systems, are outside of the scope of this definition.