Fuzzing with Biden's Executive Order 14028

After President Biden issued an Executive Order 14028 to improve the Nation’s cybersecurity posture, the National Institute of Standards and Technology (NIST) published the minimum recommendations for verification of code by developers. In this list, there are different techniques listed under various classes, such as: Automated Testing, Run with built-in checks and protections, Black Box Test Cases, and Fuzzing. Fortunately, Mayhem can help both security engineers and developers validate many of these techniques. Let me walk you through a few of these cases.

Under the Automated Testing class, Mayhem can help by integrating into your existing code pipelines.

• Section 2.2 states that "Automated testing can run tests consistently, check results accurately, and minimize the need for human effort and expertise." This is the main use case for Mayhem, to help expert security engineers and PenTesters with automatically running test cases that Mayhem generates when validating your applications. Mayhem generates an extensive test suite that, later on, can be used to sanity check both new and existing codes automatically. This process can also be integrated easily into any existing CI pipeline.

Under the Dynamic Analysis class, Mayhem can help with many sections: 

• Section 2.5 states that programming languages, both compiled and interpreted, provide many built-in checks and protections. This is the first step that Mayhem verifies and displays that your binary was compiled with four built-in checks and protections: ASLR, Fortify Source, StackGuard, and Data Execution Prevention (DEP). When your binaries are compiled with either or all of these built-in protections, it will make it much harder for bad actors to exploit any vulnerabilities. Mayhem automatically notifies you if your application is not protected with any of these checks.
• Section 2.6 recommends creating Black Box tests. The Mayhem Fuzzing Engine will help with negative tests, using invalid inputs and testing what the software should not do, input boundary analysis, and input combinations. Mayhem uses advanced coverage-guided fuzzing technique to generate and run the negative test cases. Additionally, Mayhem provides coverage metrics to help you understand how far you have tested your application.
• Section 2.8 specifies that test cases which have been created to specifically show the presence (and later, the absence) of a previous bug shall be reused to verify applications. During fuzzing, Mayhem generates a comprehensive list of regression test cases. A few of these test cases result in a defect or crash that Mayhem will use as a Proof of Vulnerability, the test case, for future validation. Later on, when a developer branches off of the Master to add a new feature to the code, upon a push or a merge request, pipeline can invoke Mayhem to run a subset of previously generated test cases to verify that the new code will not introduce any regressions. This process is done by adding a command to your GitHub actions YAML, Gitlab CI YAML, or Jenkins files.
• Finally, section 2.9 states that Fuzzers such as Mayhem can try an immense number of inputs with minimal human supervision. They can be programmed with inputs, also known as Corpus, that often reveal bugs. This further indicates the value of running Fuzzing engines such as Mayhem and integrating it within your SDLC. It is also important to note that with Mayhem you could run other fuzzing engines such as libFuzzer, AFL, and Honggfuzz.

There are other key points as well, and for those there are other tools. But for addressing Automatic Testing and Dynamic Analysis, Mayhem for Code provides the coverage you need.  Learn more here.