Interactive Application Security Testing (IAST) is a technology for automatically identifying and diagnosing software vulnerabilities in applications and APIs. As we will see, a better name might be “Instrumented Application Security Testing.” IAST is not a scanner. Repeat – IAST is not a scanner. IAST continuously monitors your applications for vulnerabilities from within. IAST runs throughout your development lifecycle and instantly alerts you through the tools you’re already using in development and test.

The key distinguishing feature of IAST is that it uses instrumentation to gather security information and telemetry directly from running code, rather than scanning source code (SAST) or HTTP scanning (DAST). But that doesn’t mean you have to wait for production. Quite the opposite, you can start using IAST in your IDE as soon as you write and test your first lines of code.

It's important to understand where IAST fits into a complete application security technology strategy. There are two main approaches to automating application security, and you should pursue both in tandem.

1. Prevent vulnerabilities during development. IAST automates the discovery of application and API vulnerabilities so that they can be fixed early in the development process when it’s less expensive. IAST has speed, accuracy, and process fit advantages over legacy static analysis (SAST) and dynamic analysis (DAST) approaches. Some IAST tools also include open source security analysis (SCA).
2. Detect attacks and prevent exploits in production. RASP prevent vulnerabilities from being exploited at runtime, rather than attempting to block attacks by examining network traffic like a web application firewall (WAF). RASP is not only more accurate and scalable than legacy approaches to web attacks, it also provides the infrastructure needed to deploy new defenses across an application portfolio within minutes.

We strongly recommend that you add IAST to your list of approved application security testing techniques. IAST emerged in 2010 and many of the largest finance, technology, and healthcare companies are already using IAST extensively. In this Refcard, we’ll explore how you can integrate IAST across your software lifecycle (SLC) to achieve cost-effective vulnerability detection.

Interactive Application Security Testing (IAST) is a security technology that uses software instrumentation to gather security information and telemetry directly from running software for the purpose of automatically identifying and diagnosing software vulnerabilities in applications and APIs.

Because IAST has access to the code itself, it can perform SAST on every single line of code. Further, because IAST has access to HTTP traffic, it can perform DAST-like analysis on every request and response. Therefore, the rule coverage of IAST is a superset of SAST and DAST tools.

Below we will explore all the things you can do with IAST, but the two primary IAST capabilities are:

• Custom Code Security Testing: IAST can be used to automatically analyze custom code for applications and APIs for previously unknown (zero-day) vulnerabilities. IAST can identify a broad range of vulnerabilities, including not only the OWASP Top Ten, but many other more complex vulnerabilities.
• Open Source Security Testing: IAST can also be used to test the security of open source libraries and frameworks in two ways. First, IAST can identify known vulnerabilities (typically published as CVEs) that plague open source. Second, IAST can also identify previously unknown (“novel” or “latent”) vulnerabilities in open source software.

How Do IAST Sensors Work?

Typically, IAST uses techniques similar to APM tools, profilers, and debuggers to instrument applications and APIs with security sensors. Security relevant events are directly measured from the running application by the sensors and are passed to an analysis engine, which assembles these events and identifies vulnerable patterns of code execution.

Instrumentation of the application with sensors is typically performed dynamically, as an application or API is loaded into memory. Instrumentation is safe and widely used for logging, performance measurement, and other purposes. Many common frameworks already use instrumentation at runtime under the hood. It is extremely likely that you are already using some form of instrumentation in your applications and APIs.

Modern applications are often assembled at runtime using techniques like dependency injection, dynamic loading, inversion of control, and other techniques. Because of this, analyzing source code can only ever provide a partial view. The best way to verify security is to directly measure the running application. IAST enables this direct measurement.

IAST security sensors can extract virtually any kind of information from an application. In many ways, IAST is a superset of SAST and DAST, as it includes analysis of code and HTTP traffic. But IAST considers many types of information in its analysis, including:

• Code – IAST can access all the source and binary code that is deployed with applications. Code sensors do binary static analysis (SAST) of every single line of code in an application, including libraries and frameworks.
• HTTP Traffic – IAST sees HTTP requests and responses and identifies vulnerabilities revealed in this traffic using techniques very similar to dynamic application security testing (DAST).
• Libraries and Frameworks – IAST can see every library and framework deployed and analyze exactly how they are used by the application or API. Not only can IAST evaluate libraries for known vulnerabilities (CVEs), but can also identify previously unknown vulnerabilities that are partially or entirely buried inside libraries. Importantly, because IAST knows exactly what parts of libraries are actually used by an application, it can filter out vulnerabilities associated with libraries that are never invoked.
• Application State – IAST can examine application state during program execution. For example, IAST can see the parameters used to call security methods to identify weaknesses, such as passing “DES” to an encryption cipher constructor.
• Data Flow – IAST traces data from untrusted sources from the point it enters an application wherever it might flow in an application or API. This is the key to identifying the most critical category of vulnerabilities, injection flaws. This technique, sometimes known as “taint tracing” is highly accurate as it tracks real data as it flows through the running application.
• Control Flow – IAST understands the control flow of an application and can identify patterns of application behavior that represent vulnerabilities. For example, if an application requires an access control check in the service() method of every web service, that pattern can be easily enforced with IAST.
• Backend Connections – IAST has access to all the details surrounding each backend connection, such as databases, OS calls, directories, queues, sockets, email, and other systems. IAST can use this information to identify both architecture flaws as well as security bugs.
• Configuration – IAST can access application, framework, appserver, and platform configuration options to ensure that they are properly configured for security. IAST can even query the runtime configuration of application components, such as XML parsers. Note that some platforms, such as.NET, rely heavily on configuration for security.

How Does IAST Analysis Work?

The IAST sensors create a stream of security-related events that feed into an analysis engine. This engine can enforce a wide variety of rules.

In effect, IAST establishes guardrails for a program. If the stream of telemetry from the sensors indicates that the behavior of the program has violated one of these guardrails, it is reported as a vulnerability.

IAST often uses multiple different sources of information to confirm a vulnerability. For example, CSRF can only exist when an exposed endpoint is non-XHR, state-changing, and does not contain a token check. IAST can access the HTTP request, analyze whether a transaction modifies files or writes to storage, and evaluate whether the control flow contains a token check. By using all three types of data in the vulnerability analysis, IAST produces the correct result, without overreporting or underreporting.

The problem is simple, we have a massive “scale” problem in application security. We have a very limited number of security experts to apply to the problem, but there are almost 20 million developers worldwide. Legacy tools require experts to “onboard” applications, train tools, and interpret results. 80% of the cost of these tools is “people cost” required to use them effectively. That isn’t really automation at all.

“Tool Soup” Doesn’t Work

“Tool soup” is what you get when none of the tools you have for a job are very good, so you resort to running a bunch of them hoping that you get a good outcome. In security, we’ve been trying this “hybrid” approach for over a decade and it just doesn’t work. Imagine taking the results of SAST, DAST, and SCA tools and trying to use them to detect CSRF vulnerabilities:

• Static Analysis: The SAST tool can only attempt to detect flows that aren’t protected with a token check, regardless of whether they are state-changing or accessed via XHR. The result is either massive time-wasting false positives or dangerous false negatives.
• Dynamic Analysis: The DAST tool can flag forms that don’t contain a CSRF token but has no way to know whether they are state-changing. Again, the result is either massive time-wasting false positives or dangerous false negatives.
• Open Source Analysis: The SCA tool can only flag libraries with known CSRF vulnerabilities. So, it will miss all CSRF vulnerabilities that haven’t been disclosed and published by security researchers.

Running all these tools takes time and precious security expertise. But more importantly, it is extremely difficult to correlate security testing results. Static tools report source code line numbers, dynamic tools report HTTP requests, and open source tools report library version numbers. There’s no good way to correlate these reports. The best correlation tools report between 15% and 35% reduction in findings. So, if you have two tools that report 200 findings each (a very conservative estimate for static tools), you get a “reduction” to 340 findings that you have to investigate. Bottom line, merging noisy and inaccurate reports simply isn’t cost effective.

Legacy Application Security Tools Aren’t Compatible with Modern Software

Modern software development moves fast and is accelerating. Many projects deploy code at a weekly, daily, or even hourly cadence. Unfortunately, techniques like SAST, DAST, fuzzing, manual penetration testing, and manual code review simply don’t work at the speed and scale of modern software.

The biggest challenges to traditional application security tools are:

• Accuracy: The biggest problem for legacy tools is accuracy. SAST and DAST generate large numbers of false positives (a report that is not a real vulnerability) and false negatives (a missed real vulnerability). Whenever tools aren’t accurate, human security experts must perform manual steps to resolve the problems. This process is incredibly time consuming and creates a massive bottleneck for software deployment. IAST has a huge information advantage over legacy tools and the corresponding accuracy improvement means developers can use the results directly, without expert intervention.
• Compatibility. Modern applications, and particularly APIs, are built on top of complex frameworks that automatically map client traffic to functionality and parse data out of complex data structures, like XML, JSON, and serialized objects. SAST tools can’t trace these pathways without extensive tailoring, and DAST tools can’t simulate the complex traffic required for testing. IAST is largely immune from these problems as it simply observes complex applications and APIs as they run.
• Speed: Modern software methodologies, like Agile and DevOps move very quickly. The goal is to fully automate the pipeline between developers and production. While legacy tools take hours to perform a full analysis (not even considering expert triage to remove false positives), IAST provides instant feedback as a developer is building and testing code in their IDE. IAST can also run alongside existing tests and QA and can instantly fail the build if a security problem is discovered.
• Scale: Security tools must be capable of continuously analyzing an entire portfolio of applications across an extensive set of rules. Legacy scanners run serially, and simply can’t scale for modern enterprises. IAST is a fully distributed and continuous approach to application security, meaning that all your applications and APIs can be continuously assessed in parallel, so that your security is always up to date across the entire portfolio.
• Process Fit: IAST simply layers on top of existing development tools and processes, without disrupting software development. No extra steps are required. IAST simply works in the background while you do your normal development and testing. And because IAST is accurate and can find vulnerabilities without having to know how to exploit them, no experts are required. So, anyone can use IAST to do their own security testing and check in clean code.

Since many are still unfamiliar with IAST, it helps to detail where IAST fits in with other types of security protections.

The diagram above shows where IAST fits into the NIST CyberSecurity Framework (CSF). IAST is squarely focused on the application security row. In addition to detecting and identifying vulnerabilities, some IAST implementations can help with identifying and profiling applications.

IAST in the Stack

The idea of using an instrumentation-based approach to security isn’t restricted to just the application layer. Security experts have realized that we can no longer detect vulnerabilities from the outside. External perspectives don’t provide enough context to identify vulnerabilities accurately. Doing vulnerability detection from the inside is much easier, faster, and more accurate. This trend of instrumentation-based security testing (versus scanning-based security testing) is occurring across the entire stack.

The following table details the layers of the modern web application stack along with instrumentation-based security solutions.

As you can see, IAST is the instrumentation-based approach to securing the application layer. Many security products that target other layers of the stack are recognizing the advantages of instrumentation-based approaches as well. At all of the layers, having direct access has massive advantages over attempts to test security from an external perspective.

Since IAST builds security directly into the software stack, the application can be deployed in any environment safely, including cloud, PAAS, VM, and data center.

For enterprise organizations, IAST is a powerful way to establish continuous security testing across the entire application and API portfolio. With IAST, organizations can perform continuous application security testing in parallel across their entire application portfolio.

Securing the Enterprise Application Portfolio

Many organizations only test a small subset of their application portfolio for security. Some organizations only test the “critical” applications. Others have policies to test all “external facing” applications. More than likely, it won’t be your primary website that gets compromised. Instead, it’s more likely to be a partner website, an obscure mobile API, or a business app on your intranet. This is why protecting all your applications and APIs, even non-web APIs, is so critical.

Many organizations reserve security testing for what they think of as “external” or “public-facing” applications. Actually, the concept of “internal” and “external” applications is dependent on a working security perimeter. Unfortunately, the perimeter established by firewalls and other network security devices has become so porous that it is now essentially meaningless. For example, a single employee workstation that is compromised by an attacker becomes an internal attack portal that makes the perimeter irrelevant. Consider testing your entire application portfolio, including internal applications.

IAST in the Pipeline

Remember, IAST is nothing like a scanner. IAST effectively becomes part of your application. It can run anywhere that your application runs, including your developer IDE, on a local testing server, on a QA machine, as part of a CI/CD build, in a container, in the cloud, or anywhere else your code runs. You can use IAST anywhere that your software runs throughout the entire software development lifecycle. There are good reasons to use IAST extremely early in development, in integration and test environments, and also in production.

The image below depicts a simple development pipeline, using IAST throughout to identify vulnerabilities continuously.

You can choose exactly which locations in your software lifecycle to use IAST. Because IAST doesn’t require any extra steps, IAST is compatible with all different approaches to software development. IAST is particularly well suited to DevOps, which is allergic to tools that require expert babysitting and take a long time to run.

Installation and Configuration

The process of installation is very simple. There are typically two parts to an IAST solution: an IAST agent and an IAST console. You create an account on the IAST console and then download the IAST agent, which performs the analysis and sends results back to the console.

The first step is to add the IAST agent to your application environment in some way. It might be as simple as adding a library, running an installer, setting an environment variable, etc… Then when you use your application, the IAST agent will automatically do the security testing in the background. Important: you don’t need to attack the application to get great security results. IAST can be used by anyone, even novice developers.

The IAST console enables you to manage security across an entire portfolio of applications in parallel. You can administer security policy, configure security controls, and set up integrations with common development tools for vulnerability notification.

Deploying IAST in Development – Process and Integrations

In development, our goal is to empower developers to find and fix their own vulnerabilities and commit clean code. But we must avoid slowing them down or giving them false positive results that waste their time.

IAST is a good match for these goals, because it provides instant feedback on exactly the code that the developer is building and testing in their local environment. IAST alerts might come through the IDE, a chat program, bugtracker, or other integration. Because IAST provides the exact line of code, the full HTTP request, and the full data and control flow, the developer’s work is made easy. They can fix the code and retest with the HTTP request to verify that the problem is resolved correctly, and check in clean code.

Deploying IAST in CI/CD and QA Environments – Process and Integrations

In the QA environment, we are looking to ensure that the developers have done the right thing and eliminated any vulnerabilities. We want confidence that the application or API is free from vulnerabilities before we push into production. We want the ability to “fail the build” in the case of serious security vulnerabilities. But we must not slow down the build or require the involvement of security experts.

IAST is a great match for security testing in QA environments, because it runs alongside your normal automated and manual tests and provides security testing automatically in the background. In these environments, the IAST notifications are typically provided through CI/CD tools and bugtrackers. Formal reports can also be generated for audit and compliance purposes.

Deploying IAST in Production

Doing security testing in production is generally not a great idea. Ideally, you would have found and fixed any security issues long before they reach production. However, there are many “legacy” applications that are no longer being actively developed. There are also third-party products that only exist in production. Yet we still need ongoing, continuous assurance that these applications are free from vulnerabilities. And we want to know if any new vulnerabilities emerge that might affect these applications.

While it is not as common as using in development or testing, IAST can also be used effectively in production. Because IAST does not require the source code, it can be used on almost any application provided it is possible to install the IAST agent. It’s important to consider the performance impact of IAST on these applications. While IAST is generally fast enough not to be noticed in development and test environments, in production even a few extra milliseconds might not be acceptable. Note that IAST often has configurations, such as “sampling mode” that can significantly improve performance in production environments, while still providing great security coverage over time.

In this section we’ll explore a few of the key criteria you should consider when evaluating an IAST solution. All IAST products work differently, and you will want to evaluate them carefully to ensure that they work in your environment.

Stakeholders

You’ll want to include a number of different stakeholders in the selection process:

• Security – Obviously, security plays a key role in vulnerability management. IAST can be a primary provider of vulnerability telemetry across the application and API portfolio in an organization. Used properly, IAST can help eliminate the majority of vulnerabilities early in development without security involvement.
• Development – The development team should have the primary responsibility for ensuring that applications and APIs are free from vulnerabilities. Development teams often have had bad experiences with security tools and may be skeptical of IAST capabilities, so ensuring that they understand IAST’s benefits and getting their endorsement is key.
• DevOps –DevOps teams have a critical need to push software into production at a high rate of speed. This isn’t compatible with static and dynamic scans that can take many hours to run and require extensive triage to weed out false positives. IAST can enable DevOps teams to do their own security and provide a fully automated path to push code into production with security confidence.
• Executives – Understanding the basis of your application security confidence can enable executives to make informed decisions about digital transformation, shifting to DevOps, or moving to the cloud. Ensuring that IAST is an approved application security testing technique will help adoption.

Technical Considerations

• Language Support – Different vendors support different languages, so you’ll want to ensure that they cover the languages that your important applications and APIs are written in.
• Framework Support – Application framework is Just as important as language coverage. Unless your IAST supports your frameworks, it will not be effective at detecting vulnerabilities.
• Accuracy – You’ll want to evaluate accuracy by using an application containing a realistic set of real vulnerabilities. Test carefully that the IAST identifies vulnerabilities without flagging false positives. Use the OWASP Benchmark to gain detailed insight into exactly what application security testing tools are good and bad at.
• Scalability – Consider the size of your application portfolio, including APIs, internal applications, and products. Can IAST scale to support continuous analysis of all those applications? How much staff will be required to achieve that level of assurance.
• Ruleset Coverage – Look for a broad ruleset that covers the types of attacks that you are concerned with. This should include both common vulnerabilities classes as well as disclosed vulnerabilities (CVEs).
• Visibility – Does the IAST have its own dashboard? Or does it rely on bugtrackers only. What alerts, notifications, and reports are available? Are IDE and CI/CD plugins available?
• Installation – Most IAST products are simple to install and don’t require process changes. Can installation be automated? Can IAST be added to containers and images so that it is automatically present for new applications?
• Configuration. Does IAST require any complex onboarding or configuration for accurate analysis? Can custom security controls and rules be added to IAST easily?
• Administration and Updates – Is there a centralized way to update IASST rules and functionality? Are software updates automatic? Does IAST include enterprise features like LDAP integration, strong authentication, enterprise grade access control, encryption of data in transit and at rest, and full security logging?
• Integration – Does IAST provide plugins for common security and DevOps tools and pipeline? Is there a full API for all data collected? Does the API also include functions enabling administrator to take actions?

IAST can be evaluated quickly, because you’ll know within a very short period of time whether it works on your applications. You can simply deploy IAST on a few applications, use your applications normally or run some tests and then evaluate the results.

In this section, we explore how to use IAST to solve common security problems. In general, IAST can identify and diagnose vulnerabilities in the software itself, not container, operating system, or network attacks. Every product is different, but because IAST has access to the code, HTTP traffic, and many other sources of security information, it can address a very broad range of vulnerabilities. Notice that the IAST list below includes both vulnerabilities deep in the code (traditionally only found by SAST) as well as vulnerabilities that manifest in HTTP traffic (traditionally only found by DAST).

• Injection - SQL Injection, NoSQL Injection, Reflected Cross-Site Scripting, Stored Cross-Site Scripting, Path Traversal, Command Injection, LDAP Injection, XPath Injection, Expression Language Injection, OGNL Injection, Hibernate Injection, Header Injection, Java Reflection Injection, Log Injection, Unsafe Code Execution, XML External Entity Injection (XXE)
• HTTP Headers – Caching, Anti-Clickjacking Controls, HSTS, Insecure Cookie, Response with Insecurely Configured Content-Security-Policy Header, Response with Insecurely Configured Strict-Transport-Security Header, Response With X-XSS-Protection Disabled, Response Without Content-Security-Policy Header, Response Without X-Content-Type Header, Version Header Enabled
• Parsing - XML External Entities, Untrusted Deserialization, Parameter Pollution, Regular Expression DoS, Unvalidated Redirect, Use of readLine on Untrusted Streams, Trust Boundary Violation, Unchecked Autobinding
• Authentication – Insecure Authentication Protocol, Unprotected Connection Strings, Session Cookie Has No 'secure' Flag, Session Rewriting, Expired Session IDs Not Regenerated, Forms Auth Protection Mode, Forms Authentication Cross-App Redirect, Forms Authentication SSL, Forms Without Autocomplete Prevention, Hardcoded Password, Session Cookie Has No 'HttpOnly' Flag, HttpOnly Cookie Flag Disabled
• Authorization – Cross-Site Request Forgery, Server-Side Request Forgery, Verb Tampering Weakness, Role Manager Protection Mode, Role Manager SSL
• Cryptography – Insecure Encryption Algorithms, Insecure Hash Algorithms, Padding Oracle, Hardcoded Cryptographic Key, Weak Random Number Generation, MAC Validation Disabled
• Weak Configuration – Detailed Error Messages, Event Validation Disabled, Header Checking Disabled, Insecure JSP Placement, Large Max Request Length, Overly Long Session Timeout, Request Validation Disabled, Request Validation Mode Disabled, Tracing Enabled, Tracing Enabled for ASPX, Unsafe XML Decoding, Viewstate Encryption Disabled, Viewstate WCF Exception Details, WCF Replay Detection Not Enabled, WCF Service Metadata Enabled, Weak Membership Configuration

Some IAST products also include a powerful rule language that allow definition of both positive (a behavioral pattern of code execution that is always required) and negative (a behavioral pattern of code that is disallowed) security rules.

Using IAST to Ensure Developers Commit “Clean” Code

Developers can use IAST for instant security analysis of their code as they create and test it within their development environment. All the developer has to do is add the IAST agent to their local server environment. Once IAST is installed, they can just do their normal work and all their testing, both automated and manual, does double-duty as security testing. Developers can receive instant security vulnerability notifications through the tools they are already using, including Eclipse, IDEA, VisualStudio, Slack, Hipchat, Chrome, JIRA, VSTS, etc.

Using IAST Provide Strong Assurance Before Deploying

IAST can also be used in the QA, test, or CI/CD stage to ensure that no vulnerabilities have escaped development. Simply add the IAST agent to any server that is used for QA testing, whether it’s a test server, used for automated testing, or part of a CI/CD build process. Using IAST in QA is an effective final check of the fully assembled application as it will be configured and deployed. Vulnerabilities discovered here should be taken seriously. IAST can be configured to automatically create a bugtracking ticket or fail the build.

Using IAST to Ensure APIs Are Secure

Legacy static and dynamic tools are not good at testing API security. These tools can’t handle the complex protocols (JSON, XML, binary, or other payload) or the complex data and control flows in the frameworks used to build APIs. Most APIs use a software framework with features like automatic payload parsing and object mapping. Many use annotations to route data to the appropriate methods. Because IAST gathers security information from inside the API itself, it works the same way it works on regular web applications and can easily identify API vulnerabilities.

Using IAST to Test for Known Vulnerabilities in OSS

While open source vulnerabilities often seem like a flood, the situation is likely considerably worse than it appears. There are millions of open source libraries in existence, and only a handful of security experts testing them. IAST can automatically analyze open source against newly disclosed vulnerabilities (CVEs). Because IAST can run continuously, in parallel, across an entire portfolio of applications at scale, it can enable mass detection of new library problems in minutes. Legacy OSS scanners have to rescan the entire enterprise. In addition, IAST can tell you exactly what code is actually invoked in your open source libraries. On average, 72% of libraries are only included in applications for compilation dependencies and are never actually invoked by the applications. IAST can save you the work of updating libraries that don’t present any risk.

Using IAST for Continuous Audit and Compliance

IAST tools support a broad range of security standards, including PCI DSS, HIPAA, NIST 800-53, OWASP Top Ten, OWASP ASVS, and DISA AppSec STIG. IAST provides strong evidence that applications have been thoroughly security tested. IAST tools can generate reports that demonstrate that applications were thoroughly tested and that no vulnerabilities were identified. Because these reports can be generated at any time for any build, they can significantly accelerate the audit and compliance processes.

Using IAST for Ongoing Assurance of Legacy Applications

Legacy applications present a particular application security challenge, as they are often in operation for a long time without significant development effort. Traditional security processes tend to focus on securing before deployment, rather than the IAST continuous security approach, and may not catch emerging vulnerabilities. Because IAST can run continuously, in parallel, across an entire portfolio of applications at scale, it is uniquely positioned to help with legacy applications.

Using IAST to Test for “Latent” Vulnerabilities in OSS

The vast majority of open source vulnerabilities have yet to be detected. Because IAST tests your entire software stack, it can discover these “zero day” vulnerabilities in the libraries and frameworks you are using that attackers may know about but have not yet been discovered by researchers. You can then choose to select another library, contribute a fix to the project, or use RASP to prevent that vulnerability from being exploited.

Using IAST to Enforce Secure Coding Guidelines

While IAST comes with an extensive set of vulnerability rules, it is also capable of enforcing your organization’s custom secure coding guidelines. You can create “positive” rules like “every API must call the AccessController.isAuthorized() method for authorization.” IAST can enforce these rules and give instant feedback to developers on how your organization has chosen to implement security. Over time, organizations can use this capability to evolve from a negative “prevent vulnerabilities” model to a positive “use enterprise security controls” model.

As software development projects move towards DevOps, the process of building and testing software accelerates, which makes SAST and DAST increasingly difficult to use. IAST is uniquely suited to work well with DevOps because it empowers developers to find and fix their own security vulnerabilities with instant and accurate feedback that doesn’t require any extra process steps. This minimizes the impact of security work on development and dramatically reduces the amount of downstream security work.

With IAST, you just build, test, and deploy code the way that you always have. The only difference is that IAST is there in the background, ensuring that you don’t introduce any dangerous code or library vulnerabilities.

As shown in the diagram above, IAST can scale to perform continuous application security testing in parallel on hundreds or thousands of applications easily.

What's Next for IAST?

IAST is well established in the market, with several vendors and many large deployments. But there is still significant room for innovation in the IAST market. Look for vendors to expand language/framework coverage, expand protection capabilities, and even add novel techniques that are brand new for the application security industry.

Here are some sources of additional information.

• DZone Introduction to RASP Refcard – https://dzone.com/refcardz/runtime-application-self-protection
• What is an IAST -- https://www.contrastsecurity.com/security-influencers/question-i-understand-sast-and-dast-and-how-to-use-them-but-what-is-iast-and-why-does-it-matter
• Gene Kim, “The Phoenix Project” - https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592
• Security at DevOps Speed and Portfolio Scale - https://www.youtube.com/watch?v=cIvOth0fxmI
• Ed Amoroso, “Explode, Offload, Reload” - https://www.linkedin.com/pulse/lose-security-wheel-edward-amoroso/