Application Security's New Mandate in a DevOps World

By Jason Schmitt, General Manager, Synopsys Software Integrity Group

An increasing number of organizations are embracing DevOps to automate and accelerate their software development and delivery processes. The benefits are clear: faster time-to-market, improved customer satisfaction, increased efficiency and productivity, and better communication and collaboration between teams.

But the unintended side effects of the DevOps movement are a bit more nuanced. Many companies are struggling to adapt their application security practices to the DevOps paradigm. Emerging technologies like continuous delivery pipelines, cloud-native development platforms, and generative artificial intelligence (AI) are transforming and accelerating software delivery to the point where many of the traditional approaches to application security are ineffective.

This dynamic is driving a shift in the practices, tooling, and culture required to run an effective DevSecOps program, whereby application security activities can be integrated seamlessly to keep pace with DevOps workflows.

Speed vs. Security: A Zero-Sum Game?

Traditional waterfall development methodologies provided security teams with a predictable and dedicated window of time at the end of the software development life cycle (SDLC) to perform a battery of the necessary security testing and remediation efforts. This stage-gate approach disintegrated with the advent of continuous delivery, falling away in favor of DevOps and its highly automated, rapid, and iterative approach to development.

As a result, many organizations contemplate whether they can or should make compromises in their application security controls to keep pace with development. Should application security efforts be deprioritized in favor of speed, or is security a non-negotiable?

Despite the wrinkles DevOps ironed out of power struggles between traditional development and IT teams, the push and pull between speed and security remain. But is this a zero-sum game, where an organization must sacrifice one in favor of the other?

In short, no. While on the surface, it seems that speed and security are at odds, this friction is helping drive innovation and change within the application security domain.

Evolution of AppSec Tooling

The bar continually rises on the amount of automation that should be applied to development environments without compromising security efficacy or hindering the velocity of modern development. Organizations are not willing to slow their shift toward cloud-centric, API-driven, super automated pipelines, and they have more specific screening criteria for their application security tooling. Application security vendors are evolving their technology in remarkable ways to provide accurate, automated, and, in some cases, instantaneous feedback within development pipelines.

Guardrails Instead of Gates

Security teams are learning that they can no longer impose inflexible mandates or security controls that impede developers' workflows. They need to provide tooling that guides developers in real time and enables them to address security issues proactively before they propagate downstream in the development pipeline, where they can cause friction and delays. This has the bonus of boosting productivity while improving security. The tooling needs to provide prioritized security testing results and actionable remediation guidance within the development toolchain.

The Myth of Shared Security Responsibility

A decade ago, security and development teams were siloed. Security teams were focused on finding as many vulnerabilities as possible, but they often had to depend on the developers to fix them.  

Since then, many organizations have attempted to distribute the responsibility of application security among developers. While DevOps has indeed changed the dynamic of application security, it is a fallacy that security responsibility has truly shifted to developers — security teams still own security. Developers obviously have a role to play, but it is still not their top priority, and probably never will be.

Today, the most effective programs come from security teams who embed themselves into development and foster security champions across the organization. These security teams are sympathetic to developers' constraints and success criteria, which makes them more credible in incentivizing development to support security initiatives. Increasingly, security teams are accepting that they cannot succeed without developer buy-in, so a cultural shift in mindset, tooling, and operation is critical.

Are "Good Enough" AppSec Solutions Really Good Enough?

We are witnessing the rise of development platforms with built-in or add-on security features. These features are designed to prioritize speed and simplicity, increase ease of use, and reduce friction.

These ecosystems have unlocked the ease and transparency organizations need as development speeds increase, promising to deliver more security controls earlier and natively in the pipeline. Fatigue is a common theme for organizations that have rolled out security programs, often over many years, making this "quick fix" very appealing.

The risk of these platforms is in the false sense of security they engender — security is too easy. Sophisticated security analysis and tools are still critical for detecting some of the most malicious and dangerous vulnerabilities (think complex memory overflow, cross-site scripting, SQL injection). These platforms cannot effectively identify the most dangerous vulnerabilities in a complex application in the seconds they take to deliver results.

Organizations should find a balance between "lightweight" security analysis that can catch simple problems early, and a much more comprehensive AppSec tooling strategy capable of the depth and breadth needed to identify business-critical risks.

In response to this changing security landscape, the AppSec vendor market is moving to evolve its offerings in kind. Vendors are striving to deliver AppSec tooling that is full scope, offers a comprehensive view, and can stay current with modern development advancements. This is no easy task.

What's Next? 

The age of DevSecOps is here. For developers, that means embracing practices, technology, and the culture of the DevOps movement and all the benefits it affords. For security teams, it means adapting to development's moving and maturing parts by embedding within existing processes. For application security vendors, it means innovation and growth. And for organizations, it means striking the right balance between speed and security, because it is possible.

About the Author:

Jason Schmitt is a seasoned leader with a proven track record of deep technical knowledge, product development, insight into emerging and rapidly changing cybersecurity challenges, and go-to-market strategy and implementation. He brings more than 20 years of experience in security and enterprise product development and management. Jason most recently served as CEO of cloud security startup Aporeto, where he led the company from pre-revenue through a successful acquisition by Palo Alto Networks. He has a deep background in software

development and application security– leading Enterprise Security Products at Hewlett Packard as Vice President and General Manager of Fortify and ArcSight. Jason combines security domain expertise with strong experience delivering SaaS/cloud-based solutions. Jason is a Louisiana native, who completed his Bachelor’s in Mechanical Engineering and Master’s in Computer Science at the Georgia Institute of Technology, and his MBA at Georgia State University’s J. Mack Robinson College of Business.