A global financial services organisation saved £200,000 in its first three months by automating just four security controls. As Catapult CX’s Financial Services security transformation case study shows, those savings did not come from adding another security gate before release. They came from redesigning how security operated across the software delivery lifecycle.
DevSecOps integrates security into software development and operations, making it a shared responsibility supported by repeatable processes, automation and continuous feedback.
‘Shift left’ is an important part of that model. It brings security decisions and testing into earlier stages of development, when teams have more opportunity to prevent problems rather than correct them later.
But shifting security left is not enough, particularly in regulated organisations.
Security must also protect the build environment, govern deployment, monitor vulnerabilities in production and feed what happens in operation back into development. Regulated organisations must also be able to demonstrate which controls operated, who approved exceptions and what evidence was retained.
All of this has to work across multiple teams without turning developers or the central security function into a bottleneck.
What is DevSecOps?
DevSecOps stands for development, security and operations.
It extends DevOps by treating security as part of the normal delivery system rather than a separate activity performed once software has largely been completed.
The NIST National Cybersecurity Center of Excellence uses a notional DevSecOps model covering seven lifecycle phases – Plan, Develop, Build, Test, Release, Deploy and Operate. Continuous security, monitoring and feedback run across those phases.
Shift left brings security into the lifecycle earlier. DevSecOps keeps it embedded throughout delivery and operation.
Why shift left is necessary but not enough
In a traditional delivery model, teams design and build software before security specialists assess it close to release. If vulnerabilities, architectural problems or compliance issues emerge at that stage, the organisation must either:
- delay the release
- accept additional risk
- create an exception
- send the work back for remediation
The NCSC’s Secure Design and Development guidance, aimed primarily at organisations that develop or sell software, recommends establishing security requirements, threat modelling and secure development practices from the beginning of the lifecycle. It also recognises that secure development depends on the right people, processes and technology.
However, introducing controls earlier addresses only part of the risk.
An insecure build environment can still compromise the software supply chain. Without production monitoring, new vulnerabilities and changes in risk cannot inform future development. If every difficult decision still requires intervention from a small central security team, delivery will continue to slow as the organisation scales.
Enterprise DevSecOps must therefore embed security throughout the lifecycle and use evidence from later stages to improve what happens earlier.
What enterprise DevSecOps looks like in practice
Catapult CX encountered these challenges when working with one of the world’s largest insurance and financial services providers.
Security was introduced late in the software development lifecycle. Practices and tooling varied between business units, security teams worked in silos and much of the work remained manual. This created release bottlenecks and made it difficult to apply consistent governance across the organisation.
Buying more security tools would not have resolved the underlying problem. We helped redesign the operating model.
| Problem | Intervention |
| Security introduced late | Security embedded throughout the software development lifecycle |
| Manual security activity | SAST, DAST, runtime testing, infrastructure and configuration scanning automated through CI/CD |
| Security specialists becoming bottlenecks | Development teams given greater ownership for security |
| Fragmented standards | A common NIST-aligned framework applied across policy, governance and maturity assessment |
| Knowledge held in separate teams | Security Community of Practice established |
| Cloud adoption constrained by risk | Secure Azure environments provisioned through Infrastructure as Code |
| Inconsistent delivery between business units | Repeatable planning frameworks introduced across the organisation |
The changes reduced manual intervention and accelerated delivery. Automating the first four security controls produced the £200,000 saving highlighted in Catapult CX’s Financial Services security transformation case study.
The value did not come from any individual scanner. It came from connecting the technology to clear ownership, common standards, repeatable workflows, governance and feedback.
What enterprise-scale DevSecOps requires
1. Security starts before code
Security testing cannot fully compensate for insecure design.
Security requirements, architecture decisions and threat modelling should begin during planning and design, while teams still have the scope to change the solution.
The NCSC’s Secure Design and Development guidance recommends using established secure-development frameworks, defining security requirements, undertaking threat modelling and applying secure-by-design principles from the beginning of the lifecycle.
2. Testing becomes part of normal delivery
Security testing needs to be repeatable and integrated into the engineering workflow rather than reserved for periodic assessments.
Different controls identify different types of risk.
| Control | Typical role |
| SAST | Analyses source code for security weaknesses before it is executed |
| SCA | Identifies known vulnerabilities and other risks in third-party dependencies |
| DAST | Tests a running application externally for exploitable weaknesses |
| Runtime security testing and monitoring | Identifies security issues while an application is running |
| Infrastructure and configuration scanning | Identifies insecure infrastructure or configuration before or during deployment |
| Secrets scanning | Detects credentials and other sensitive information introduced into repositories or pipelines |
The objective is not to introduce every available scanner. It is to automate controls that address relevant risks and provide feedback at a point when teams can act on it.
A security gate that generates thousands of low-value alerts does not improve delivery. It creates an automated bottleneck.
3. The build pipeline becomes security-critical infrastructure
Moving testing earlier can create false confidence if the build environment itself is poorly controlled.
The NCSC’s Build Environment Security guidance explains that compromising a build environment can affect software further along the supply chain. It recommends controls including defined access roles, strong authentication, protected credentials and auditable logs.
Repositories, build servers, package stores, deployment credentials and CI/CD tooling should therefore be treated as privileged infrastructure.
Pipeline security is not limited to what the pipeline scans. The systems performing the scanning, building and deployment must also be protected.
4. Policies become repeatable controls
A security process that depends on an expert remembering which standard applies to every release becomes increasingly fragile as the number of engineering teams grows.
NIST’s DevSecOps guidance includes Security as Code, through which security policies and configurations can be version-controlled and applied through automated delivery practices.
This does not mean automating every risk decision. Predictable controls should be automated where appropriate, while exceptions and material decisions remain subject to human judgement.
For infrastructure changes, GitOps can support the same principle. A version-controlled desired state and automated reconciliation make proposed changes easier to review, apply consistently and evidence.
5. Security continues after deployment
Applications do not stop changing after release. New vulnerabilities emerge, dependencies are updated, configurations drift and the threat environment develops.
NIST’s DevSecOps lifecycle model therefore includes an Operate phase supported by continuous monitoring and feedback. The NCSC’s Secure Deployment and Maintenance guidance also covers the ongoing detection, prioritisation and remediation of vulnerabilities, alongside security updates and response processes.
A complete DevSecOps model uses what happens in production to improve requirements, design, testing and controls in the next delivery cycle.
Why DevSecOps tools are not enough
DevSecOps tools are necessary, but the operating model determines whether they improve security or create more work.
An organisation may have source-code and dependency scanning, secrets detection, policy-as-code checks, container scanning, vulnerability management and runtime monitoring. Their value depends on how they are integrated into delivery and what happens when they identify a problem.
Teams need clear answers to practical questions:
- Which risks does each control address?
- Who owns and resolves the findings?
- Which findings prevent a release?
- Who can approve an exception?
- Where is that decision recorded?
- What happens when the same vulnerability recurs?
Without defined ownership, thresholds and escalation routes, additional tools generate more alerts without necessarily reducing risk.
Catapult CX’s DevOps transformation approach therefore starts by identifying the constraint in the delivery system rather than assuming another platform will resolve it.
DevSecOps and compliance in regulated environments
In regulated environments, organisations will commonly need to demonstrate that relevant controls exist and operate effectively.
For compliance leaders, the benefit of DevSecOps is not fewer controls. It is more consistent execution and less manual effort collecting evidence that those controls operated.
The NCSC’s Assurance Principles and Claims guidance illustrates the types of evidence a software provider may need. These include defined roles and permissions, controlled credentials, logs of access and changes to the build environment, and records retained for an agreed period.
A well-designed DevSecOps model can create much of this evidence through normal delivery, including:
- pull and merge-request histories
- automated security-test results
- vulnerability and remediation records
- access and pipeline approvals
- deployment histories
- security exceptions and risk decisions
- runtime monitoring and incident records
However, evidence that a control operated does not prove that the control was appropriate or effective.
Security, risk and compliance teams must still define the required controls, review their effectiveness and retain oversight of exceptions and other material decisions.
Why DevSecOps fails at enterprise scale
A common reason DevSecOps fails is that it is treated as a tooling project while the operating model remains unchanged.
A scanner is added to the pipeline, but security specialists still approve every difficult decision. Developers receive findings without the context, authority or capability to resolve them. Business units continue to apply different standards, and responsibility remains concentrated in a small central team.
Security has not shifted left. The queue has shifted left.
A scalable model distributes security capability without expecting every developer to become a security specialist.
The NCSC’s Secure Design and Development guidance recognises that developers need access to appropriate expertise, training, processes and usable security technology.
Security champions, Communities of Practice, reusable controls and common standards provide that support. The central security team defines the organisation’s standards, develops shared capability and handles material escalations. Engineering teams can then make routine security decisions and deliver safely within that framework.
How to introduce DevSecOps without slowing delivery
Do not begin with a shopping list of security products. Begin by understanding how security currently operates across the software lifecycle.
Map where vulnerabilities are first discovered, where security specialists perform manual work and where teams wait for approval. Identify differences in standards between products or business units, gaps in developer feedback, evidence that must be assembled manually and security issues that repeatedly reach production.
Then introduce change in a clear sequence:
- Prioritise the points creating the greatest risk or delay.
- Automate repeatable, high-volume activity where the result will be actionable.
- Define who owns each type of finding and who is responsible for remediation.
- Agree which risks should stop delivery, which can be accepted and who can approve an exception.
- Capture evidence through the workflow instead of reconstructing it before an audit.
Measure the results rather than whether teams have adopted something labelled DevSecOps. Useful measures include:
- security-review lead time
- vulnerability age and remediation time
- number of manual interventions
- recurring vulnerabilities
- false-positive rates
- time required to produce control evidence
If the main constraint sits within the pipeline, our CI/CD Pipeline Optimisation service focuses on improving its automation, reliability and delivery flow.
Where the constraint is not yet clear, the DevOps Health Check & Uplift provides a diagnostic starting point before the organisation commits to a specific intervention.
The objective is not to move every security activity earlier. It is to ensure that each control operates at the right point, evidence is created as part of delivery and teams can move quickly without losing control.
DevSecOps FAQs
What is DevSecOps?
DevSecOps is an operating model that integrates security throughout software development and operations. It combines secure design, automated testing, pipeline controls, production monitoring, governance and shared ownership so security becomes part of normal delivery rather than a final approval stage.
What is the difference between DevOps and DevSecOps?
DevOps uses collaboration, automation and feedback to improve how development and operations teams deliver software. DevSecOps makes security an explicit shared responsibility within the same delivery model and embeds security practices and controls throughout the lifecycle.
What does shift left mean in DevSecOps?
Shift left means addressing security earlier in the software lifecycle, when teams have more opportunity to prevent problems. Typical practices include defining security requirements, threat modelling, secure design, code scanning and dependency analysis.
Shift left is one part of DevSecOps. Security must also extend into the build environment, deployment, production monitoring and ongoing vulnerability management.
What tools are used in DevSecOps?
Common tools include:
- static application security testing
- software composition analysis
- dynamic application security testing
- secrets scanning
- Infrastructure as Code and policy-as-code checks
- container scanning
- vulnerability management
- runtime monitoring
The right combination depends on the organisation’s risks, technology and delivery model. Tools must also be supported by clear ownership, release criteria and processes for managing findings and exceptions.
What is a DevSecOps pipeline?
A DevSecOps pipeline integrates appropriate security tests and policy checks into CI/CD. It provides security feedback as software moves through development, build, testing and deployment, while retaining evidence of the controls applied and the decisions made.
The pipeline itself must also be secured, including its repositories, build environments, credentials, access permissions and deployment tooling.
Does DevSecOps slow software delivery?
Poorly implemented DevSecOps can slow delivery if it introduces excessive alerts, unclear release criteria or additional approval queues.
A well-designed model should reduce delays by identifying issues earlier, automating repeatable controls and allowing engineering teams to resolve routine findings without waiting for a central security team.
Who is responsible for security in DevSecOps?
Security is a shared responsibility, but that does not mean every role has the same responsibilities.
Central security teams define standards, provide specialist expertise and oversee material risks. Engineering teams apply the controls, respond to findings and make routine decisions within the agreed framework. Risk and compliance teams help define evidence and oversight requirements.
Does DevSecOps help with regulatory compliance?
DevSecOps can make regulated delivery easier to control and evidence by applying repeatable checks and retaining security, approval, exception and deployment records.
It does not make an organisation compliant automatically. The organisation must still determine which controls are required, assess whether they are effective and maintain appropriate governance and oversight.
