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. 

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

Never miss an update. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to
the processing of my personal data as described therein. By clicking submit below, you consent to allow Checkmarx
to store and process the personal information submitted above to provide you the content requested.