Why the Next-Generation of Application Security Is Needed

Why the Next-Generation of Application Security Is Needed

New software and code stand at the core of everything we do, but how well is all of this new code tested? Luckily, autonomous application security is here.

By David Brumley

Software is revolutionizing the way the world operates. From driverless cars to cryptocurrency, software reimagines possibilities. With software standing at the core of everything we do, we find ourselves pushing out code faster than ever. Current estimates show that there are more than 111 billion lines of new code written per year. And our fixation on rapidly developing the latest technology has positioned application security to be in the way, and as coming at a “cost.”

As we continue to accumulate security debt and struggle to solve the cybersecurity workforce shortage, it becomes clear that we’re living on borrowed security time.

The point is not to dwell on our deficits in software security, but to highlight that we have to think bigger if we want to solve this critical cybersecurity problem. Manually eliminating 20, 50, 100 false positives from the backlog of 10,000 bug reports — reports that are only increasing by multiples on a daily basis — isn’t going to move the needle. And it’s incredibly expensive, with the average AppSec engineer making more than $133,000 per year and in short supply. Shouldn’t their time be better spent than fielding false positives?

What’s needed is autonomous application security. We need an application security testing solution that is able to accurately identify issues at speed and scale.

Autonomous is not Automation

I particularly want to emphasize the urgent need for this next-generation to be autonomous. This is not to be confused with automation. Unlike automation, autonomous capabilities encompass more than doing a pre-programmed task at the machine speed.

Autonomous application security testing is able to intelligently adjust it’s testing techniques to the specific needs of each application — no prebuilt test suites and no one-size-fits-all approach. It pulls data from past test results, and leverages it by making adjustments for its next test. This enables product-security teams to eliminate manual efforts in the application-security-management process.

Current solutions such as software analysis security testing (SAST) are not agile. They review the code line by line. They also lack the necessary means for validation, which would address the issue of false positives. Software engineers have to accept the practice, and build in the necessary time to investigate each result.

Fuzz-testing meanwhile is a dynamic application security testing (DAST) technique which sends malformed inputs to targets, with the objective of triggering bad behaviors in the running software, such as crashes, infinite loops and/or memory leaks. These anomalous behaviors are often a sign of an underlying vulnerability.

Fuzz-testing is a type of dynamic, behavior-based analysis. Initially, the industry had DAST web-fuzzers, where the tools were unaware of the code itself. These got slightly more advanced with interactive application security testing (IAST), which provided a code-feedback loop, but doesn’t help you grow coverage, leaving you at risk for untested code. Untested code is risky code.

Fuzz-testing, then, is the next generation, which automatically finds bugs. Fuzz testing is also the only dynamic analysis solution that helps reduce the cloud of uncertainty from that untested code because it continually expands code coverage. The ability to grow your test suite helps you get fixes fielded faster, and with more certainty.

Fuzz-testing-based autonomous application security testing goes beyond just pointing out vulnerabilities. Typically, the main barrier to getting a fix out is whether it breaks existing features. Google reports that 40 percent of its bugs fall into regression failures. By testing and retesting to confirm that each vulnerability is indeed real, developers can zero in on the specific line of code that warrants further investigation — thus saving time and resources.

This validation is also critical to continuous integration and delivery (CI/CD) workflows, because it allows developers to fork a section of code and have that section automatically checked before merging with the master.

Further, next-generation autonomous application security testing includes symbolic execution, which is able to abstract inputs and therefore map out a greater amount of code, increasing coverage in its test cases. Often these are areas of code where zero-day vulnerabilities are located, and areas where conventional security testing does not probe.

Autonomous Security Picks up

In the last year alone, we’ve seen shifts that further acknowledge the need for more autonomous application security:

  • Gartner has added fuzz-testing, the technology behind autonomous application security testing, to its AST Critical Capabilities. Gartner’s Critical Capabilities outline the criteria for qualifying into its Magic Quadrants.
  • The rise of the chief product security officer. Similar to the rise of the CISO role and the information security discipline, we are seeing organizations implement a product security discipline and give CPSOs a seat at the executive table. Product-security groups are responsible for the security of the products they offer, which is distinctly different from securing the company’s operations.
  • Git repository vendors enter the application-security testing space. GitHub and GitLab have both made moves into the application security testing market, highlighting the need to enable developers to write secure code. GitLab, in particular, acquired not one but two fuzz testing solutions.

Autonomous application security is here, and the world is ready for it.

David Brumley is the CEO of ForAllSecure.

 

The post “Why the Next-Generation of Application Security Is Needed” appeared first on Threat Post

Source:Threat Post – Threatpost