DevOps principles and practices are continuing to be adopted by a wide variety of companies, and here at Synopsys we’re working with our customers to help them in this journey. When it comes to DevSecOps, we have a comprehensive portfolio of products and services to help build security into every DevOps environment. In this blog post, learn how Synopsys addresses typical challenges that DevOps teams often see when incorporating security into their continuous integration/continuous development (CI/CD) pipeline.
Always be testing
One of the key enablers of DevOps is automation or continuous testing, which fits or aligns with the continuous integration and delivery concepts. Improving the reliability of your product delivery largely depends on how well you can find bugs, and how fast you can fix them (at least the critical ones).
This principle is also true for security. I want to reiterate (and reframe): Improving the reliability security of your product delivery largely depends on how well you can find bugs vulnerabilities, and how fast you can fix them (at least the critical ones). According to a recent DevOps report, “Among companies with full security integration [into CI/CD], 45% can remediate critical vulnerabilities within a day.” Isn’t that amazing? I vividly remember numerous industry reports that averaged the number of days to remediate a vulnerability to 14 days or more. So how can we get from 14 days (or whatever your number is) to 1?
Shift left, right, and everywhere in between
Integrating security at every stage of the CI/CD pipeline is more than just shifting security to the left. Let’s take a look at a typical CI/CD process.
Figure 1. The typical CI/CD pipeline with added security context
That should look familiar—the image depicts mapping the appropriate security controls to CI/CD stages, but there’s a catch, and some questions we need to ask:
- What security controls are appropriate for the test stage?
- How do you test your releases for exploitable vulnerabilities before they’re pushed into production
- How do you do that without slowing down the delivery process?
- How do you verify that vulnerabilities caught at the earlier stages were fixed?
Traditional runtime security controls lag behind
With all the love I have for dynamic application security testing (DAST), fuzzing, and penetration testing, I must admit that they are inadequate controls for the testing stage for the following reasons:
- It takes time and expertise to run them—in most cases you don’t have either one of those.
- They might be too expensive (and too late)—especially penetration testing.
- They provide almost no actionable feedback to developers—it’s a black box testing.
- It’s difficult or impossible to integrate into CI/CD pipelines in the automated fashion.
Fortunately, there is a technology that eliminates all these gaps.
Interactive application security testing
Interactive application security testing (IAST) is an application runtime security testing technology that uses instrumentation to find and validate vulnerabilities in an application while it’s running. The technology is a much better fit to the DevOps testing phase. IAST benefits include the following:
- It’s automated and doesn’t require an expert (or any human for that matter) to run it.
- It’s accurate and produces high-quality findings.
- It’s actionable. Unlike other runtime testing technologies, it can pinpoint the exact line of code where a vulnerability was found.
- It can be easily integrated into the CI/CD process.
- It can test web applications, web APIs and microservices.
How to deploy IAST
IAST is deployed by adding its agents to the web server where your applications are running. The deployment process can be easily automated as well, and it works great with containers and cloud infrastructure. Because IAST is a dynamic runtime security testing technology it requires some amount of traffic to be put through an application. Fig. 2 depicts a typical deployment of IAST.
Figure 2. A typical deployment of IAST
When developers release the code, it enters a testing phase in which a set of automated and manual tests are run. As this traffic goes through applications, an IAST agent analyzes how the applications process the traffic. If applications have vulnerabilities, IAST agents will detect them and provide immediate feedback.
Why DevOps teams choose IAST
Now it’s time to answer the question I put in the headline. While every application and CI/CD pipeline can be different, here are some common reasons why to choose IAST:
- IAST identifies high and critical vulnerabilities at much lower cost as compared to static application security testing (SAST) and DAST.
- Some vulnerabilities marked as fixed at earlier stages of the pipeline still can be found at the testing stage in running applications.
- IAST identifies actual exploitable vulnerabilities in a running application, so it’s much easier to prioritize remediation activities.
- There’s a significant reduction of penetration testing costs, as most of the exploitable vulnerabilities are found by IAST.
You may also ask how this helps to remediate critical vulnerabilities within one day, another question I asked in the beginning. Let’s be honest, IAST or any other technology is not a silver bullet that alone can solve the problem. But in order to remediate critical vulnerabilities faster, you need to start detecting them faster and more accurately, without spending days (or even weeks) looking at false positives or true positives that aren’t exploitable/reachable. That’s exactly what IAST does for you.
Continue Reading
