Overcoming 5 Challenges to Shifting AppSec Left

Developer-first is the future of application security.

Digital transformation and the speed at which applications are developed and deployed are moving at a rapid pace. Businesses have always competed to see who can be the first to respond to customer needs, mainly in hopes of capturing some of a competitor’s market share. DevOps and the cloud have enabled software development to move from the annual updates of yesteryear to shipping releases daily to what we now call continuous delivery (CD). 

Unfortunately, the security industry has fallen behind in its ability to keep pace with modern developer teams in many ways. It may be more accurate to say security was left behind. As developers assumed ownership of applications through development and operations, security was left in a silo — a gatekeeper expected to review code, find vulnerabilities, and send the results back to the developer team for remediation.

There is often friction today between developers and application security teams as they try to provide security the same way as in the days of annual releases. I know; I have experienced this tension first hand throughout my security career. I saw how difficult it could be to try and scale an AppSec program to keep pace with modern software development. 

In this article, I’ll discuss what I’ve learned and explore the top five challenges faced by AppSec teams that hold them back. 

Challenge 1: Security Teams Do Not Have Visibility or Control Over the Risks Introduced by Developers

It’s easy to understand why it would be frustrating for security teams to be tasked with reviewing software only to have the vulnerabilities they identify ignored. Security teams can feel blindfolded and shut out without visibility into the business needs and constraints under which the software is produced, and left without a seat at the table as potential risks are evaluated and assumed. 

The solution for this challenge is to integrate security into the development process by codifying and automating security controls as guardrails in the CI/CD process. This integration is not an entirely new concept; development teams are already accustomed to ensuring that software meets certain quality, reliability, and performance thresholds. Security needs to be another threshold for which developers are accountable.

Challenge 2: AppSec Tools Generate Unactionable Noise

The tools used by AppSec teams generate too much noise, including false positives and unactionable alerts. The process of identifying what’s relevant and actionable is time-consuming and wastes valuable resources.

Security tool vendors primarily focus on bringing solutions to the market that can identify every potential security vulnerability. In their attempt to provide tools that are easy to use and require no programming skills to operate, these solutions create more noise than teams can effectively handle. 

Instead of triaging every possible vulnerability reported by the tools, AppSec teams should instead focus on defining safe coding patterns and identifying which classes of bugs are relevant to the organization. They should then convert these findings into security guardrails that get implemented in the developer workflows. 

This approach to security provides continuous feedback to developers and enforces security requirements in a scalable manner. This paradigm flips the process from reacting to noisy alerts to defining what is relevant to your organization and only generating signals for things that matter.

Challenge 3: Security Tools and Processes Typically Operate Outside Developer Workflows

Every AppSec tool is a data silo, and developers don’t have the time or bandwidth to learn how to operate multiple security tools. This isolation leads to security teams having to communicate actionable items manually (e.g., filing tickets) and following up with developers. This process is not scalable and is a waste of AppSec resources.

Instead, teams should consolidate data from AppSec tools into a single centralized data repository which can become the single source of truth for security and development teams. Actionable data from this centralized data repository should then be communicated to developers directly in their own workflows using collaboration systems they are familiar with, such as Github, Slack, Jira. This improved method helps make security a first-class citizen within development processes.

Challenge 4: Software Ownership or Code Attribution Is Difficult for Engineering Teams and Security

Many AppSec teams spend too much time trying to figure out who really owns the relevant parts of code and who should fix the security bugs. Most organizations do not have a clearly defined code ownership process. AppSec teams, therefore, spend valuable time going back and forth to find the rightful owner. Trying to assign attribution within their own organization is both time-consuming and frustrating.

An evolving solution to this challenge is emerging as many programmers adopt git-based code ownership management. Leveraging one of these systems enables dev teams to declare code ownership and the metadata associated with code owners like tech leads, communication channels, Jira projects, etc.

Challenge 5: Lack of Accountability Results in Finger-Pointing

Driving accountability is always a challenge in a distributed function like security, that works with different teams and departments across the organization. More often than not, security challenges result in a finger-pointing exercise where nobody takes responsibility. 

As an industry, we need to transform AppSec into a data-driven function, where teams rigorously collect data and measure security performance across the organization. Every AppSec team aiming to drive ownership and security accountability must build the capability to collect the right security data throughout the software delivery lifecycle and report the right metrics at every level of the development organization. 

The same way development teams measure themselves on software quality, performance, and reliability, AppSec programs need to empower dev teams to measure and improve themselves using application security KPIs. 

Preparing for a Developer-First Future of Application Security

Developer-first application security is necessary to allow AppSec teams to rise above spinning their wheels on low-value tasks. As long as AppSec programs ensconce security teams as a gate that works against the business goals of speed and agility,  there will continue to be frustration and discord between DevOps and AppSec. 

Up till now, security hasn't been a part of the DevOps journey, and more than just shifting left, AppSec programs must empower dev teams to make security decisions and hold them accountable for outcomes. 

Instead of acting as a gate, organizations must integrate security processes into the software delivery life cycle. This is the future of application security.