Software Integrity Blog


IAST—A better bugtrap

IAST (interactive application security testing) is a better way to find bugs during the SDLC. And you know what they say about building a better mousetrap.

IAST — A better bugtrap with interactive application security testing

Everybody’s heard the cliché that if you build a better mousetrap, the world will beat a path to your door.

The same applies to building a better bugtrap—as in software bug. Which is why developers ought to be beating a path to a tool that offers a better way to find bugs during the SDLC (software development life cycle). It’s called IAST—interactive application security testing.

While it is not the right tool for every application, and it’s not an automatic replacement in every case for DAST (dynamic application security testing) or penetration testing, it is superior for finding vulnerabilities early in the SDLC—when it is easier, faster, and cheaper to fix them.

Both DAST and pen testing can be effective at determining whether a web application is vulnerable. But they can be costly, complex, and slow to operate, and they don’t integrate well into CI/CD (continuous integration/continuous delivery) pipelines.

IAST addresses the reality that the software delivery cycle is always under a time crunch. While the pressure is much less existential, it recalls the iconic line from Jeff Goldblum’s character in “Jurassic Park” as he’s riding in a Jeep trying to outrun a Tyrannosaurus rex: “Must. Go. Faster.”

IAST = Fast

Forrester Research reports that 34% of developers say they build multiple times per day or during check-in. That means security testing must run in these same timeframes or risk bringing development to a grinding halt.

It is the kind of pressure that often prompts developers to favor speed over security. The priority is to get web applications to market before the competition does, and worry about patching software vulnerabilities later.

In that kind of environment, DAST can be, in a word, cumbersome.

So much so that development teams typically move DAST scans to the end of the software delivery life cycle or into the production environment because DAST scans can identify vulnerabilities but don’t specify corresponding vulnerable lines of code where developers can go to fix them.

But it no longer has to be that way. With IAST tools, which integrate seamlessly into developer workflows, teams can build security into their products without sacrificing speed and before they are released to production. There are multiple reasons why:

  • IAST tools relieve developers from having to depend on a crawler to assess running applications. They identify vulnerabilities in real time, using instrumentation techniques to deploy agents in a running application that continuously analyze all app interactions initiated by manual and automated tests. No need to run scans that don’t fit into CI/CD workflows.
  • They can easily scale to process hundreds of thousands of HTTPS requests without overwhelming security teams with long lists of analysis results that are riddled with false positives.
  • They can identify vulnerable lines of code and provide descriptions, risk assessments, and stack traces for discovered vulnerabilities, along with remediation advice, which developers can use to find and fix problems before the product is on the market and unpatched bugs are bugging customers.
  • They are easy to deploy, update, and scale to support large enterprise requirements.
  • Several IAST solutions now on the market also integrate software composition analysis (SCA) tools. These tools work by scanning source code or binary files (compiled code) and/or collecting information from package manager software (such as Maven, Gradle, and others, used when developing software in languages like Java and Ruby) to assemble a list—often called a bill of materials (BOM)—of components and versions. Then they report current known vulnerabilities associated with those components, as well as their associated licenses and other information.

Bottom line: IAST catches problems earlier in the SDLC, which cuts remediation costs and eliminates delays. So you can go faster and still improve security.

How to make IAST work

There are some conditions necessary to make IAST function most effectively. It can be performed only on running apps and is most effective for organizations that have rigorous test suites, functional tests, and QA processes built into their DevOps workflows.

Also, IAST tools can assess only running apps, not static source code, unlike SAST tools. Thus, the more complete the automated testing coverage already in place, the more reliable the results.

But the payback is significant. Instead of spending several days to a week on external pen testing at the end of an SDLC that would likely turn up hundreds of high-level defects that take considerable time to fix, IAST can cut pen testing time by as much as 75% and eliminate virtually all high-level defects.*

Bottom line: IAST is cheaper, better, and faster—a much better bugtrap.

Learn more about IAST now.

*Source: Amy DeMartine, Construct a Business Case for Interactive Application Security Testing, Forrester, Nov. 2017.


More by this author