Who Shift Left Really Benefits: 4 Responsibilities DevSecOps Shifts Onto Developers

DevSecOps has transformed the software development landscape, embedding security practices at each stage of the development and delivery pipeline. While the DevSecOps approach has (rightfully) been lauded for helping teams produce safer software, it has come with its own set of problems. 

With this “shift left” has come a slew of new processes and tools that have become the responsibility of development teams to learn, follow and use. This raises the question: Do the benefits of “shift left” justify the extra workload placed on development teams? 

In this post, we will explore this concern, discussing how DevSecOps can unintentionally increase the workload for developers and how to help your developers integrate security as efficiently as possible, maintaining the balance between innovation and security.

1. Triage and Reproduction

In the DevSecOps paradigm, developers shoulder a dual responsibility. Not only are they the architects of code, but they also serve as its guardians, tasked with identifying and rectifying potential security vulnerabilities. This additional layer of responsibility, often encapsulated by the term 'triaging security results', can be a significant addition to their workload.

The process of triaging security results is much more than a cursory glance over the data. It involves delving deep into the sea of information that security tools generate. Developers must meticulously sift through this data, discern the false alarms from the genuine threats, and prioritize remediation actions based on the severity and potential impact of each identified vulnerability.

For instance, imagine a security tool flags a potential SQL Injection vulnerability in the code. The developer must then reproduce the issue to verify the result, which can be a complex and time-consuming task. They may need to set up a testing environment that mirrors the production one, input the same data that triggered the vulnerability, and monitor the system's response. If the vulnerability is confirmed, they then need to trace back through the codebase to identify where it was introduced, which could involve sifting through thousands of lines of code. They may even need to liaise with other team members who worked on that section of the codebase. 

And this is all for only one vulnerability. Recent analysis of about 1,000 companies found that it took 271 days on average to fix just one vulnerability and that only 13% of vulnerabilities observed were remediated.

To solve this challenge, organizations should prioritize integrating security tools that provide detailed and actionable insights to make the task of analyzing security results less daunting. Security tools should deliver as much information as possible to developers—including easy reproduction of scripts and test cases. The less time spent on triage, the more seamless shift left will become.

2. Overwhelming False Positives

Security tools integrated into the DevSecOps pipeline can sometimes erroneously flag safe operations as potential threats, leading to 'false positives'. Developers then need to spend valuable time differentiating between real threats and these false positives. 

According to a 2020 survey by GitLab, 39% of security professionals said they deal with at least 100 false positives a day. Fastly estimates that 45% of all application security results are false positives. This is a staggering amount of noise for developers to sort through. In addition to time lost filtering out false positives from real issues, the inaccurate and non-actionable results also erode developer trust—which over time leads to circumvention of security testing. 

False positives cannot be completely eliminated in most application security approaches. However, development teams can reduce their impact by customizing developers’ visibility of security testing alerts and making sure developers understand security results.

Often, security results are shared en masse with developers, who then struggle to separate the real issues from the noise. By focusing on how security tools alert developers and create remediation tickets, teams can ensure that developers are spending their time fixing real issues. Larger swaths of data can be reviewed by other teams for a broader risk assessment.

Developer-First Security Testing

Mayhem is application security built by professional hackers. Every result is real and actionable for immediate triage and rapid remediation.

Get Mayhem Free Request A Demo

3. Alignment on Priorities

Just bringing together the words “development” and “security" isn't enough. DevSecOps truly requires the integration of security and development, including an alignment on priorities between the two teams. This process can be time-consuming and full of friction, specifically around vulnerability remediation. Development and security teams have different business goals they’re working towards, and this can play a large role in how mitigation and remediation approaches are taken.

For instance, consider a scenario where the teams are working on an application with a microservices architecture. During the development process, an insecure direct object reference (IDOR) vulnerability is identified in one of the services. This vulnerability could potentially allow unauthorized access to user data.

From the security team's perspective, this vulnerability might be seen as critical. Given the potential risk to user data, they might argue for immediate remediation, even if it means halting other development work. They may see it as a matter of security integrity and user trust, which could be gravely compromised if the vulnerability were to be exploited.

On the other hand, the development team—while acknowledging the importance of the vulnerability—might be in the middle of developing a new feature set to significantly enhance user experience and engagement. 

From their perspective, putting a halt on this feature’s development to remediate the vulnerability could delay the release, potentially affecting the competitive edge and user satisfaction. They may instead push the security team to deploy a mitigation strategy that would alert, block or otherwise contain the breach. This would buy time for them to develop and deploy new features before properly remediating the breach.

Differing views like this between security and development teams can result in time-consuming discussions and negotiations. These misalignments place developers in a tug-of-war between planned feature work and security remediation, leading to delays and frustration on both sides. Developers and security teams need a better way to align on business risk than CVE criticality, so they can develop a shared understanding of prioritization and continue to move fast. 

4. Navigating the Sea of Security Tools

In the DevSecOps environment, developers are faced with a vast array of security tools that they need to master and use. From static application security testing (SAST) tools to dynamic application security testing (DAST) tools, from software composition analysis (SCA) tools to interactive application security testing (IAST) tools, the list goes on. Each tool has a unique role in identifying and mitigating potential security risks, making them an essential part of the development process.

However, this abundance of tools can also present a significant challenge. According to Gitlab’s 2023 Global DevSecOps Report Series, 66% of survey respondents said they want to consolidate their toolchains. The learning curve associated with these tools can be steep, as each tool has its specific features, interfaces, and usage nuances. The time and effort required to master these tools can significantly eat into the time developers could otherwise devote to core development tasks.

Moreover, the multitude of security tools can also lead to 'tool fatigue.' This is where developers, overwhelmed by the sheer number of tools they need to handle, may end up underutilizing them or, worse, making mistakes due to confusion or lack of understanding. This can potentially result in overlooked vulnerabilities, creating a security risk. 

Similar to dealing with false positives, teams should consider carefully how exposed their developers are to security tools. The best security processes and tools are the ones that are used consistently. In an ideal world, developers might have little visibility into the actual tools used. Instead, security results could be seamlessly integrated into ticketing or build systems. By reducing developer exposure to multiple tools, some of the tool fatigue developers face from DevSecOps can be resolved. 

Conclusion

Incorporating security into the DevOps process undoubtedly strengthens software safety, but it also presents challenges for developers. Navigating security results, handling false positives, aligning on remediation priorities, and having to learn too many security tools and processes may lead to developers that are overburdened with security tasks.

Providing comprehensive training, refining developers’ use of security tools, and promoting effective inter-team communication can help organizations ensure that developers have the time to innovate and produce high-quality software—while still maintaining robust security. It's not just about creating secure software: it's about making the process as efficient and pain-free as possible for development teams.

Got a Sec for your DevOps?

Integrating Security into your DevOps Process is hard when you don’t have the time. If you don’t have a Sec to put into your DevOps, we’ve got you. Mayhem is a developer-first security testing solution built by professional hackers to save development teams time.  

Mayhem automatically generates thousands of tests to identify defects in your apps and APIs. Self-learning algorithms continually expand test coverage, and automated triage and reproduction ensures every result is actionable—resulting in more risks identified, more defects fixed, and more secure features shipped on time. Get started for free.