Identify Critical Security Vulnerabilities With IAST
Vulnerabilities in production code continue to increase, including vulnerabilities in open source codebases. According to a recent report from Synopsys, the number of open source vulnerabilities increased over the past year to a record 84%. Part of this increase may be attributed to the need for organizations to get their applications to production quickly to meet the demands of a remote workforce. Rushing applications to production often means less-rigorous testing and the release of applications that still contain critical vulnerabilities.
Adopting AppSec Testing Tools
Many organizations are now shifting left to try and resolve security issues earlier in code development and decrease the critical vulnerabilities found in production. The move to shift left includes the adoption of testing technologies like static application security testing (SAST) and dynamic application security testing (DAST) during application development.
But companies often find that SAST and DAST tools lead to the discovery of an overwhelming number of vulnerabilities, translating to delays in application development and longer product development life cycles. The reason? Many SAST and DAST tools report a high rate of false positives. Working through a huge list of vulnerabilities to determine which ones are real and which ones are false can be daunting. And for those vulnerabilities that are real, SAST and DAST tools don’t typically provide the information needed to clarify how serious or exploitable these vulnerabilities actually are nor do they provide the recommended directions to address them.
When overwhelmed with the high number of vulnerabilities being reported by SAST and DAST testing tools, organizations are also less likely to fix all of them, especially when they lack verification or proof of an exploitable vulnerability. A 2020 ESG report, The State of Application Security, found that 79% of organizations knowingly release vulnerable code to production on a regular basis.
Enter IAST.
NIST and IAST
Recognizing the need for better results from application security testing and application security in general, last fall the National Institute of Standards and Technology (NIST) added two important new application security requirements to its security and privacy framework. Released as NIST SP800-53 Revision 5, the new document adds runtime application self protection (RASP) and interactive application security testing (IAST) to its requirements. It’s a first in recognizing these two advancements in application security by now requiring them as part of the security framework.
IAST builds upon the technology used in DAST. DAST provides black-box testing, using attacks on the application to detect vulnerabilities. IAST adds an agent running directly on the application server for greater visibility and understanding of the attacks carried out by the testing server. The agent offers greater visibility to provide crucial data that the DAST component is missing.
By residing on the server, the IAST agent typically instruments the code, giving IAST the ability to watch the application code as it is executing. Advanced technology—like deterministic security used by some IAST tools—validates that the code is executing correctly, giving it the ability to verify a vulnerability has actually been exploited and provides valuable information a developer needs to remediate vulnerabilities that are discovered.
For example, many IAST tools can provide the payload used to attack the vulnerability along with proof of exploitability. In addition, IAST can pinpoint the location of the vulnerability in the code down to the filename and specific line of code where the vulnerability exists, enabling a developer to quickly locate the vulnerability for correction. Based on the flaw’s exploitability, IAST tools can also provide an associated level of risk for the vulnerability.
Adopting IAST Tools
IAST tools are available in either active or passive (and sometimes both) deployments. Active deployments use attacks like the ones that DAST tools use for vulnerability detection along with the agent running on the application server. Passive IAST uses normal QA testing along with the agent to detect vulnerabilities by fuzzing the code as it is executing to look for problems. Some IAST tools can use either approach.
The detailed telemetry that IAST provides about the vulnerability helps the developer rapidly remediate detected vulnerabilities before code is released to production. It also helps identify which vulnerabilities carry little or no risk of damage so that they can be released to production.
Another important use case for IAST involves false positives. When an IAST tool doesn’t detect a vulnerability that is reported by a SAST or DAST test, it provides a valuable use case to look for a false positive first, rather than have developers work on vulnerabilities that most likely don’t exist and that would otherwise use up a lot of the developer’s time on an unnecessary task.
For organizations that think they’re not ready to move to IAST yet, there’s an easy way to try IAST in existing testing environments. Testing teams can use an IAST agent with existing DAST testing, enabling organizations to leverage existing investments in their testing tools and training while getting the added insight and benefits that using an IAST agent provides.
By providing the visibility that other tools lack, IAST gives organizations the ability to manage the vulnerability overload, and the information needed to enable their developers to work more effectively. With IAST, enterprises get the critical vulnerability detection and information they need to make decisions about the prioritization of vulnerabilities to remediate, which to defer and which can be harmlessly released to production, along with assistance in detection of false positives produced by their other tools.
Now that NIST has officially added IAST to its Security and Privacy Framework, it’s time for all organizations to take a fresh look at their application security and the tools they use in their own infrastructure.
