A common misconception that we often hear when talking to our clients about IAST tools is that they are only helpful during the development phase.

This idea is probably rooted in the role that legacy AST tools such as SASTs have traditionally played in the overall application security workflow.

We briefly touched on this subject in our previous IAST post, but we wanted to give it proper attention. So we going to start describing the main IAST Use Cases across the three main environments: development, QA, and production. This post in particular will be focused on how QA teams can utilize IAST tools.

QA Security Pain Points

As the maturity level of a software development organization evolves, and the QA group gains relevance, we often see the following security pain points:

1. Unclear ownership of application security acceptance

The QA team is typically tasked to provide the final GO/NOGO on an application before pushing the code into production stage. In this sense, they act as app security gate keepers, both in case the application is developed internally, and also when application development is outsourced. However, many organizations have no clear process in terms of security assessment, because it is not easy to automate this evaluation.

2. Low detection accuracy and false positives

Traditional AST tools such as SASTs are well known for throwing a large amount of false positives that distract the QA teams. On the other hand, DAST tools are not able to detect most risks and vulnerabilities.

3. Difficult communication between teams, and lack of metrics

QA teams work with developers and the operations teams. Frequently, it is not clear how the QA team communicates and maintains the results of the review process. In Agile environments, nobody wants to consume static reports that are outdated after minutes. There are no clear indicators (metrics) that reflect the security stance of the applications. Developers and QA tribes speak different languages.

Vulnerability Trend

QA team could analyze detailed information for each vulnerability detected during the latest test execution phase

4. Slow and expensive security testing

Because traditional scanning tools such as DASTs are slow and have a low detection rate, QA teams must have security experts to properly evaluate the security of the application. The need of security experts slows down and adds cost to the development.

IAST as a solution to QA security pain points

Pain point #1: Unclear ownership of application security acceptance

Solution: IAST tools empower QA teams to conduct dependable security analysis

IAST tools provide the QA team a direct and immediate way to assess the security stance of the application. IASTs work no matter who wrote the app, so the QA team can create a repeatable process that it is completely independent from the development teams.

Pain point #2: Low accuracy and false positives

Solution: Hdiv IAST covers 100% of OWASP Benchmark, with no false positives

Due to their privileged vantage point, which combines visibility of source code and visibility of the runtime flow of data, IAST tools are able to detect 100% of the OWASP Benchmark battery of tests, with no false positives. According to Forrester, “IASTs eliminate the need for separate dynamic application security testing.” [1]

Pain Point #3: Difficult communication between teams, and lack of metrics.

Solution: Integrate security issues within your general bug tracker

IASTs provide different channels to consume and communicate the results of the analysis. Some teams use a centralized console, while others connect the IAST to the bug tracking tools (Jira, Asana, etc) so that security risks are treated like any other functionality defect. Moreover, the QA team now has a direct hard metric to check the security of an entire application: the number & severity of risks.

Pain point #4: Slow and expensive security testing

Solution: IASTs automate the QA security validation according to metrics

IASTs do not require apps to be attacked to produce a risk analysis. By just browsing the application, IASTs leverage their visibility of source code and execution flow inside the app to detect security risks in real time. According to Forrester, “a DAST can introduce a 5 to 7 day delay” [1]. There is no need to have a security expert to operate an IAST tool, which results in faster and less expensive QA phases.

Workflow best-practices: how successful QA teams use IAST tools

This is a complete example of a QA review cycle that includes an IAST to provide fast and reliable security assessment of the application being tested:

    1. As a first step, the IAST is installed transparently by deploying an agent in the QA application server. There’s no need to have access to the source code of the app being tested, and it does not matter whether the app was developed internally, or outsourced. Third-party libraries are also reviewed as part of the process.
    2. Then the QA team conducts its preferred assessment benchmark, which may include automatic scanners (such as Selenium and Burp), UX/UI validation, manual reviews, and/or batteries of automated test cases. It’s business-as-usual for them. Even better, there is no need to specifically attack the application.
    3. While this assessment is performed, the IAST agent monitors the application from the inside out, and checks for risks and vulnerabilities from a privileged vantage point. The QA team, in turn, consumes the analysis in real-time via a high-level monitoring console, and/or via the integration with a bug-tracking tool. No need to wait for the generation of a static report.
    4. After this process, the QA team has a clear picture of the security stance of the application. Then the QA team can make an informed decision based on hard metrics such as the number and severity of the risks detected. All this without ever having to analyze the source code directly, nor specifically attack application. There is no need of having security experts in the QA team anymore.
      Hdiv IAST Console
    5. For teams that perform CI/CD integration via Jenkins or Maven, advanced IAST solutions enable automated blocking of the deployment pipeline, if the application suffers from a number of security risks beyond a threshold. Typically the App Sec team sets these security compliance parameters, and the QA team enforces them. The IAST automatically checks the security of the apps as part of the build routine.

    Hdiv IAST Continuous Integration chart

Drop us a line if you want to learn more about IASTs!


[1] Forrester Research, Construct A Business Case For Interactive Application Security Testing, November 2017

Comments are closed here.