Software application vulnerabilities fall into three different risk categories:
- Known Known: Known Knowns are identifiable risks that are known to lead to compromise. These risks are identified through a Common Vulnerabilities and Exposure (CVE) ID, with 100s to 1,000s of vulnerabilities in a given software.
- Known Unknown: Known Unknowns are identifiable risks that could potentially lead to compromise, and these risks exhibit software flaw patterns that are likely to create exploitable vulnerabilities. These risks are identified through a Common Weakness Enumeration (CWE) ID, with 10,000s to 1Ms of defects in a given software.
- Unknown Unknown: Unknown Unknowns are risks that cannot be identified. Unknown Unknowns present the greatest risk, because they enable adversaries to operate unnoticed for an extended period of time. These are unidentifiable risks not detectable by CVE or CWE, with an unknown quantity in a given software.
An Application Security Testing strategy that utilizes different kinds of Application Security Testing tools offers the best coverage by discovering vulnerabilities from each risk category. For the purpose of this blog post, we will focus on how SAST and Mayhem work together to identify both known-unknown and unknown-unknown risks.
SAST Discovers “Known Unknown” Risks
Static Application Security Testing (SAST), or static analysis tools uncover bugs by analyzing source code. The defects they identify are known unknown risks.
SAST is a good first line of defense in your Application Security Testing strategy, since it can be introduced earlier in the SDLC (Software Development Lifecycle) than many Application Security Testing methods. SAST directly analyzes code to detect vulnerabilities and weaknesses. A white box method of testing, SAST examines an application as it's written, and doesn’t need to run the application to test it.
However, SAST has a few shortcomings, the main one being that it can find defects in code, but is unable to determine whether those defects are vulnerabilities. This means that SAST produces a high number of false positives, all of which must be manually combed through to determine which are actual vulnerabilities. Another shortcoming is that SAST requires manual test case creation, which can be very time consuming.
Despite its shortcomings, SAST has its place in the SDLC as a preventative practice. By using SAST to test an application as it is written, you can find defects before you’ve ever run the application. Since static analysis requires source code, SASTs are able to provide prescriptive remediation advice, down to the line of code. SAST is best used during the SDLC development phase.
Mayhem Uncovers “Unknown Unknown” Risks
Mayhem uses advanced fuzz testing techniques to uncover defects utilizing unknown or uncommon attack patterns. The defects Mayhem identifies are unknown unknown risks.
Mayhem offers strengths in SAST’s limitations, since it doesn’t require manual test case creation and produces zero false positives.
Mayhem’s continuous fuzz testing is a proven and accepted method for uncovering unknown defects automatically. This testing can be done during the SDLC development or QA phase. Mayhem uncovers unknown defects, enabling organizations to be preventative and proactive. It can pinpoint the exact line of affected code and provides expert remediation advice, making fixes as simple as possible for developers.
Using SAST and Mayhem Together
SAST and Mayhem strategically offer strengths where the other technique has limitations. Using SAST as a frontline approach to catch known-unknown defects and Mayhem throughout development to catch unknown-unknown vulnerabilities is the foundation for a good multi-pronged software security approach.
Learn more about how Mayhem makes up part of a comprehensive application security approach by reading our Buyer’s Guide to Mayhem and Comprehensive Application Security.
Development Speed or Code Security. Why Not Both?
Mayhem is an award-winning AI that autonomously finds new exploitable bugs and improves your test suites.