Five years ago, many engineering organisations still treated application security as a release-time event: a scan, a penetration test or a sign-off sitting just in front of production. That model is steadily giving way to something different. Across regulation, open-source tooling and hiring, the clear trend is towards stage-level security controls, small safeguards embedded at each point in software delivery so that a weakness is detected where it is introduced rather than at the exit. This piece reviews where that shift stands today, what has driven it, and what it means for DevOps professionals planning their next skills investment.
The trend in one sentence
Security is moving from a gate at the end of the pipeline to a property of every stage within it. The final review has not disappeared, but its role is shrinking from primary defence to confirmation.
Driver 1: high-profile incidents exposed the blind spots of late review
Several widely reported incidents made the limits of release-time inspection hard to ignore:
- SolarWinds (disclosed December 2020). Attackers compromised the build process and inserted malicious code into signed updates. Reviewing source code at release would not have revealed it, because the tampering happened during compilation.
- Log4Shell (disclosed December 2021). A critical flaw in the ubiquitous Log4j library forced organisations to determine, urgently, whether they used it anywhere. Many could not answer quickly because they lacked a current inventory of components.
- The xz Utils backdoor (discovered March 2024). A malicious change was introduced into a widely used compression library through its upstream maintenance process and was caught shortly before it reached most stable Linux distributions.
Each case located the decisive weakness somewhere a final inspection struggles to see: the build system, the dependency tree, the upstream project. Together they pushed teams to place controls at those specific points.
Driver 2: regulation and government guidance
Policy has followed the incidents. In May 2021, US Executive Order 14028 on improving the nation’s cybersecurity directed attention to software supply-chain security, including software bills of materials for software sold to the federal government. In 2023, CISA and international partner agencies launched their Secure by Design guidance, urging vendors to take ownership of security outcomes during design and development rather than shifting the burden to customers. In Europe, the Cyber Resilience Act, in effect since late 2024, sets security requirements for products with digital elements across their lifecycle, with obligations phasing in over the following years.
The common message across these frameworks is that security must be demonstrable throughout development, not asserted at the end. That is pushing organisations to generate evidence at each stage, such as component inventories at build time and policy records at release time, which in turn requires stage-level controls.
Driver 3: tooling has made per-stage checks cheap
A decade ago, adding a security check to every commit or build could be slow and noisy. That has changed substantially. Open-source scanners for dependencies, containers and infrastructure-as-code now run in seconds to minutes. Policy engines such as Open Policy Agent let teams express release rules as code that runs identically on every deployment. Supply-chain frameworks such as SLSA, along with open artefact-signing projects that emerged around the same time in 2021, gave teams practical ways to prove where an artefact came from and that it was not altered along the way.
The practical consequence is that cost is no longer a convincing argument against stage-level controls. Our explainer on the purpose and use of a software bill of materials covers one of the most widely adopted examples.
Where adoption stands now
Rather than cite figures that vary widely between surveys, it is more useful to describe the observable pattern in engineering organisations:
- Most commonly adopted: automated dependency scanning in builds and secret detection on commits. These are low effort and high value, and most mainstream CI platforms make them easy.
- Increasingly common: container image scanning, infrastructure-as-code scanning and release gates written as policy. Teams running Kubernetes or managing cloud through Terraform tend to adopt these next.
- Still maturing: structured threat modelling during planning, build-provenance verification and runtime defence linked back to the originating team. These require changes in habit and ownership, not just tooling, so they spread more slowly.
The order is telling. Controls that can be automated spread first; controls that depend on people changing how they plan and own work spread later. Organisations that stall usually do so at this boundary between tooling and culture.
How the shift looks inside a single team
The macro trend is easiest to understand at the scale of one product team. Under the older model, a team might have spent most of a quarter building, then handed a release candidate to a security group for review, received a findings report and spent the final weeks fixing issues that had been embedded for months. Under the emerging model, the same team sees small, specific feedback continuously: a commit blocked because it contains a token, a build that fails because a library has a newly published flaw, a deployment halted because a storage bucket in a template would be public. Each signal arrives within minutes of the action that caused it, addressed to the person who can fix it. The security group’s role changes too, from inspector to designer of the controls and adviser on the hard cases those controls escalate.
What is changing in roles and skills
The shift is reshaping job descriptions. Security responsibilities that once belonged to a separate team are being distributed into platform, DevOps and development roles. Hiring managers increasingly expect DevOps engineers to be able to wire security scanning into pipelines, tune results so developers trust them and explain why each control exists. Managers are expected to set governance and keep these habits alive across teams. Architects are expected to design policy-as-code and zero-trust patterns that span environments.
Training providers have responded with role-specific paths. DevSecOpsSchool’s role-based DevSecOps programmes are one illustration of that trend: rather than a single generic course, it splits its certifications by job, so a manager track concentrates on governance, security culture and enabling teams while an architect track takes on enterprise blueprints, multi-cloud and zero trust, and complements them with consulting on secure CI/CD roadmaps and hands-on security automation implementation. Readers comparing options across the wider landscape may find our overview of certifications spanning DevOps, SRE and DevSecOps useful context.
Open questions for the next few years
The direction is clear, but several questions remain unsettled:
- Signal versus noise. As more checks run at more stages, alert fatigue becomes a real risk. The teams that succeed will be those that tune aggressively and block only on findings that matter.
- Upstream responsibility. Incidents like xz Utils show that some risks originate in open-source projects maintained by small groups of volunteers. How organisations contribute to, or verify, those upstream processes is still being worked out.
- Evidence for regulators. As lifecycle obligations take effect, teams will need stage-level records that are reliable and auditable without becoming a paperwork burden.
- Developer experience. Controls that slow delivery invite workarounds. Keeping each safeguard fast is as much a security requirement as a usability one.
What this means for practitioners
For individual DevOps professionals, the practical implication is straightforward. Understanding how to place, configure and maintain a security control at each relevant stage of a pipeline is moving from a specialist niche to a baseline expectation. A good starting point is to master the controls that are already widely adopted, then build towards the planning and policy work that is still maturing. Our deeper look at architecting live systems that combine CI/CD, security and monitoring shows how these controls fit into a production-grade design.
Conclusion
The state of the field can be summarised simply: the industry has largely accepted that security cannot be inspected into software at the final step. Incidents demonstrated the blind spots, regulators codified the expectation, and tooling removed the cost barrier. What remains is the harder, human part of the transition, making stage-level safeguards a normal part of how every team plans, builds and ships.
