Separating DevOps from security creates gaps between speed and control, especially when software supply chain attacks are rising. If teams optimise only for delivery, vulnerabilities can move downstream into production and become harder to fix. A combined DevSecOps model reduces blind spots by making security decisions part of build, test, and release activities from the start.
Why the split increases delivery risk
When DevOps and security sit in separate lanes, the delivery system tends to optimise for throughput first and control second. That creates a handoff problem: code, build logic, infrastructure changes and release decisions can all move faster than the security review that is supposed to catch weak defaults, exposed secrets or unsafe dependencies before they reach production.
The practical risk is not just that issues exist, but that they become harder to see once they are embedded in pipelines, deployment scripts and shared services. In modern delivery, the most damaging failures are often not isolated code defects, but process gaps where no team fully owns the security outcome of the release.
Separation also encourages local optimisation. Dev teams may treat security as a late-stage gate, while security teams may focus on policy after the fact rather than on the build and release mechanics where defects are introduced. That split weakens feedback loops, slows remediation and increases the chance that a vulnerable artifact is promoted because the delivery path is already considered “done”.
Where modern software delivery becomes most exposed
Modern delivery is especially sensitive because the attack surface now includes source control, CI/CD systems, package dependencies, container images, infrastructure-as-code and deployment credentials. A weakness in any one of those layers can become a production issue if security is not built into the same workflow that creates and releases the software.
This is why pipeline security, build integrity and secrets handling matter as much as application code review. The CI/CD pipeline exploitation case study shows how exposed pipeline material and mismanaged secrets can turn a delivery system into an attacker entry point, while Emerald Whale breach illustrates how exposed configuration and repository content can cascade into large-scale secret theft and repository compromise.
Delivery teams also need to recognise that supply-chain control is now part of software reliability. If provenance, dependency integrity and release trust are handled outside the delivery flow, the organisation is effectively trusting artifacts it has not fully verified. The result is delayed detection, wider blast radius and more expensive rollback when a defect or malicious change slips through.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | DevOps-security separation increases configuration drift and unsafe defaults in delivery systems. |
| CIS Control 16 — Application Software Security | The risk arises when security checks are detached from software construction and release. | |
| CIS Control 15 — Service Provider Management | Modern delivery often depends on external services and supply-chain relationships that need governance. | |
| Recommendation — Enforce secure build and deployment configurations across pipelines and release tooling. Embed security testing and review into the software development lifecycle. Assess third-party delivery dependencies and require security assurances for shared tooling. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Pipeline and release weaknesses can expose code, secrets and sensitive deployment material. |
| PR.IP — Information Protection Processes and Procedures | The question centers on process separation that weakens integrated security practice. | |
| GV.SC — Supply Chain Risk Management | Software delivery now depends on artifacts, dependencies and pipelines that must be trusted end to end. | |
| Recommendation — Protect sensitive build and release data throughout the delivery lifecycle. Integrate security procedures into development and release processes. Apply supply-chain risk controls to software artifacts, dependencies and delivery tooling. | ||
| OWASP Agentic AI Top 10 | Software Supply Chain Security | Modern delivery risks include compromised artifacts and pipeline trust, which this control family addresses. |
| Recommendation — Verify build provenance and harden the software supply chain before release. | ||
Practitioner Guidance
What to verify: Check whether security requirements are enforced where code is actually built and deployed, not only in a separate approval step. If a release can still proceed after a failed control without an explicit exception record, the process is leaving a gap.
Decision rule: If the team cannot trace who approved the build, who can change the pipeline, and what security checks ran on the artifact that reached production, treat the release path as incomplete. That is the point to rework the workflow, not just add another review meeting.
What good looks like: Security controls are part of the same delivery mechanics as testing and deployment, with clear ownership for pipeline changes, artifact trust, secret handling and rollback decisions. The best signal is a workflow where security findings are resolved before release, not deferred into production support.
Practitioner takeaway: The main risk is not simply “missing security review”, it is losing shared ownership of the release outcome. Once speed and control are separated, organisations usually discover the weakness only after the vulnerable change has already become operational.
Related resources from NHI Mgmt Group
- Why does treating security as a late-stage activity increase supply chain risk in modern software environments?
- Why do APIs create more security risk as organisations move faster in modern software delivery?
- Why do abandoned GitHub Actions increase operational and security risk in software delivery?
- Why do disconnected development tools increase risk in modern software delivery?
