7 Surprising Roadblocks on the Path to DevSecOps Maturity

As part of our recent formulation and launch of the DevSecOps Maturity Framework, Snyk conducted extensive industry research on the current state of Developer Security within the software-focused enterprise. Over 300 organizations provided data to help us understand how they self-assess their own maturity in DevOps, application security, vulnerability management, prioritization, developer adoption, and program governance.

Overall, our findings show that most enterprises understand the value of mature DevSecOps practices and are actively working to build a modern security culture and AppSec program geared toward continuous improvement. However, not everyone is approaching this in the same way. In fact, within the broad theme of increasing maturity, we saw quite a bit of diversity in how organizations described key parts of their security practice, signaling significant gaps that still remain in working toward a common goal of DevSecOps maturity. Let’s look at some of these findings that highlight potential areas of improvement.

Risk Reduction and Security Fatigue are the KPIs least likely to be measured by security teams, but they are among the top five indicators that teams want to measure.

Across all the security metrics being tracked by the teams we researched, the two least likely to be measured were “Risk reduction due to developers’ actions” and “Reduction in security fatigue (time spent on manual triage, broken builds, security rework).” Yet, these two KPIs were also near the top of the list when we asked the same respondents what metrics they would ideally want to report on if all the relevant data were available. 

Clearly, there is still a major disconnect between the kinds of data that security tools can easily report—like counts of vulnerabilities found and fixed, CVSS scores, time-to-fix, etc.—and the questions security professionals want to ask, like, “How much risk is being reduced through a particular kind of action?”, that determine their program’s effectiveness and ROI. This highlights the importance of aggregating and correlating vulnerability data from multiple sources to break down silos and understand risk holistically based on a full understanding of application, business, and vulnerability context. Application Security Posture Management (ASPM) tools, such as Snyk AppRisk, can help by serving as the internal hub and single source of truth for risk-based security insights. 

Meanwhile, of all the personas included in the study, software developers were most likely to express interest in measuring security fatigue, otherwise known as toil. This broad category attempts to measure the cost of shifting left in terms of lost developer productivity, which must be spent on security tasks that are not easily automated. Because most vulnerability scanning tools are designed for a security audience, they often overlook how these tools impact developers, making it impossible to understand how much inefficiency exists in the detection and remediation processes embedded in the SDLC. This inability to measure security toil is partially responsible for the high levels of friction between developer and security teams, which we continue to observe even in organizations with high levels of DevSecOps maturity.

The ability to accurately measure security posture based on risk is the #1 DevSecOps goal for both security and engineering teams.

It is a persistent myth in application security that developers do not care about software risk. We see the reality again in that developers’ top DevSecOps priority was accurately understanding risk-based security posture–the same as their peers in AppSec (Platform Engineering groups reported it as their #2 goal). In other words, developers want to do their part in reducing risk for the organization but feel they lack the data needed to make better prioritization decisions.

This discrepancy is rooted in the complexity of computing application risk, which requires additional context (business impact, reachability, exploit maturity, and presence of compensating controls, etc.) beyond a simple count of issues and their associated severities. Modern software is very complex, and remediation budgets are always limited. Therefore, fix time must be allocated not simply based on the highest-severity vulnerabilities (which may or may not be truly exploitable, and even if so, may or may not lead to significant business impact if exploited) but on a customized, risk-based scoring system based on multiple sources of context across the SDLC.

This inability to align on a risk-based prioritization scheme is a major driver of friction between engineers and security teams and can lead to the failure of DevSecOps initiatives due to the persistent lack of trust. Developers often feel forced to spend fix time on the “wrong” (i.e., actually lower-risk) issues. Security professionals often feel too many true risks are escaping into production environments because there is no shared and trusted risk-scoring mechanism accessible within both personas’ workflows. So it’s clear why accurate risk measurement is their shared top priority, but most security tooling is still evolving to support this need.

Only 50% of organizations report investing in Just-In-Time security training for developers and building Security Champions programs within development teams.

Security education, especially for software developers, is a critical component of mature DevSecOps practice. To be effective, it must be relevant, actionable, ongoing, and tightly integrated within teams’ processes and ways of working. Most traditional security training, however, fails to meet these goals, leading to a consistent gap in developers’ understanding of application security risks and associated secure coding practices.

This gap is rooted in engineers’ preferred way of learning, which is based on real-world problem-solving. The vast complexity of modern software development techniques means teaching everything an engineer needs to know using traditional, top-down methods is difficult. Instead, developers learn by doing; they encounter a problem and must find a solution before moving on. This type of “just-in-time” learning is demonstrably stickier. Yet most security training programs take the opposite, ineffective approach. Investing in just-in-time security education, by which a developer can take a micro-lesson lesson to understand the risks of a specific vulnerability and learn how to fix it (like addressing an issue found in their own code), such as Snyk Learn, has been shown to improve security outcomes. However, it is still only used by about half of the organizations we studied.

Relatedly, research has consistently shown the effectiveness of Security Champions programs, which seek to inject security knowledge directly into software engineering teams. This is done by equipping one developer on each team with in-depth, targeted training and resources to act as the liaison between their developer peers and the AppSec organization. Because engineers prefer to learn from other engineers, and peers can more effectively translate security requirements into their team’s ways of working, security champions have been shown to reduce friction with AppSec and improve outcomes. The half of organizations that have not yet implemented a Champions program may continue to face headwinds in their developer security initiatives without this critical cultural building block.

Less than half (46%) of organizations report they can accurately identify their mission-critical applications.

Risk is often broadly computed as likelihood multiplied by impact. While vulnerability scanning tools can more or less accurately measure the likelihood of an exploit (especially if they include additional context, such as reachability and exploit maturity), impact, by definition, can only be assessed by the business. A security scanner cannot distinguish between a high-severity issue in a mission-critical application and the same vulnerability in an unused service supporting an outdated promotional website. Yet, the risks associated with these two issues could not be more different.

Mature DevSecOps requires that organizations understand the business impact of their software assets and integrate these assessments into risk scoring for issue prioritization. Tools like configuration management databases (CMDBs) are often used to maintain an up-to-date inventory of code repositories, container images, deployments, and other artifacts. They can also be the source of truth for business criticality scoring, which can then be ingested by security orchestration platforms, especially ASPM solutions like Snyk AppRisk, for integration with risk-based prioritization algorithms.

The majority of surveyed organizations struggling to identify their mission-critical software have a dual problem: they are potentially allowing too much risk to escape into production for these crown-jewel applications, which would incur substantial business impact if exploited. They also suffer from inefficient remediation processes overall since they cannot easily de-prioritize fixes for applications with very low impact scores. Mature DevSecOps requires tooling and processes that make business impact a first-class citizen in any calculation of risk.

Only 31% of organizations automatically enforce security requirements in multiple stages of the SDLC before production.

Our research found that most organizations have fully documented software risk profiles that are automatically enforceable. However, for the largest cohort (40%), this enforcement happens only in the production/runtime environment. A comparatively smaller number of organizations take the initiative to enforce policy at multiple points in the SDLC in pre-production enclaves. Critically, this means that even within mature DevSecOps cultures, most benefits of fast and early remediation of security issues are being missed.

It has long been a security truism that the cost of fixing issues rises as software moves from left to right. If only a subset of security policies are implemented in pre-production (i.e., in CI/CD pipelines, PR checks, or staging environments), then most issues will incur the most expensive possible remediation process.

There is a trade-off between cost-to-fix and accuracy of detection. Catching issues earlier in the SDLC makes fixing them faster and more efficient because the feedback loops back to developer workflows are shorter. However, as software gets closer to production–when it is compiled, packaged, and deployed to increasingly prod-like environments for testing–it becomes easier to understand risk, and security scans become more accurate. There’s no “right” place to implement security testing in a DevSecOps-oriented SDLC. Instead, the balance between accuracy and efficiency is best achieved through multiple lightweight security checkpoints, which apply policies at each stage based on the changes made to the software. Organizations that only enforce security at a single stage are forced to sacrifice either accuracy or fix efficiency, ultimately limiting their movement toward DevSecOps maturity. 

Only 25% say security alerts are sent only to relevant stakeholders and include all the necessary context to take action.

Alert fatigue is a major cause of security friction. Too many alerts or notifications–especially ones that don’t feel relevant or require extra effort to interpret–are easily ignored. Over time, this can ultimately lead to a lack of trust in the noisy security tool, even if future alerts become more targeted. This is why avoiding alert fatigue is critical in maturing DevSecOps practice.

Three-quarters of organizations suffer from notifications that cannot be properly actioned. Often, they lack the necessary context, aren’t sent to the right people, or don’t include clear and trusted steps for resolving the issue. This alerting chaos can be a side effect of multiple stovepiped security tools competing for attention from the same stakeholders, reducing bandwidth for notifications that meet the threshold for actionability.

Response and Remediation is one of the six pillars of Snyk’s DevSecOps Maturity Framework. However, any repeatable response strategy must first begin with an alert stream that can reliably and quickly initiate decisive action from the appropriate personas. Organizations unable to solve the alert fatigue problem will quickly discover a limit to their ability to implement trustable remediation loops, which improve over time.

Only 37% describe their DevSecOps program as “transparent and self-service from an engineer's perspective, making it easy to be secure and hard to introduce software risk.” 

Perhaps the biggest disconnect on the road to DevSecOps maturity is understanding the developer's experience. Initially, the promise of DevOps (before the “Sec”) was aimed at making developers' lives easier by giving them the tools to handle tasks that required help from centralized IT teams. Things like packaging software, deploying applications, or setting up infrastructure could all be managed by developers themselves, simply by writing code. This shift towards self-service through automated, repeatable processes became a cornerstone of modern software development and led to major improvements in time-to-market.

However, when it comes to security, the progress hasn’t quite kept up. The idea of “DevSecOps” has been around for over a decade but often relies on legacy AppSec tools and processes that don’t align with modern software developer practices. This mismatch creates a less-than-ideal developer experience. While engineers can easily manage their own containers, automated tests, and cloud services, they often have to wait for security scans to run out-of-band, leading to more expensive remediation and constant tension with AppSec teams.

This lack of transparency and self-service makes it harder for developers to manage software risks effectively. Instead of preventing issues upfront, they’re often left to guess the secure choice and remediate later when fixing is most expensive. In other words, it is easy to introduce risk and hard to be secure. True DevSecOps must break this cycle by moving to “secure by design” principles that provide paved roads for developers, allowing them to self-service risk management and trust that the default choice is also the secure choice.

DevSecOps has evolved greatly since its introduction. While our research shows most organizations are firmly on the path toward maturity, there are still significant gains to be made in unlocking the promise of trusted, automated, developer-focused security practice.

Interested in progressing your DevSecOps program? Download the ebook today.