IAST defined, plus how it is impacting business-critical software

by Taylor Armerding on September 28, 2018

This article was originally published in Forbes.

As one of the endless number of acronyms in the software security industry, IAST doesn’t have much going for it—it’s awkward to pronounce and it’s hard to guess what it stands for.

But what is important, of course, is what a string of letters does stand for.

And in that case, Interactive Application Security Testing has a lot going for it—it is a tool that is remarkably effective at rooting out potentially catastrophic bugs in web-based applications during the (yes, another acronym) SDLC, or software development lifecycle.

Sponsorships Available

Its capabilities are significant—it enables developers to find and fix vulnerabilities before they end up in a finished product on the market, where they can be exploited by hackers.

It’s called “building security into” software, which is more effective, cheaper and not as risky as trying to patch it on later when a product is already in use.

Obviously, that benefits both consumers and the organizations that create, build and sell the apps and/or products operated by that software. Consumers are far less at risk of being hacked, and becoming victims of privacy violations, ransomware attacks and/or identity theft. Companies are far less at risk of compliance sanctions, brand damage, legal liability and other financial headaches.

IAST is not a brand-new kid on the security testing block—you can find experts touting its capabilities going back about five years.

And it is not the only useful tool for building security in throughout the SDLC.

But it is more relevant and valuable now, given the crucial need for speed in CI/CD (continuous integration/continuous delivery) workflows to develop business-critical software.

Other tools—yes, that means even more acronyms—include SCA (Software Composition Analysis), SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and penetration (or pen) testing.

SCA is an automated process that finds and identifies open source components in a codebase—a crucial step in the SDLC because once such components are identified, it is possible to check on if they contain security vulnerabilities that are already known, have been assigned a CVE (Common Vulnerabilities and Exposures) number and likely have a patch available.

SAST is used to analyze source code, to find threats so they can be fixed before before the launch of an application.

DAST tests an application’s exposed interfaces—it is frequently called testing “from the outside in.”

And penetration testing does what it sounds like—it launches “attacks” against software, generally at the end of the SDLC, to see if they can penetrate and expose vulnerabilities so they can be fixed before they can be exploited.

But it is more time consuming and costly to fix bugs at the end of development. DAST and pen testing can also be complex and slow, and they don’t integrate well into CI/CD pipelines, where, as Forrester Research reported last November, developers may build several times a day.

Enter IAST—designed for the speed of modern software development. While it is not an automatic replacement for DAST or pen testing in every case, it doesn’t slow developers down—and if the trade-off is between speed and security, speed usually wins, since organizations are trying to get a product to market before the competition does.

With IAST, they don’t have to slow down. It identifies vulnerabilities in real time while an app is running. Which is the way the app will be functioning in the real world—on the market.

Other advantages of IAST:

It is easily scalable.
It doesn’t overwhelm developers with false positives.
When it identifies vulnerabilities, it provides descriptions, risk assessments and remediation advice, all of which help developers fix problems early and quickly.

Beyond those, several IAST solutions now available also integrate SCA tools. That is a crucial combination, given that an overwhelming majority of web applications use a combination of proprietary and open source code, yet many organizations don’t know how much, or even what, open source code they are using.

Overall, the biggest business case for IAST is that it addresses the biggest attack surface. The Verizon 2018 Data Breach Investigations Report found that web application attacks remain the most common vector for data breaches.

Building secure software from the start is the best way to defend against that.

And it would add some significant credibility to the claim by most organizations—generally made after they’ve had to acknowledge a data breach—that “the security of our customers’ personal information is our highest priority.”