DevSecOps

As organizations rush to embrace various digital transformation initiatives, DevOps (development and operations) becomes an increasingly critical focus. According to a report from OpsRamp, nearly two-thirds of organizations indicate they plan to increase their DevOps (as well as Agile, which is similar in nature to DevOps) investments this year.

DevOps Security (DevSecOps) Becomes important for secure SDLC

The jury’s decision is out: Waterfall development approaches cannot satisfy the velocity and agility requirements of modern software development, which demand more code commits and faster release cycles. Instead, organizations are embracing DevOps, which offers development teams the ability to go from software release cycles measured in terms of weeks or months to days. DevOps involves automated testing of small pieces of software at the unit level and at the integration level.

Software instrumentation is a critical enabler of this process, embedding software development workflows and processes within the software. Doing so makes those point-in-time workflows and processes continuous and real time. This, in turn, dramatically improves the accuracy of the respective workflow or process. Software instrumentation also unlocks automation, enabling DevOps teams to improve efficiencies and shorten software development life cycles (SDLC).

But there are security challenges that come with DevOps. Legacy application security models relegate security to the final stage of development, when pen testing tools are used to analyze the code for application vulnerabilities. This creates gates that slow SDLC, with many releases taking months or even years to complete. Under this scenario, organizations are unable to tap the business opportunities of digital transformation—and specifically DevOps—where velocity and agility differentiate successful and failed projects.

Reviewing legacy SAST and DAST scanning methods

The continuous workflows and processes of SDLC demand a software security paradigm shift. Vulnerability scanning tools cannot support continuous software development since they are designed for point-in-time security scans at the end of the SDLC—“bolted” onto code right before it is deployed. In response, some DevOps security providers have attempted to shift left, moving vulnerability assessment earlier in the SDLC. DevSecOps (which is sometimes called SecDevOps) can mean different things depending on the security approach in question. The following is a quick overview of the different approaches and solutions (SAST vs. DAST vs. IAST).

Assessing the efficacy of SAST tools for DevSecOps

In the case of static application security testing (SAST), it uses predefined security signatures to perform static code analysis. Because SAST tools use security signatures to identify vulnerabilities, they are unable to pinpoint unknown threats. These false negatives increase security software risk. SAST tools also become complex to manage when used in web application environments where multiple languages are used. As separate SAST tool configurations are required for each language, this results in a tool swamp that is complex to manage for busy DevSecOps teams.

False positives are another significant problem with SAST tools. Vulnerability scanning pinpoints every known application vulnerability—regardless of whether it can be exploited. Developers can waste upwards of three hours diagnosing each false positive. With research revealing that over one-quarter of security alerts are false positives today, this is a huge time expenditure that translates into release delays and time that could have been spent writing code.

In addition to the above, SAST puts the onus of security responsibility on developers. Manual vulnerability management incurs significant time to identify vulnerabilities as well as to verify their remediation. To effectively manage vulnerability identification and fixes, however, developers must become security experts in their own right to conduct static code analysis, which requires ongoing training and subject-matter expertise—something most developers do not want to assume.

Assessing the efficacy of DAST tools for DevSecOps

DAST tools analyze application runtime with vulnerability scanning to detect possible security vulnerabilities. DAST tools continually search for vulnerabilities in a web application. Upon identifying a vulnerability, DAST tools send an alert to the appropriate team so that they can take action to fix the vulnerability.

One of the downsides of DAST tools is that they provide no contextual insight into the underlying cause of a vulnerability. Identifying an actual fix and then verifying it can be time-consuming. And because it lacks context, a DAST tool often cannot simulate an attack since exploits are often executed by bad actors using malicious code that has specific knowledge about the application.

DAST tools are also not good fits for early stages of the SDLC as they can only work in application runtime. As vulnerability fixes cost increasingly more to fix the further to the right in the SDLC, DAST tools can incur more time and costs than other DevSecOps solutions that shift further to the left.

Because DAST tools rely on a signature-based engine, they are plagued with the same false-positive and false-negative challenges as SAST tools. These false positives waste valuable time for DevSecOps to manually verify each of them. This slows down vulnerability scanning, thereby increasing the cost of a scan as well as elongating release cycles. In addition, as DAST tools are not configured to identify unknown threats, false negatives are missed, which can potentially result in a successful breach or operational disruption/outage.

Using IAST for modern DevSecOps

Modern DevSecOps requires a different approach to application security. Vulnerability scanning tools are based on a nearly 20-year-old technology model. Interactive application security testing (IAST) employs a different model. Security instrumentation is embedded within software using agents and sensors. It also unlocks automation of vulnerability identification and verification of remediation, which is a significant improvement on automated penetration testing.

Rather than point-in-time security visibility as with SAST and DAST, IAST enables continuous, real-time vulnerability management and looks at much more than just code as the case with vulnerability scanning solutions: runtime control and data flow information, configuration information, HTTP requests and responses, open-source libraries, frameworks, and other open-source components, and back-end connections. 

The false positives that come with SAST and DAST tools are absent with IAST. Because IAST only identifies vulnerabilities that can be exercised in an application, false positives are virtually eliminated. No longer does DevSecOps need to spend valuable time tracing the causes behind purported vulnerabilities that cannot be exercised in an application. Plus, IAST categorizes vulnerabilities based on those that are most common and at the highest risk, enabling DevSecOps to perform continuous security risk assessments of their application.

Unlike SAST and DAST tools that are unable to identify unknown vulnerabilities because of their reliance on signature-based engines, IAST uses route coverage or intelligence. Both known and unknown vulnerabilities are pinpointed, as a result. This eliminates false negatives that can pose serious risk to an application.

Months of time configuring and tuning SAST and DAST tools, which often require additional security staff and specific skill sets, are also obviated with IAST. And because IAST uses instrumentation, it is simple and fast to deploy and runs continuously within the software. This also means there are no coding disruptions for breaking checkpoints that slow release cycles.

Extending DevSecOps to open source

The adoption of open-source frameworks and libraries has grown exponentially in recent years, as developers seek to accelerate the velocity of application releases. Here developers can use, modify, and share open source. This use of open-source software helps developers to lower costs and reduce time to market by reusing existing components as building blocks for applications. An estimated 90% of applications use open-source code today. The amount of open source being used in application development jumped 40% this past year as well.

While open source is a critical enabler of DevOps, the risks of open-source software can be significant. On the one hand, even though open source is free to users, this does not mean that it comes without licensing requirements. Licensing stipulations range from extremely permissive versions to highly restrictive ones. Using undeclared or restrictive licenses of open source can present serious risks to an organization’s intellectual property and compliance. On the other hand, open source also presents security risks. OWASP, the originator of the OWASP Top 10, finds that the most critical web application security vulnerability is the use of older versions of open-source components with known vulnerabilities.

The first step to open-source security software is to define the characteristics of all components in an application. A software bill of materials is the best way to do so. In addition to mapping out all open-source obligations under license, this shows direct and indirect dependencies that can be used to track license, quality, and security variables. Just like custom code, open source must be continuous and automated. This is achieved using security instrumentation. Open-source vulnerability scans are inadequate, providing point-in-time snapshots that quickly become outdated since the use of open source is dynamic.

Extending DevSecOps into production runtime with RASP

Modern applications require DevSecOps that extend from development and testing into production. Traditionally, organizations employ deficient perimeter defenses using web application firewalls (WAFs). These are powered by signature-based threat engines that generate huge volumes of false positives and false negatives. This creates a huge headache for security teams that must cull through long lists of flagged vulnerabilities that turn out to be false positives. But because they are not configured to address unknown vulnerabilities, they also produce false negatives that increase risk.

WAFs use an outside-in security approach. Runtime application self-protection (RASP) employs an inside-out model whereby instrumentation is used to place security right alongside vulnerabilities within the software. When malicious code attempts to execute a vulnerability—known or unknown—the RASP stops it from exercising the vulnerability in real time. This production runtime approach to security virtually eliminates all false positives.

In addition to the above, a RASP produces virtually no false positives because it runs within the application. In contrast, WAFs require immense amounts of constant fine-tuning to manage false positives. 

Time to shift application security to DevSecOps 

Application security that relies on manual vulnerability scanning slows release cycles and creates friction between security teams and developers. The proliferation of application programming interfaces (APIs), containers, and microservices for DevSecOps results in a security tool soup that increases the complexity of managing application security. Static code analysis cannot accommodate the continuous integration/continuous deployment (CI/CD) pipeline.

An outside-in application security approach simply cannot accommodate these DevSecOps changes. It requires an inside-out security paradigm shift, whereby instrumentation embeds security without software. Application security testing becomes a strategic advantage—providing the speed and agility organizations require to ride the wave of digital innovation.