How Mayhem Fits Into the Federal Guidance for Securing the Software Supply Chain

In a previous blog post, we looked at the federal government’s recent release of the Securing The Software Supply Chain series, in particular, part one: guidance for developers. 

In this blog post, we’ll take a deeper look at the National Institute of Standards and Technology (NIST) guidance for software development. In particular, we’ll look at PW 8.2 in NIST 800-218 which is cited.

PW 8.2 in NIST 800-218

The NIST 800-218 is a document that describes the Secure Software Development Framework (SSDF), based on established secure software development practice documents. The new Securing the Software Supply Chain Guidance makes numerous references to the document. The practices in NIST 800-218 are organized into four groups, of which, we’ll focus on the Produce Well-Secured Software (PW) group.

Section PW 8 specifically provides recommendations to “help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.” 

Specifically PW 8.2 says developers should “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.” 

PW 8.2 includes nine examples of how developers can use this. One of the recommendations explicitly cites fuzz testing:

1. Perform robust functional testing of security features. 
2. Integrate dynamic vulnerability testing into the project’s automated test suite. 
3. Incorporate tests for previously reported vulnerabilities into the project’s test suite to ensure that errors are not reintroduced. 
4. Take into consideration the infrastructures and technology stacks that the software will be used with in production when developing test plans. 
5. Use fuzz testing tools to find issues with input handling. 
6. If resources are available, use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios. 
7. Identify and record the root causes of discovered issues. 
8. Document lessons learned from code testing in a wiki that developers can access and search. 
9. Use source code, design records, and other resources when developing test plans. 

SAST, DAST, and Mayhem

ForAllSecure supports the guidance from the Enduring Security Framework and PW 8.2 in NIST 800-218. Mayhem as a platform also looks forward to additional guidance as needed in the future.

Clearly, if you have existing SAST and DAST solutions in place, you will need to augment these with fuzz testing. Mayhem provides such automated software testing today.