Why Isn’t Secure DevOps Being Practiced? Barriers, Risks, and the Path Forward

This article draws on findings from two industry reports: the May 2018 “Examining DevSecOps Realities and Opportunities” report by Synopsys and 451 Research (based on a survey of 350 enterprise leaders), and the Ponemon Institute’s “Bridging the Digital Transformation Divide” study, sponsored by IBM. Statistics cited below reflect those reports as summarized by SecurityIntelligence.com.

The Awareness-Adoption Gap in Secure DevOps

DevSecOps — the practice of embedding security testing and controls directly into DevOps workflows — is well understood at the leadership level. CIOs and engineering directors broadly recognise that finding vulnerabilities early reduces remediation costs, improves software quality, and lowers compliance risk. Yet understanding a practice and consistently executing it are very different things.

According to the Synopsys/451 Research report, only around half of DevOps teams at large enterprises integrate application security testing into their CI/CD pipelines. The gap between awareness and action is the central problem facing the industry — and understanding why it exists is the first step toward closing it.

Where Security Testing Currently Fits in CI/CD

The report found roughly 50 percent of surveyed organizations integrate some form of application security testing into their DevOps process. Adoption varied by industry, but only a 12-percentage-point margin separated the highest and lowest adopting sectors:

• High-tech: approximately 56% integration of security testing in CI/CD workflows
• Retail: approximately 44% integration — ranked last among industries surveyed

The most commonly used security practices among organizations that do practice secure DevOps include:

• Static application security testing (SAST) / software composition analysis (SCA)
• Dynamic application security testing (DAST)
• Third-party penetration testing

These tools are mature and widely available. The fact that adoption is still below 50% in most sectors points to barriers that go well beyond tooling availability.

Why Secure DevOps Is Failing to Translate into Practice

Survey respondents identified several barriers to integrating security into CI/CD pipelines. The challenges span technology, process, and people:

• Lack of automated, integrated security testing tools — many security tools still require manual intervention or operate outside the pipeline, creating friction
• Inconsistent approaches — different teams within the same organisation apply security testing unevenly
• Perceived slowdown — security testing is seen as slowing release velocity, even when that perception may not reflect reality
• High false-positive rates — noisy scan results erode developer trust in tooling and lead to alert fatigue
• Developer resistance — security is still often seen as someone else’s responsibility

Three of the top five barriers — inconsistency, resistance, and the belief that security slows things down — are rooted in culture and education rather than in a genuine technical impossibility. This matters because it means better tooling alone will not solve the problem.

Is Technology the Root Cause?

Technology and human factors are tightly coupled in DevOps environments. Poor tooling directly shapes developer attitudes: if a security scanner generates hundreds of false positives, slows build times significantly, or requires a separate login and workflow, developers will route around it.

The Synopsys/451 Research report makes the point plainly: not all security tools are equal, and the less a tool can be integrated and automated into existing workflows, the less effective it will be. A security gate that breaks the developer experience will be disabled, bypassed, or ignored.

The practical implication is that security tools must be selected and configured with developer experience as a first-class concern. Tools that:

• integrate natively with existing CI/CD platforms (Jenkins, GitLab CI, GitHub Actions, etc.)
• return actionable, low-noise results
• scan incrementally rather than blocking the entire pipeline on every commit
• surface findings inside the IDE or pull request, not in a separate portal

…are far more likely to achieve consistent adoption than point-in-time or externally managed alternatives.

Balancing Risk and Reward: The Business Case

Secure DevOps is not purely a compliance exercise. The Ponemon Institute’s “Bridging the Digital Transformation Divide” study found that organisations failing to address security as part of digital transformation face direct business consequences. The study reported that 74 percent of IT security practitioners said it was likely their organisation had experienced a cybersecurity incident in the previous 12 months as a direct result of insufficient security in digital transformation processes.

The costs of not practicing secure DevOps compound over time and include:

• Expensive application rework — vulnerabilities found in production cost significantly more to fix than those caught during development
• Slower releases — unplanned security remediation disrupts release schedules more than planned security gates do
• Regulatory noncompliance — many frameworks (PCI DSS, HIPAA, SOC 2, GDPR) increasingly require security-by-design practices
• Data breaches and reputational damage — the downstream loss of customer trust is difficult to quantify and slow to recover

How Mature Organizations Approach Secure Digital Transformation

The Ponemon study identified characteristics that distinguished high-performing, security-mature organisations from their peers. Leadership attitude was a defining factor: in the most mature organisations, senior management actively shaped the security posture rather than delegating it entirely to the security team.

IT security practitioners in high-maturity organisations were significantly more likely to report leadership agreement with the following positions:

• Investing in emerging security technologies — including automation, AI, and machine learning — is essential, not optional
• Digital transformation inherently creates new security risks, which must be actively managed
• Adequate, sustained funding for IT security is a prerequisite for successful transformation
• The security of digital assets is directly tied to customer trust and brand value

These organisations also demonstrated full alignment between IT security teams and business units — meaning security requirements were built into product and project planning, not bolted on at the end.

Secure DevOps Is an Organisational Problem, Not Just a Technical One

The evidence from both studies points to a consistent conclusion: the gap between DevSecOps awareness and DevSecOps practice cannot be closed by deploying better tools alone. Technology is a necessary enabler, but the following organisational conditions must also be present:

• Executive sponsorship — leaders must visibly champion secure practices and fund them adequately
• Shared ownership — security cannot remain the sole responsibility of a separate security team; developers must be empowered and trained to act as the first line of defence
• Defined strategy — organisations need a documented secure transformation roadmap, not ad-hoc responses to compliance audits
• Metrics and feedback loops — teams should measure security outcomes (mean time to remediate, vulnerability escape rate, etc.) the same way they measure delivery velocity

Practical Steps to Start Closing the Gap

For engineering and security leaders looking to move from awareness to consistent practice, a phased approach tends to reduce resistance and build momentum:

1. Audit your current pipeline. Map where security testing currently occurs (if at all) and where the highest-risk gaps exist — typically at the build, dependency, and deployment stages.
2. Start with low-friction wins. Introduce SCA (software composition analysis) to flag known vulnerable dependencies. This is usually fast, low-noise, and immediately demonstrable in value.
3. Integrate incrementally. Add SAST and secrets-scanning at the pull-request stage before expanding to full DAST coverage in staging environments.
4. Tune to reduce noise. Work with security teams to suppress or triage false positives systematically rather than leaving developers to manage noisy output.
5. Train and incentivise developers. Provide secure coding training and include security metrics in team performance reviews.
6. Report to leadership. Make security metrics visible at the CIO and CISO level alongside deployment frequency and defect rates.

Conclusion

The secure DevOps gap is real, persistent, and costly — but it is not inevitable. The organisations that successfully close it share a common pattern: they treat security as a shared engineering discipline, invest in tooling that fits developer workflows, and ensure that leadership actively supports and funds the effort. Better technology helps, but without cultural and organisational alignment, even the best security tools will be underused. Bridging the gap requires action at every level, from the IDE to the boardroom.