Unraveling the Complexities of DevOps Security
April 29, 2019

Manish Gupta
ShiftLeft

According to a recent SANS Institute Survey titled Secure DevOps - Fact or Fiction?, only 10 percent of organizations report repairing critical vulnerabilities satisfactorily and in a timely manner. In a world where application vulnerabilities are the leading source of security breaches, that is a scary statistic, and something has to change.

However, to understand how to address this problem, we first need to understand the current state of application security. Application security operates in the Development (dev) and Production (prod) phase of the Software Development Lifecycle (SDLC). In dev, the goal is to find and fix vulnerabilities before releasing insecure code. In prod, the goal is to protect the application from all of its vulnerabilities. Theoretically, software providers only need one or the other, but since neither is foolproof, most companies employ both approaches. According to Gartner, there are three available code analysis techniques:

1. SAST

SAST (Static Application Security Testing) analyzes the application from the inside-out and is considered highly thorough because it leverages fundamental knowledge of vulnerabilities to inspect the source code. It can be used for any code as long as the programming language is supported, and is performed closest to dev, making it the least expensive way to find and fix vulnerabilities. However, traditional SAST scan times are slow, requiring hours or even days to complete, which doesn't work well in increasingly automated CI/CD environments. False positives are also an inherent part of the SAST process. Moreover, traditional SAST does not analyze an entire application (such as open source software, frameworks, etc.).

2. DAST

DAST (Dynamic Application Security Testing) probes the application from outside in, treating the application as a black box and testing exposed interfaces for vulnerabilities. DAST generally results in low false positives and can be performed even when the source code of the application is not available (for instance with 3rd party applications). Unfortunately, DAST requires test scripts to test everything, which requires heavy reliance on experts to write tests, making it difficult to scale. More importantly, by definition it only analyzes exposed interfaces, which presumes an attacker only has external access – yet insider threats and complex attacks are some of the most dangerous. DAST also provides insufficient information to the developer on why and where a vulnerability exists.

3. IAST

IAST (Interactive Application Security Testing) aims to improve on DAST by instrumenting the application to allow deeper analysis (beyond just exposed interfaces) and can be termed a superset of DAST. Its advantages and disadvantages are similar to those of DAST, with the added drawback that the application instrumentation means it needs to support the application programming language. In particular it can only be performed on languages such as Java, C#, Python, and NodeJS that have a virtual runtime environment.

A New Approach

Clearly each approach has advantages and disadvantages. If we were to develop a better AST solution from scratch, what would it look like? First, its analysis would mirror the more comprehensive inside-out paradigm of SAST, but be much, much faster. Like DAST, it should analyze the entire application, including dependencies, 3rd party APIs and frameworks. After all, a hacker only needs one vulnerability in an entire application to wreak havoc.

The analysis also shouldn't be generic. Developers should be able to leverage their application knowledge to write new custom queries or edit existing ones. For instance, if a team has written a custom API to escape inputs, the tool needs to take this API into account. A better approach also recognizes that DevOps and CI/CD is the future, and that any AST solution should integrate into CI/CD seamlessly, and display its results within minutes of each new build.

In addition to finding vulnerabilities, a better approach must understand the flow of an application so even when no clear vulnerability is identified (a false negative), monitoring of runtime behavior compared to the inherent flow of the application can identify when an application has been successfully exploited.

As noted earlier, SAST in itself is incomplete, so it should be combined with the ability to take data from the production environment to address otherwise inherent reachability challenges. This would require a microagent that deeply instruments the application (like IAST) and is designed around the stringent performance and stability requirements of a production environment. Because this microagent is designed for production, it should easily run in QA where if tested with QA/security test scripts, it can function as an "enhanced" IAST. Yet unlike IAST, the microagent should learn from SAST where it needs to instrument the application. So for example, if the application is not vulnerable to SQL injection, why instrument the application and alert on SQL injection patterns?

Given that so few organization report satisfactory and timely repair of critical vulnerabilities, there will be unfixed vulnerabilities deployed into the production environment regardless of how good an AST tool chain is. Yet today's typical security approach is to deploy a tool or appliance that continuously alerts on threats, regardless of whether the application itself is vulnerable to that particular threat.

In contrast, the better approach instruments the application based on SAST findings, ensuring the protection is high-performant and accurate. It will also tell the developer about the vulnerability and the specific location in code that needs to be fixed. That's continuous improvement — code analysis informs runtime and runtime traffic informs code analysis — the key goal of every application security program.

Manish Gupta is CEO at ShiftLeft
Share this

Industry News

May 28, 2020

Docker has extended its strategic collaboration with Microsoft to simplify code to cloud application development for developers and development teams by more closely integrating with Azure Container Instances (ACI).

May 28, 2020

Eggplant announced updates to its Digital Automation Intelligence (DAI) platform.

May 28, 2020

Aptum launched its Managed DevOps Service in partnership with CloudOps, a cloud consulting and professional services company specializing in DevOps.

May 27, 2020

Red Hat announced an expansion of its application services portfolio with the addition of Quarkus as a fully supported framework in Red Hat Runtimes.

May 27, 2020

Couchbase has completed a $105 million all-equity Series G round of fundraising.

May 27, 2020

Aqua Security closed a Series D round of $30M led by Greenspring Associates.

May 26, 2020

GitLab is releasing 13.0 of its DevSecOps platform to enable organizations to efficiently adapt and respond to new and dynamic business challenges.

May 26, 2020

Solo.io announced the availability of the Istio Developer Portal to streamline the developer onboarding process for improved developer experience and increased productivity with added security features.

May 26, 2020

WhiteHat Security will offer free application scanning services to any education institution to support secure online learning.

May 21, 2020

Exadel announced the Grand Prize winner of the “Appery.io COVID-19 Virtual Hackathon.”

May 21, 2020

CloudBees announced significant advances for its Software Delivery Management (SDM) platform – integrations with additional continuous integration and continuous delivery (CI/CD) engines, including Google Cloud Build and Tekton, and extension of the availability of CloudBees’ SDM Preview Program.

May 21, 2020

OutSystems is announcing over 70 development accelerators that ensure web and mobile applications created on the OutSystems low-code development platform can comply with the highest accessibility standards and regulations.

May 20, 2020

Styra announced that Styra Declarative Authorization Service (DAS) now supports microservices and extends context-based authorization to the service mesh.

May 20, 2020

Optimizely announced that its free feature flagging plan for development teams, Rollouts, now also includes A/B testing and feature configuration.

May 20, 2020

StackRox announced new runtime security features in the latest release of the StackRox Kubernetes Security Platform.