With the introduction of the National Cybersecurity Strategy earlier this year, the US Government has started to use its influence and buying power to alter the behavior of all software producers. The US Government is the world’s largest consumer of IT products and services in dollars. It appears they will be using that buying power to add additional cybersecurity requirements for all software purchased. Companies will be faced with the options of changing their behavior or walking away from selling to the federal government.
The National Cybersecurity Strategy makes the case that there must be a shift of the burden for cybersecurity from the consumers of software to the producers of software. We are now seeing indicators of how the US Government intends to drive the changes they believe are necessary. One of the requirements they are implementing is that all software vendors attest that they developed their software in accordance with NIST 800-218, the Secure Software Development Framework, or SSDF. In 2023, they released some draft language to this effect, and requested public input. All indications are that they still intend to implement this requirement, and it no longer a question of if, but when.
I thought I would do a walkthrough of the guidance provided by NIST 800-218, and to highlight where Checkmarx can help our customers to become compliant with it. I’m hesitant to use the term compliance, since if you read the actual language in the SSDF, you will quickly realize that it is a set of principles and guidelines instead of objectively measurable compliance requirements. This is going to make it difficult to verify any company’s attestation to being “compliant” with SSDF, and I do wonder if there will be some additional guidance on how the Government intends to verify compliance.
NIST 800-218 is currently in version 1.1 and came out in February 2022. From a NIST standard point of view, this is current and applies to modern software development life cycle (SDLC). It is also important to note that some in the government describe the SSDF as a best business practice.
This document recommends the Secure Software Development Framework (SSDF) – a core set of high-level secure software development practices that can be integrated into each SDLC implementation.[i]
So, it isn’t a compliance framework – it’s a set of principles that should be followed. This is an important distinction, since Checkmarx primarily supports the implementation of those practices. The practices are implemented through a combination of tools such as Checkmarx, in conjunction with the relevant processes and procedures being put into place.
One of the most interesting aspects of the SSDF, is that NIST went as far as to include Notional Implementation Examples. I love this, as it clearly identifies what at least NIST thinks would be an appropriate implementation. Overall, the SSDF is broken up into four (4) practices: Prepare the Organization (PO), Protect Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Under each practice is a set of tasks, and for each task you will find the notional implementation examples.
If I was the CEO being asked to attest to SSDF compliance, I’d be asking my team to replace the Notional Implementation Examples with our own implementation details. The fuzzy part comes into the subjective assessment around whether your implementation details are sufficient to state that you meet the intent of the task. This may be why we haven’t seen the hard requirements being implemented yet by the government. They must have some concern that vendors will claim compliance to SSDF without an implementation that would be sufficient in the government’s opinion. Given that this will become a contractual obligation at some point, the government is going to have to clarify what is sufficient.
For the rest of this post, I’m going to list out the SSDF Practices and Tasks and provide some insight into how Checkmarx can support SSDF implementation. I’ll offer my standard disclaimer here, “your milage may vary”. It all comes down to how you implement Checkmarx and how you define sufficient. For this blog, I’m going to simply provide if Checkmarx a) Directly Supports, b) Indirectly Supports, and c) Not Applicable.
This assessment is based on all the current capabilities of all the different scanning engines within the Checkmarx One platform, as well as the Checkmarx CodeBashing training application. If any of these components either completely or significantly satisfy the task, then I’ve graded it as Directly Supports. If it helps the customer satisfy the task but is not the major tool to meet the task, I’ve graded it as Indirectly Supports. If the task doesn’t have anything to do with the capabilities of CxOne, I’ve graded it as Not Applicable.
How well CxOne helps you satisfy the SSDF is highly dependent on how you implement CxOne and how as an organization you complete the SSDF tasks.
| Practice/Task | Checkmarx’ Role |
| Prepare the Organization (PO) | |
| Define Security Requirements for Software Development (PO.1) | |
| PO.1.1: Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time. | Indirectly Supports |
| PO.1.2: Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time. | Indirectly Supports |
| PO.1.3: Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software. [Formerly PW.3.1] | Not Applicable |
| Implement Roles and Responsibilities (PO.2) | |
| PO.2.1: Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC. Periodically review and maintain the defined roles and responsibilities, updating them as needed. | Not Applicable |
| PO.2.2: Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed. | Directly Supports |
| PO.2.3: Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development related roles and responsibilities. | Not Applicable |
| Implement Supporting Toolchains (PO.3) | |
| PO.3.1: Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other. | Indirectly Supports |
| PO.3.2: Follow recommended security practices to deploy, operate, and maintain tools and toolchains. | Directly Supports |
| PO.3.3: Configure tools to generate artifacts of their support of secure software development practices as defined by the organization. | Directly Supports |
| Define and Use Criteria for Software Security Checks (PO.4) | |
| PO.4.1: Define criteria for software security checks and track throughout the SDLC. | Directly Supports |
| PO.4.2: Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria. | Directly Supports |
| Implement and Maintain Secure Environments for Software Development (PO.5) | |
| PO.5.1: Separate and protect each environment involved in software development. | Not Applicable |
| PO.5.2: Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach. | Not Applicable |
| Protect Software (PS) | |
| Protect All Forms of Code from Unauthorized Access and Tampering (PS.1) | |
| PS.1.1: Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access. | Not Applicable |
| Provide a Mechanism for Verifying Software Release Integrity (PS.2) | |
| PS.2.1: Make software integrity verification information available to software acquirers. | Not Applicable |
| Archive and Protect Each Software Release (PS.3) | |
| PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release. | Not Applicable |
| PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]). | Directly Supports |
| Produce Well-Secured Software (PW) | |
| Design Software to Meet Security Requirements and Mitigate Security Risks (PW.1) | |
| PW.1.1: Use forms of risk modeling – such as threat modeling, attack modeling, or attack surface mapping – to help assess the security risk for the software. | Indirectly Supports |
| PW.1.2: Track and maintain the software’s security requirements, risks, and design decisions. | Directly Supports |
| PW.1.3: Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services. [Formerly PW.4.3] | Not Applicable |
| Review the Software Design to Verify Compliance with Security Requirements and Risk Information (PW.2) | |
| PW.2.1: Have 1) a qualified person (or people) who were not involved with the design and/or 2) automated processes instantiated in the toolchain review the software design to confirm and enforce that it meets all of the security requirements and satisfactorily addresses the identified risk information. | Indirectly Supports |
| Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality (PW.4) | |
| PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, opensource, and other third-party developers for use by the organization’s software. | Indirectly Supports |
| PW.4.2: Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components. | Indirectly Supports |
| PW.4.4: Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles. | Directly Supports |
| Create Source Code by Adhering to Secure Coding Practices (PW.5) | |
| PW.5.1: Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements. | Directly Supports |
| Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security (PW.6) | |
| PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security. | Not Applicable |
| PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. | Not Applicable |
| Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.7) | |
| PW.7.1: Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization. | Directly Supports |
| PW.7.2: Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system. | Directly Supports |
| Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.8) | |
| PW.8.1: Determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing and, if so, which types of testing should be used. | Directly Supports |
| PW.8.2: Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system. | Directly Supports |
| Configure Software to Have Secure Settings by Default (PW.9) | |
| PW.9.1: Define a secure baseline by determining how to configure each setting that has an effect on security or a security-related setting so that the default settings are secure and do not weaken the security functions provided by the platform, network infrastructure, or services. | Indirectly Supports |
| PW.9.2: Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators. | Not Applicable |
| Respond to Vulnerabilities (RV) | |
| Identify and Confirm Vulnerabilities on an Ongoing Basis (RV.1) | |
| RV.1.1: Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports. | Directly Supports |
| RV.1.2: Review, analyze, and/or test the software’s code to identify or confirm the presence of previously undetected vulnerabilities. | Directly Supports |
| RV.1.3: Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy. | Not Applicable |
| Assess, Prioritize, and Remediate Vulnerabilities (RV.2) | |
| RV.2.1: Analyze each vulnerability to gather sufficient information about risk to plan its remediation or other risk response. | Directly Supports |
| RV.2.2: Plan and implement risk responses for vulnerabilities. | Directly Supports |
| Analyze Vulnerabilities to Identify Their Root Causes (RV.3) | |
| RV.3.1: Analyze identified vulnerabilities to determine their root causes. | Indirectly Supports |
| RV.3.2: Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently. | Indirectly Supports |
| RV.3.3: Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, and proactively fix them rather than waiting for external reports. | Directly Supports |
| RV.3.4: Review the SDLC process, and update it if appropriate to prevent (or reduce the likelihood of) the root cause recurring in updates to the software or in new software that is created. | Not Applicable |
So, as shown above Checkmarx has the ability to significantly assist any software developer in meeting the requirements defined in NIST 800-218. As always, implementation matters in how well Checkmarx supports a developer, but that is for a later discussion. If you have any questions on this or would like to have a deeper discussion on implementation in support of SSDF, please reach out to us.
[i] From NIST 800-218, Abstract