In a previous post of AST Guide for the Disenchanted, we identified the minimum appsec risks that need to be addressed as a part of your DevSecOps pipeline. The two risks are: known and unknown vulnerabilities. In today’s post, we’ll focus on how fuzz testing can help you address those unknown vulnerabilities.

To let coders do what they do best, code, they need a solution that reduces false-positives.

Developers are creative, brilliant people. They solve intricate problems by writing applications.

Although they are talented individuals who possess many skills, they are not security engineers.

Writing code and writing secure code require two separate skill sets. Many R&D teams have come to this realization and have armed their developers with static Application Security Testing (SAST) tools that promise to teach their developers to build security into their code.

While the logic behind SAST is in the right place, it unfortunately goes awry in execution. Static testing directly analyzes the code for coding vulnerabilities and/or weaknesses. Because they work on identifying weakness patterns, they can help identify unknown vulnerabilities. However, SAST is conducted on applications while they’re in a non-running state, so it can only blindly apply coding best practices. SASTs have zero context into how the application will behave in production environments, and, as a result, frequently produce false-positives.

Grammar is an excellent analogy. Understanding the rules of English grammar sets the foundation for apt writing. However, the English language is all about exceptions, and the proper use of English grammar largely depends on context. Coding works similarly; The applicability of coding rules largely depends on context. So, now, developers are expected to code, run SAST against their code, sift out false-positives, correct validated issues, and deploy releases without adjustments to roadmap commitments. Of course, this is a lot to ask of a developer, so security teams get involved to analyze SAST results on their behalf. This is an unsustainable, unscalable approach that requires a lot of time and effort. There’s a need for application security solutions that reduce the number of false-positives to sift through.

Continuous Testing at the Speed of Development.

Find out how ForAllSecure can bring advanced fuzz testing into your development pipelines.

Request Demo Learn More

There is: Advanced fuzz testing. Advanced fuzz testing (AFT) is an alternative solution for identifying unknown vulnerabilities in code. Unlike SAST and SCA, it does not rely on lists of known weaknesses or vulnerabilities alone. It executes uncommon or unknown attack patterns against applications in running state. There are several benefits to this approach:

• Accuracy: Because fuzzers run attacks against applications in running state, all findings are reproducible. It can also prove its findings by sharing the test case that triggered the vulnerability.
• Proactive: Fuzz testing takes offensive approaches to help organizations build defensive mechanisms directly within their applications. This particular technique is effective for uncovering unknown vulnerabilities.

The diagram below offers an at-a-glance, in-depth view of SAST and AFT’s technical capabilities:

Static Application Security Testing (SAST)

Advanced Fuzz Testing (AFT)

Description

Directly analyzes the code to detect coding and design vulnerabilities and/or weaknesses.

Executes uncommon and unknown attack patterns against applications and monitors for anomalous behaviors. Anomalous behaviors, such as memory leaks, infinite loops, and crashes are a sign of underlying vulnerabilities

Approach

White Box

Grey-box - meaning it can test with both access to code and without

Application State During Testing

Non-running State

Running state

Accuracy

Low

High

SDLC Phase

Development

Development

CI/CD

Pre-Deployment; AST solutions integrated earlier in the SDLC is desired for DevSecOps. Studies have shown testing early and often manages unexpected remediation costs and effort. 

Pre-Deployment; AST solutions integrated earlier in the SDLC is desired for DevSecOps. Studies have shown testing early and often manages unexpected remediation costs and effort. 

Remediation Actionability

High

High

DevSecOps Best Practice

Integrates as a part of developer workflows to share results as they code

Integrates as a part of developer workflows to share results as a part of the build process

Until next time…

In this post of AST Guide for the Disenchanted, we covered the challenge of securing proprietary code, particularly as it pertains to reducing false-positives. We also identified advanced fuzz testing as a solution for identifying unknown vulnerabilities in code.

In the last and final post, we’ll show how SCA and AFT come together to complement each others weaknesses with strength. Meanwhile, read this blog on Challenging ROI Myths of SAST.  For immediate information or a demo, contact us at info@forallsecure.com.