This article is based on data from the 451 Research report “DevSecOps Realities and Opportunities,” commissioned by Synopsys Inc. The original report analysed survey responses from 350 enterprise decision-makers across large organisations in multiple industries. The source article was published on bwcio.businessworld.in in April 2018.
The DevSecOps Gap: Awareness Without Action
Synopsys Inc. released research data highlighting a troubling disconnect in how enterprises approach application security within their DevOps pipelines. Despite widespread acknowledgement of the benefits, security integration into continuous integration and continuous delivery (CI/CD) workflows remains inconsistent and incomplete across the industry.
The 451 Research report found that only half of CI/CD workflows include application security testing elements, even though survey respondents demonstrated clear awareness of why security testing matters. In other words, the bottleneck is not knowledge — it is execution.
Why DevOps Teams Are Moving Fast — and Taking on More Risk
Modern DevOps teams operate at a scale and pace that amplifies the consequences of any security gap. According to the survey, 63 percent of respondents expected to deploy software at least four times faster in a DevOps model compared to traditional delivery approaches. Each release often involves significant code changes, and the underlying infrastructure is increasingly large and complex.
This acceleration is exactly what DevOps promises to deliver — but without a deliberate and automated security strategy embedded into the pipeline, speed becomes a liability. Vulnerabilities that would previously have been caught in a slower, more manual review cycle can ship directly to production.
Key Challenges Organisations Cite for DevSecOps Adoption
The survey identified several recurring obstacles that prevent security from being effectively integrated into CI/CD workflows:
- Lack of automation and consistency: Security checks that rely on manual processes do not scale to the velocity of modern pipelines. Without automation, testing becomes a bottleneck rather than a safeguard.
- Reduced pipeline speed: Teams often perceive security tooling as slowing down builds and deployments, creating organisational pressure to skip or defer testing.
- False positive noise: Security scanners that produce a high volume of inaccurate alerts cause alert fatigue, erode trust in tooling, and lead developers to ignore findings — including genuine vulnerabilities.
Jay Lyman, principal analyst at 451 Research, summarised the situation clearly:
“While some DevOps teams are starting to incorporate application security into their CI/CD workflows, driven by factors such as improved software quality, compliance, and risk avoidance, there is ample room for improvement. In many cases, security testing is not being integrated often or early enough in the process for organisations to fully benefit from reduced risk and rework headaches.”
Jay Lyman, Principal Analyst, 451 Research
The Case for Shifting Security Left
Despite the challenges, the survey data reinforced a well-established principle in software engineering: integrating automated security tools early in the software development life cycle (SDLC) has a measurable positive impact on both the speed of delivery and the overall quality and security of the finished software.
“Shifting left” — the practice of moving security testing earlier in the development process rather than deferring it to a pre-release gate — reduces the cost and complexity of remediating vulnerabilities. A defect caught during development is far cheaper and faster to fix than one discovered after deployment. This is not a new argument, but the survey data suggests many organisations still struggle to act on it in practice.
Software Composition Analysis: The Most Critical Gap
One finding stands out as particularly urgent: Software Composition Analysis (SCA) was identified as the most critical application security capability that needs to be incorporated into CI/CD pipelines.
SCA is the process of identifying open source and third-party components within an application and checking them against databases of known vulnerabilities. Given that modern applications are built heavily on open source libraries and frameworks, SCA is not optional — it is foundational.
Yet the survey revealed a significant blind spot: nearly 40 percent of organisations either do not perform SCA at all or claim not to use any open source components. The second claim is almost certainly inaccurate at scale. A separate Open Source Security and Risk Analysis report by Black Duck Software found that over 95 percent of applications contain open source code. The gap between self-reported open source usage and actual usage suggests that many organisations simply do not have visibility into their own software supply chains.
What DevOps Teams Should Prioritise
Based on the findings, teams looking to strengthen their DevSecOps posture should consider the following practical steps:
- Audit your open source inventory. Before you can secure your dependencies, you need to know what they are. Integrate an SCA tool into your pipeline to automatically detect open source components and flag known CVEs on every build.
- Automate security testing at every pipeline stage. Static application security testing (SAST), dynamic testing (DAST), and SCA should all be automated triggers in your CI/CD pipeline, not manual gates performed on release day.
- Tune your tools to reduce false positives. A scanner that developers do not trust is worse than no scanner, because it trains teams to ignore alerts. Invest time in baseline configuration and suppression rules to surface only actionable findings.
- Define security requirements before writing code. Security requirements should be part of the story or ticket definition, not an afterthought during code review. This is the most literal form of shifting left.
- Measure and report on security debt. Track the number of open vulnerabilities, mean time to remediate, and the stage at which defects are found. Visibility drives accountability and helps build the business case for further investment.
The Opportunity Is Real
The Synopsys and 451 Research data paints a picture of an industry at an inflection point. The awareness of DevSecOps benefits — better software quality, reduced compliance risk, fewer late-stage rework cycles — is already present in the enterprise. What lags is implementation.
Teams that bridge this gap by automating security testing early and consistently in their pipelines will not only reduce their exposure to breaches and compliance failures — they will also deliver software faster, because fixing vulnerabilities at build time is dramatically cheaper than triaging incidents after release.
The technology to do this exists today. The main barrier is organisational: prioritisation, tooling investment, and the cultural shift required to make security every developer’s responsibility, not just a security team’s periodic concern.