Skip to content

Emerging from the Tool Swamp to a Unified AppSec Platform

Emerging from the Tool Swamp to a Unified AppSec Platform

Traditional approaches to application security (AppSec) rely on a patchwork of disconnected tools and processes that add high levels of friction to the modern software development life cycle (SDLC). A unified AppSec platform provides continuous and comprehensive security across the life cycle, enabling organizations to accelerate the release of stronger software while easing the burden of IT budgets and security staffing.

Stuck in the AppSec Tool Swamp

The idea that software needs to be secured and protected is not a new one. As far back as 1979, there were versions of Lint that looked for security issues in code. After around 40 years, AppSec should have identified and codified effective ways to help businesses develop and deploy secure software. Unfortunately, insufficient progress has been made. Despite the evolution of AppSec tools and practices to date, the average number of security vulnerabilities per application has remained unchanged for years—with 26.7 serious problems on average in every release. And with over 100 billion lines of new code being written each year, that’s a tremendous amount of vulnerable software out there in the wild.

When combined with the ever-increasing number of cyberattacks, the implications are serious. For example, per Gartner, “vulnerabilities, and the exploitation of them, are still the root cause of most information security breaches today.” Per the Ponemon Institute, the cost of cyber crime increased 11% from 2018 to 2019—with organizations spending an average of $13 million to deal with the cost and consequences of cyberattacks.

To combat this situation, many organizations simply stack up multiple tools and hope they do the job. But many of these solutions are disconnected, siloed, and specific to different users—a “tool swamp” that makes identifying and fixing vulnerabilities an inefficient, expensive, and time-consuming endeavor.

The tool swamp adds drag and complexity to both security operations and development pipelines, requires multiple teams of experts to interpret results, and frustrates developers and puts them at odds with security. This might be one of the reasons why between 31% and 48% of firms feel security is a major constraint on delivering software quickly. Considering the pace at which developers work these days, particularly those engaged in Agile development and DevOps, there is no way that traditional security tools and processes can keep up.

Embracing DevSecOps

To address these problems, organizations need an approach to AppSec that aligns the objectives of development, security, and operations. DevSecOps is the promise and practice of bringing security to the “DevOps Party.” It aims to weave security into modern software development and information technology principles and practices that aim to shorten the software life cycle and provide continuous delivery with high quality.

DevSecOps encourages AppSec approaches that shift both left and right across the SDLC. It encourages “systems thinking” by promoting alignment and collaboration between developers, release engineers, security teams, and operations teams around shared quality, agility, and security goals. As a result, it promotes a unified, and unifying, approach to AppSec.

Continuous AppSec Across the Entire SDLC

In support of achieving a functional DevSecOps practice, a security instrumentation-based AppSec platform provides continuous, unified application security across the SDLC. Security instrumentation passively monitors applications from the inside, as they are used. It lights up runtime code paths like an X-ray or fluoroscope, providing code-level details for both custom code and libraries. It also unifies AppSec stakeholders in the following ways:

  • Development teams get immediate feedback on code-level vulnerabilities in their native tools and processes, with AppSec woven into integrated development environments (IDEs), ChatOps, and ticketing systems. Developers see runtime proof of vulnerabilities that they can fix, as they are working, even before they check in code.
  • Quality assurance (QA) teams see the value of their testing doubled. Security instrumentation follows the runtime path codes of end-to-end testing exercises, mapping all functional testing coverage into security testing coverage, with no additional effort.
  • Continuous integration/continuous deployment (CI/CD) processes benefit from seamless integration with build orchestrators, allowing AppSec to be used as a quality gate for every build or release.
  • Operations teams get detailed attack forensics and real-time exploit prevention for production applications, as well as integration with incident management and data visualization systems, and security information and event management (SIEM) solutions.  

Shifting Left with IAST   

At the left end of the SDLC, security instrumentation provides interactive application security testing (IAST). IAST examines every code path exercised while applications are used and tested. If a code path is not properly sanitizing and validating the data it is processing, a vulnerability is confirmed, and instant details are sent to developers as they work. This information is not limited to a single static location in code; it’s an entire source-to-sink code flow that includes line-of-code level detail. Static application security testing (SAST) and dynamic application security testing (DAST) solutions cannot match the speed, accuracy, or details of this approach.

Huge Risks of Open-source Software     

Today’s problems are not limited to custom code. As Gartner notes, “99% of the vulnerabilities exploited by the end of 2020 will continue to be ones known by security and IT professionals at the time of the incident. In platforms such as Java, the use of open-source software (OSS) is ubiquitous and growing, leaving more and more code needlessly vulnerable. A comprehensive AppSec solution must deal with this situation, and security instrumentation provides the answer. It associates class-level code in OSS with associated CVEs and the applications that use the code. Security instrumentation tells developers not just that they’re using vulnerable libraries, but exactly when and how those vulnerable libraries make their applications vulnerable.

Shifting Right with RASP   

In general, it’s impossible to guarantee that an application will always make it into production in a vulnerability-free state. There is always risk from latent vulnerabilities or unpatched libraries. Organizations also need to run legacy applications and third-party applications that are crucial to their businesses. These situations require that AppSec shift right as well as left.

Runtime application self-protection (RASP) uses the same concept of security instrumentation to provide a defense-in-depth layer inside running applications. Such a layer acts as a second line of defense behind web application firewalls (WAFs), ensuring application security by detecting and blocking attacks from inside the running application itself. In contrast to a WAF, RASPs have the advantage of security instrumentation that follows suspicious input along the runtime code paths.

RASP, as a result, can decide if an attack needs to be blocked (based on matching suspicious data with vulnerable runtime code). This provides high accuracy as well as detailed forensics that organizations can leverage to improve their security posture.

AppSec-as-Code: Scaling Across the Applications Portfolio

The embedded nature of an instrumentation-based approach to AppSec eliminates friction during application on-boarding and deployment processes. Instrumentation can be provided in various forms: Libraries, native modules, dynamic-link libraries (DLLs), gems, and other modules that allow AppSec to be treated as any other deployment artifact.

AppSec-as-Code deploys with applications, leveraging CI/CD tooling, infrastructure management, and package management systems to provide automated parallelized deployment that scales across the application portfolio. And AppSec-as-Code runs wherever applications run—containers, Platform-as-a-Service (PaaS), microservices architectures, in the cloud, or even on-premises behind a firewall. Regardless of how an application is deployed or where it is run, AppSec-as-Code goes with it.

Software Is the Future

Software really is eating the world. The more dependent a company is on software as part of its lifeblood, the more the above considerations directly impact the success of the business.  

For more information on how Contrast Security can help on your DevSecOps journey, check out our “A Comprehensive Approach to DevSecOps” eBook.


Robert Statsinger - Senior Solutions Architect

Robert Statsinger - Senior Solutions Architect

Robert Statsinger has worked in Application Security for the past few years. His prior experience includes Applications Performance Management and its impact on DevOps, Intelligent Device Management, Enterprise Applications Integration, and developer tools and middleware. Robert holds a Masters Degree in Computer Science from the University of Southern California.