Navigating the Shift: Challenges in Shifting from DevOps to DevSecOps and How to Overcome These
Explore the challenges faced by teams while transitioning from DevOps to DevSecOps and the strategies to overcome these
The transition from DevOps to DevSecOps is a journey that is both rewarding and challenging. While DevOps emphasises collaboration and efficiency in software delivery, DevSecOps seeks to embed security into every phase of the software delivery process.
By adopting DevSecOps practices, organisations not only deliver secure software faster, giving them a competitive edge, but can also demonstrate continuous compliance with internal policies and external regulatory requirements.
However, the journey may not be as straightforward. While the benefits of DevSecOps are clear, organisations often encounter significant barriers that hinder this evolution, making the process challenging. This shift goes beyond changes in processes and technology and requires a fundamental shift in mindset and organisational culture too.
In one of my earlier articles, I discussed the importance of this cultural shift and highlighted how embracing a security-first mindset is crucial for successfully embedding security into every aspect of the software development process.
In this article, I will explore some of the key technical, process, and cultural barriers that DevOps teams typically face during this transition and share strategies on how organisations can address these challenges.
Major Challenges to DevSecOps Adoption
Challenges that the DevOps teams face while integrating DevSecOps practices in their workflows:
#1. Cultural Resistance — Speed vs Security
Resistance to change is one of the most significant barriers to adopting DevSecOps. Teams accustomed to the speed and agility of DevOps often perceive security as an additional burden. They may fear that incorporating security practices will slow down the delivery cadence and add new layers of complexity. This is especially true for fast-paced DevOps teams who are accustomed to releasing updates multiple times a day.
This resistance is further exacerbated by a fear of accountability, as integrating security increases scrutiny and may expose vulnerabilities. Such a mindset may result in rushed releases with minimal security validation, leaving software vulnerable to attacks in production environments.
Siloed mentalities also pose a significant challenge. Security has traditionally been the domain of a separate team, leading to a “not my responsibility” mindset among developers and operations teams. Additionally, security is often perceived as a bottleneck, and making its integration into the development process feels more like an intrusion than a shared responsibility. Teams working under aggressive timelines may prioritise speed over security, creating a conflict between short-term goals and long-term resilience.
While cultural barriers are significant, they are often compounded by technical challenges, such as integrating security tools effectively into existing workflows.
#2. Tools Overload and Integration Complexity
With DevSecOps, multiple tools are introduced to automate security tasks, such as SAST, DAST, secrets scanning, container security, and vulnerability scanning etc. While these tools enhance security capabilities, they can also overwhelm teams, particularly when they do not integrate seamlessly with existing CI/CD workflows.
Poor integration may lead to siloed data from multiple scanning tools, requiring manual intervention to consolidate results. This creates inefficiencies, slows down delivery timelines, and complicates the detection of critical vulnerabilities across different stages of the development process. Furthermore, disconnected tools contribute to friction within workflows, making it harder for teams to maintain a consistent security posture.
The use of multiple tools can also result in duplicate reports of the same vulnerability, often with differing severity ratings and varying contextual information. This inconsistency adds to the confusion among development teams, making it harder to prioritise and address security issues effectively.
Use tools that embed security checks into the developer workflow without disrupting their daily workflows (e.g. SAST tools integrated into CI/CD pipelines). Consider consolidating findings from multiple tools and build a centralised dashboard for security alerts to reduce tool and vulnerability overload.
These operational hurdles are compounded due to lack of security expertise within development teams. Without the necessary skills, developers may struggle to interpret security findings and implement appropriate remediation, further delaying the resolution of vulnerabilities.
#3. Lack of Security Expertise in Development Teams
DevSecOps requires developers to take on additional security responsibilities that they may not be familiar with, such as performing vulnerability scans, interpreting results, and implementing appropriate fixes. This shift often leads to a knowledge gap, as many developers are experts in writing code but lack experience with security best practices.
When vulnerability descriptions are unclear, developers may mark these security issues as low-priority technical debt, accept the associated risks, or may even mark these as false positives. These actions can create a false sense of security, leaving vulnerabilities unaddressed and exposing the software to potential exploitation in production environments.
To bridge the expertise gap, organisations can invest in targeted security training programs and consider embedding security champions within development teams.
Conduct regular security training sessions on topics like OWASP Top 10 and secure coding practices. Developers should be trained to understand security vulnerabilities identified by automated tools and how to remediate them. Peer security reviews and security hackathons can also be helpful in increasing awareness and ownership of security issues.
Security champions can act as liaisons, ensuring developers receive timely support and guidance on complex security issues. These measures can enhance developers’ understanding of security practices, enable them to handle vulnerabilities effectively, and foster a culture of shared responsibility for security.
#4. False Positives and Alert Fatigue
Security tools, particularly during early adoption phases, could produce a high volume of false positives, leading to alert fatigue. Developers may become desensitised to security alerts, potentially ignoring critical vulnerabilities that can get lost in the noise. This increases the likelihood that a real security vulnerability goes undetected and makes it into production, increasing security risks.
To mitigate these early adoption challenges, closely monitor the early iterations of tool integration within the pipeline to assess the rate of false positives. Fine-tuning security tools to reduce false positives is essential to ensure that security issues are accurately classified and prioritised for remediation.
Setting up custom rule sets and fine-tuning security tools to your organisation or system specific context, allowing the tools to flag only critical or high severity vulnerabilities will help prevent alert fatigue in the beginning. Tailored rule sets not only reduce alert fatigue but also improve developer productivity by allowing them to focus on high-priority issues. Once improvements have been made, the vulnerability identification scope can be expanded gradually to include medium and low severity issues.
Additionally, implement an automated risk-based prioritisation system to ensure that the most critical issues are addressed first. Create feedback loops between developers and security teams to help improve the accuracy of these tools over time.
By addressing alert fatigue early, organisations can foster greater trust in security tools and promote a collaborative security-first culture.
#5. Balance between Automation and Human Oversight
While automation is a key tenet of DevSecOps, not everything can, or should, be automated. False positives highlight the importance of striking a balance between automation and human oversight to ensure critical vulnerabilities are not overlooked. Complex threats and critical security decisions still require human oversight to provide the necessary context and judgment and therefore may pose challenges and may potentially cause delays that would need to be managed.
It is generally debated that the security gates should be replaced with appropriate guardrails within CI/CD pipelines. While this approach is generally effective, manual intervention is still necessary in certain scenarios, acting as a dual control mechanism. For instance, manual peer reviews during code commits and manual approvals before deploying to production ensure that critical vulnerabilities are thoroughly examined at appropriate stages in the CI/CD pipeline. Beyond these steps, automation should handle the majority of tasks, with appropriate guardrails applied at each stage of the software delivery process.
Some of the edge cases may include automating security checks in the pipeline but certain vulnerabilities, such as logic flaws, may still require manual reviews and contextual decisions that automation couldn’t handle effectively. Over-reliance on automation can lead to missed vulnerabilities or misclassifications that require deeper analysis.
Implement automated tools for tasks like code scanning, dependency analysis, and configuration checks, but schedule periodic manual code reviews, especially for high-risk areas like authentication and authorisation logic. Security engineers or champions couldbe involved in reviewing critical vulnerabilities flagged by automated tools to provide deeper analysis where necessary.
#6. Legacy Systems and Technical Debt
Many organisations operate with a mix of legacy systems and modern applications. Integrating security into legacy systems can be particularly challenging, as these systems were not designed with security or automation in mind. This results in compatibility issues with modern security tools, creating bottlenecks or necessitating additional workarounds to incorporate security measures effectively.
Generally, the security vulnerabilities in legacy systems are harder to address, and patching them often requires significant manual effort, which can slow down the DevSecOps transformation.
Consider how to reduce the technical debt for these systems over time. A potential solution might be to develop a strategy for gradually securing legacy systems while prioritising modernisation, however, this is easier said than done. Potential approaches may include segmenting legacy systems to isolate them from modern, secure environments or refactoring critical components to align with current security practices.
These technical challenges are further compounded by leadership misalignment, which can derail DevSecOps transformation efforts in the organisation.
#7. Leadership Misalignment
Leadership misalignment is another critical factor that can hinder the adoption of DevSecOps practices. Without strong leadership support and clear alignment on security goals, the necessary investments in modernisation and security integration may fail to gain traction.
Mixed messages from leadership about whether speed or security should take priority can cause confusion, undermining efforts to align teams and foster a unified approach.
Consistent, top-down advocacy is essential to ensure that security is prioritised alongside delivery speed, enabling teams to collaborate effectively and embrace DevSecOps principles.
Strategics to Overcome Challenges
Leadership Support
Leadership must champion the shift and set clear priorities.
Leadership plays a critical role in driving the cultural and operational shift required for DevSecOps. Leaders must actively champion the initiative, setting clear priorities that emphasise security as a core value. By aligning strategic goals with DevSecOps principles and fostering an environment where security is prioritised alongside speed and innovation, leadership can inspire teams to adopt and sustain these practices.
Cross-functional Collaboration
Break down silos with shared goals, open communication, and mutual accountability.
Breaking down silos between development, operations, and security teams is essential for success. Organisations must establish shared goals, facilitate open communication, develop communities of practice, and create mutual accountability across all teams. Regular cross-team collaboration fosters trust, ensures alignment, and integrates security seamlessly into existing workflows, making it a shared responsibility.
Building a culture where security is everyone’s responsibility is critical. The shift to DevSecOps must emphasise that security isn’t an afterthought or a blocker but a necessary component for building resilient software.
Security as an Enabler
Frame security as a tool for empowerment rather than restriction.
Reframing security as a tool for empowerment rather than a restriction is key to overcoming resistance. When teams understand that security strengthens their work — protecting users, the organisation, and the software they develop — it becomes easier to integrate into workflows. Positioning security as a contributor to quality and innovation helps dispel the perception of it as a bottleneck.
Training and Upskilling
Equip teams with knowledge and tools to integrate security seamlessly.
Equipping teams with the right knowledge and tools is vital for successful DevSecOps implementation. Regular training sessions on secure coding practices, threat modeling, and using security tools within the CI/CD pipeline empower teams to take ownership of security. Upskilling ensures that all team members, regardless of role, understand and can apply security principles in their day-to-day activities.
Investing in developer security training will help ensure developers understand the security tools they are using and can interpret the security findings to take appropriate actions for timely resolution. Appoint security champions within the development team to bridge the gap between security and development and integrate security early in the SDLC (“shift left”).
Shift-left Mindset
Promote early and continuous security integration to embed it naturally into workflows.
Promoting a shift-left mindset embeds security early and continuously in the development lifecycle. By addressing vulnerabilities at the earliest stages — design, coding, and testing — organisations can minimise risks and reduce the cost of remediation. This proactive approach ensures security becomes a natural part of workflows, rather than an afterthought.
Careful tool selection and integration planning are crucial. Avoid adopting tools without a clear plan for how they will work together and fit into the existing DevOps process.
Celebrate Wins
Highlight the value of security to foster positive behaviour across teams.
Recognising and celebrating achievements, no matter how small, can foster enthusiasm and reinforce positive behaviors. Highlighting the value of security in delivering trusted, resilient products motivates teams and builds momentum for further improvements. Celebrations also provide an opportunity to reflect on lessons learned and promote a culture of continuous growth.
Final Thouguhts
Transitioning from DevOps to DevSecOps isn’t just a technical shift, but a cultural and organisational one. The challenges teams face are real and significant — from cultural resistance, to tool overload, to security expertise gaps.
By addressing these challenges through leadership support, collaboration, and strategic integration of security practices, organisations can embed security into their development workflows without compromising speed or agility.
What steps is your organisation taking to navigate the shift to DevSecOps? I would like to hear from you in comments!