Security as an Afterthought Is Losing Ground

For much of the software industry’s history, security reviews happened at the tail end of the development process — or not at all until a vulnerability surfaced in production. Developers would finish building an application, hand it off to a security team, and move straight on to the next project. By the time security concerns were flagged, the original developers were mentally and logistically disengaged, making remediation slower and more expensive.

That pattern appears to be changing. According to the 2017 DevSecOps Community Survey released by Sonatype, organisations have steadily shifted security analysis to earlier stages of the software development lifecycle (SDLC) since at least 2014.

Survey Methodology

The survey was the fourth in a series Sonatype has conducted since 2011 on application development and security practices. The 2017 edition collected online responses from 2,292 IT professionals worldwide, of whom 1,759 completed the survey in its entirety. The questionnaire covered 37 questions about security and development practices and was conducted between 1 February and 28 February 2017.

Key Data: Security Analysis Is Moving Left

Comparing 2014 responses with 2017 responses, the survey tracked at which SDLC stage security analysis was performed. The growth across every phase is striking:

The data shows not just an increase in security coverage at individual stages but a broader adoption of continuous security practices — with the proportion of teams applying security analysis throughout the lifecycle nearly doubling from 15% to 27%.

For organisations with mature DevOps practices, the figures were even higher across every category. According to Derek Weeks, Vice President and DevOps Advocate at Sonatype, automated security practices in those mature organisations increased two- to three-fold over the same period.

Why Earlier Security Integration Matters

The business case for shifting security left — addressing it earlier in the development process — is well established in principle, and the Sonatype data provides empirical backing. Weeks explained the logic to ITPro:

“If you empower the developers with that information early in the software development lifecycle, they can fix it immediately. What development teams have really figured out is that if they can talk about secure coding practices as they are building applications, someone can say that logging framework has a vulnerability and resolve it before it goes further.”

Derek Weeks, VP and DevOps Advocate, Sonatype

The alternative — learning a month after release that an application contains a critical flaw — is far more disruptive. Developers are no longer focused on that codebase, context has been lost, and in some cases the vulnerability may already have been exploited.

The Persistent Time Pressure Problem

Despite the positive trend, the survey surfaced a persistent obstacle: 50% of developers said they understand that security is important but frequently lack the time to prioritise it given their existing workloads.

This finding underscores why automation is central to the DevSecOps approach. Embedding security tooling — static analysis, dependency scanning, secrets detection — directly into CI/CD pipelines reduces the manual overhead on developers and enables security checks to run continuously without requiring dedicated context switches.

Open Source Component Risk on the Rise

The survey also tracked awareness of security breaches related to open source components — a concern that has only grown more urgent since 2017 given high-profile supply chain incidents. In 2017, 20% of respondents said they had suspected or confirmed a breach linked to an open source component in the past year, up from 14% in the 2014 survey.

This aligns with the broader industry trend of attackers targeting third-party dependencies as an attack vector — a risk that is directly addressable through software composition analysis (SCA) tools integrated early in the pipeline.

DevOps Maturity and Security Friction

The survey also examined the relationship between DevOps maturity and perceptions of security as an obstacle:

• 67% of respondents described their organisation’s DevOps practices as very mature or improving in maturity.
• 47% of respondents from traditional development and operations teams said DevOps security teams and policies were slowing them down.
• Only 28% of respondents from mature DevOps teams felt they were being slowed by security requirements.

The gap is significant: mature DevOps teams are nearly half as likely to experience security as a bottleneck compared to teams still operating in traditional silos. This reinforces the argument that investing in DevSecOps culture and tooling ultimately reduces friction rather than adding to it.

What This Means for DevOps Teams in Practice

The 2017 Sonatype data, while now several years old, established a clear directional trend that subsequent research has continued to confirm. For engineering teams looking to act on these findings, several practical steps align with the survey’s conclusions:

• Integrate security tooling into the IDE and CI pipeline so developers receive feedback on vulnerabilities at the moment of writing code, not weeks later.
• Adopt software composition analysis (SCA) to automatically flag known vulnerabilities in open source dependencies before they reach production.
• Include security requirements in the design phase — threat modelling and architecture review should happen before a line of code is written.
• Measure and report on security debt alongside feature work so leadership understands the real cost of deferred security fixes.
• Invest in developer security training to build baseline secure coding literacy across the team, reducing reliance on a separate security gatekeeper at the end of the pipeline.

Weeks summarised the cultural shift the data represents: “Security has traditionally been more of a central focus of its own, apart from everything else. But we have seen over the last few years more organisations adopting security much earlier in their software development lifecycles, as they are trying to bake security into applications so when they go into production they are more secure from the beginning.”

The empirical trend is clear. The operational question for any engineering organisation is how quickly it can move security from a final checkpoint to a continuous, automated practice woven into every stage of delivery.