Back

5 Most Common Challenges To Shifting AppSec Left and How to Overcome Them

Shifting AppSec Left? Here are the 5 most common AppSec challenges teams face and what can be done to overcome them.
read

The speed at which applications are developed and deployed means businesses must move quickly to meet customer needs. In the past, companies would compete to see who could be the first to respond to what their customers want to gain market share. However, with the advent of DevOps and the cloud-native application and infrastructure, software development has moved from quarterly/annual updates to shipping releases daily/weekly, which we now call continuous delivery (CD).

While this is transformative for the development side of the house, security teams have been unable to keep up. Developers have taken ownership of applications through development and operations, leaving security in a silo. Organizations now expect security to review code, find vulnerabilities and send the results back to the developer team, where remediation will occur – which is a time consuming process.

There is often tension between developers and security teams when providing security using legacy processes, the same as back in the days of monolithic software deployments. I know from personal experience that with this tension, it can be difficult to scale an AppSec program to keep up with modern software development.

Security teams often face several challenges that prevent them from effectively performing their job. These challenges can include a lack of resources, a lack of support from management, or simply a lack of understanding of security concepts on the part of team members. Addressing these challenges is critical for security teams if they hope to secure their organization’s applications and data effectively.

How to Overcome the 5 Most Common AppSec Challenges

Challenge 1: Security teams lack visibility or control over risks introduced by developers.

Integrating security into the development process can be difficult. The lack of visibility into business needs and the constraints governing the software’s functionality, can leave security teams feeling shut out. Security teams can also feel left out of the evaluation process regarding potential risks.

However, organizations can more effectively meld security into the development cycle by codifying and automating security controls to create guardrails in CI/CD. Policies that are defined by security teams and applied within existing developer workflows. Through security guardrails, we can create a more secure software development process.

Challenge 2: AppSec tools produce unactionable noise.

Traditional AppSec tooling can often generate too much noise, including false positives and unactionable alerts. These irrelevant signals can make it challenging to identify what is applicable and actionable. As a result, teams waste valuable resources trying to manually parse through this information, decreasing the security team’s effectiveness.

Instead of immediately investigating every vulnerability found, AppSec teams should focus on identifying safe coding patterns and the types of bugs relevant to their organization. They can then convert these findings into security guardrails implemented in the developer workflows. This paradigm flips the process from responding to noisy alerts to determining what is relevant to your enterprise and only generating signals for relevant events. This technique provides continuous feedback to developers and enforces security requirements in a scalable manner.

Challenge 3: Security tools and processes generally operate outside developer workflows, making communicating quickly and effectively with developers challenging.

Developers are often overwhelmed by the number of AppSec tools and lack the time or bandwidth to learn how to use them well. This isolates the security team, requiring them to communicate actionable items manually filing tickets and following up with developers. This process is not scalable and wastes the resources of understaffed AppSec teams.

Teams should aim to consolidate data from AppSec tools into a single centralized data repository. Doing so will make it easier for teams to get a holistic view of their security posture and allows for better communication of security issues to developers. The centralized data repository can generate actionable data that is communicated directly to developers using familiar collaboration systems. This approach allows security to be a first-class citizen within development processes.

Challenge 4: Software ownership and code attribution can be difficult for engineering and security teams.

Most organizations have no straightforward process for code ownership, leading to wasted time and frustration when determining who should fix security bugs. AppSec teams would benefit from a defined code attribution process to save time and energy.

Adopted by many programmers, a Git-based code ownership management system can help developers declare code ownership and the metadata associated with code owners, such as tech leads and communication channels.

Challenge 5: Lack of accountability often leads to finger-pointing

One of the biggest challenges in security is getting different teams and departments to work together. Without interdepartmental cooperation, communication can devolve into a finger-pointing exercise where nobody takes responsibility.

As an industry, we must move AppSec toward a data-driven function where teams rigorously collect data and measure security performance. Every AppSec team needs to be able to collect relevant security data throughout the software delivery lifecycle. There must be mechanisms to facilitate reporting the right metrics at every level of the development organization. This approach will help drive ownership,security accountability, and compliance across the organization.

Just as development teams use software quality, performance, and reliability metrics to measure their progress, AppSec programs should enable development teams to measure and improve their AppSec. This can be done by using KPIs related explicitly to application security.

Developer-First is the Future of Application Security

A developer-first paradigm of AppSec is necessary to allow AppSec teams to focus on high-value tasks that move the business forward. As long as AppSec programs rely on security teams to act as gatekeepers, the business goals of speed and agility will cease to be effective, and there will continue to be friction between developers and AppSec.

In order to make security a part of the DevOps journey, organizations must shift-left and empower development teams to make approved security decisions. By integrating security processes into the Software Delivery Lifecycle (SDLC), organizations can create a more secure future for their applications.

Rate this article

Recent articles

How Do You Justify Investment In Product Security?

How do you justify investment in product security? On a recent episode of the Future of Application Security, FullStory’s VP of Product Security and Compliance, Mark Stanislav...

Read more
Should You Outsource Product Security Maturity Modeling to a Third Party?

Should you outsource product security maturity modeling to a third party? On a recent episode of the Future of Application Security, FullStory’s VP of Product Security and...

Read more

Ready to Scale Your Product Security Program?

Sign up for a personalized one-on-one walkthrough.

Request a demo

[email protected]

Request a demo