If you have followed Contrast's progress over the years, you will recognize us as a leading provider of Interactive Application Security Testing (IAST)/ Runtime Application Self-Protection (RASP) (and recently Static Analysis Security Testing [SAST!]) provider. Contrast has been working on security instrumentation for nearly a decade now, and during my time here I've had countless conversations with people about how and where these technologies can be used to help accelerate DevSecOps. What continues to surprise me is the misconceptions that surface again and again about which teams should use these technologies and where they can benefit from them. For today, let's start with IAST, and I’ll follow up soon with some thoughts on RASP.
Myth #1 - IAST is only for modern development teams
For me, this perception is probably the most inaccurate one on the whole list.
The thought process here is sound: Modern development teams work with microservices, event-driven architectures and automated deployments. These teams release multiple times per hour, which means speed is important. Given that IAST is blazingly fast, they benefit the most, right?
I disagree.
Let’s talk about the monolith, that huge squillion-lines-of-code application that no one wants to talk about (until it’s been successfully carved up!). It’s your 15-year-old pensions ledger, your enterprise resource planning (ERP), your bookings system, whatever. The fact is that if you try and secure this type of system through traditional SAST or DAST scanning, then you’re either in a world of pain or you’ve just accepted your fate. The truth is that IAST is a great technology to take care of these huge applications for you. Simply deploy an IAST agent alongside your application, then sit back and enjoy a steady flow of accurate vulnerabilities from the continuous analysis. No need for “nightly” security scans, no more endless DAST tuning and very few false positives. Set it and forget it, IAST loves your monolith!
Myth #2 - IAST is late in the SDLC, during the testing phase
Err no, also wrong. The truth is, IAST can be deployed directly on the developer workstation using a lightweight agent, enabled through your project configuration. The world is hell-bent on building secure pipelines, and I get it (IAST should run there too!), but if you really want to shift waaaay left, then why not catch those vulnerabilities before your dev checks in their code? I hear you screaming “Don’t touch my IDE!” and I understand the pushback, but this isn’t some heavyweight integrated development environment (IDE) plugin. the Contrast agent is fast, continually benchmarked for performance and it’s getting faster all the time. For most languages, I think we’re already at the stage where it becomes a no-brainer to have the agent checking for issues as you test the application programming interface (API) or web page you just wrote. Issues that get caught before the pull request? Yep, nice!
If you can’t tolerate an agent riding shotgun with your app while you’re in flow, then IAST can still help you out at the pull request (PR). If you’re running integration or functional tests as part of your PR process, then IAST can be slotted into the mix, and you’ll have security feedback in an instant. This isn’t some “maybe you have a vuln here” cryptic feedback, we’re talking nailed on “we tracked this piece of data from your http param and you eventually used it in a filename” type feedback. Reliable, actionable and early in the Software Development Life Cycle (SDLC).
Myth #3 – Language support is limited with IAST tools
I’ll admit that in the past, this was a very fair observation of IAST tools, but I’m glad to say that the industry has responded. In the past couple of years, Contrast has added support for Golang, .NET Core, Golang, Scala, Kotlin and PHP, along with support for many additional frameworks. I mention frameworks, as IAST can be a bit more sensitive to frameworks, but so too can SAST technology. With IAST or SAST it is important for the technology to understand the sources and sinks within the application to successfully identify vulnerabilities.
Myth #4 - IAST is difficult to deploy
This objection should really be refined. IAST can be difficult to deploy if you are a member of the security team and you don’t work closely with developers. Although the installation of an IAST agent is trivial, it does require access to the build configuration or deployment environment to add the agent. If your security team have been scanning code via the repo, then it may feel like an effort to implement an IAST agent. On the flip side, if you can engage your development teams, then, typically, they already have experience in deploying agents thanks to the widespread adoption of Application Performance Management (APM) tools. Our development teams at Contrast continue to improve in this area, and thanks to our recently released Kubernetes operator, it just became very easy to scale deployment. The operator provides a simple way to instrument your Kubernetes or OpenShift pods by simply adding a workload label to the pod's yaml configuration. You can read more about this here.
Myth #5 - IAST requires full test coverage
Finally, let’s examine the elephant in the room: test coverage. IAST works by tracking “tainted” data and watching this data propagate through your application until it reaches a sink (I.e., somewhere this data could be harmful). The perception that IAST always requires test coverage to be able to detect vulnerabilities isn’t quite accurate. I only speak for Contrast’s IAST agent, but I can clearly state that our rules don’t all require test coverage to identify vulnerabilities. Contrast Assess inspects your dependencies, looks for embedded secrets and finds configuration problems without test coverage.
Underpinning any anxiety around IAST coverage, there is sometimes a dangerous misconception (or maybe over-confidence) in SAST tooling. While infamous for the volume of false positives they produce, SAST tools are also very prone to false negatives (missed vulnerabilities) for numerous reasons. Static analysis tools can have issues with understanding real code flows, as there is much complexity to be unpacked in logic branches, data transformations and reflection. Some tools operate on source code specifically, becoming effectively blind when the code flow reaches a binary library and having to approximate how data flow could be manipulated. Sprinkle on some inversion of control, code annotations and plugins; then, you can see how tracking taint flow reliably is a tricky business. Traditionally, tools have separated our testing of applications into the code we write (SAST) vs. the code we import (SCA), but it makes more sense to test it together — which is how IAST works, reliably tracking taint through the assembled application.
Finally, let’s just consider the effort and reward associated with automated testing. Reliable and consistent feedback on the quality of the asset that we’re putting into production is the goal for every engineering team. Contrast agents can help in this area by continually monitoring the route test coverage of your applications, making it easy to see how much of your application's “attack surface” was visited in testing. This telemetry is collected from every environment where the agent was run on the way to production. This feature is adored by test teams, highlighting parts of the application which are not reliably or consistently tested as you promote to production. I would also question the level of effort in improving coverage: Modern testing tools can make it trivial to produce reliable end-to-end tests of your application, and if you’re looking for recommendations in this space, then Playwright is my new love!
Stay tuned for RASP-y thoughts!
I hope some of these insights are useful and helped dispel some of the myths around IAST to give you a clearer picture. Tune in next time for my thoughts on RASP!
