What is the difference between embedding security in DevOps and adding more approvals?

Embedding security means putting policy and identity checks where work already happens. Adding more approvals usually just increases delay and encourages workarounds. The difference is whether security changes the operating model or simply adds another gate in front of it.

Why This Matters for Security Teams

Security in DevOps is not just about putting controls earlier in the pipeline. It is about making policy, identity, and verification part of the path that code, secrets, and deployments already take. That distinction matters because approval-heavy models often treat risk as a paperwork problem instead of an execution problem. In modern delivery environments, delays push teams toward bypasses, shared accounts, and manual secret handling, which weakens both governance and accountability.

Frameworks such as the NIST Cybersecurity Framework 2.0 and NHIMG research on the CI/CD pipeline exploitation case study both point to the same operational reality: control points need to follow the workflow, not sit outside it. A security review that happens after a build is complete may still be useful, but it does not prevent insecure secrets, over-privileged service accounts, or risky deployment paths from being created in the first place. In practice, many security teams encounter the real failure only after the first workaround has already become the standard process.

How It Works in Practice

Embedding security in DevOps means shifting from approval gates to continuous enforcement. Instead of asking a human to validate every deployment, the pipeline checks identity, policy, and context automatically at each step. That can include signed build artifacts, short-lived credentials, policy-as-code checks, environment-specific access decisions, and secret scanning before release. The goal is to make the secure path the easiest path.

This is especially effective for secrets and non-human identities. NHIMG’s 2024 State of Secrets Management Survey found that 88% of security professionals are concerned about secrets sprawl, which helps explain why manual approval chains do not scale well when secrets are created, copied, and consumed across automated workflows. A better pattern is to issue credentials just in time, scope them tightly, and revoke them automatically when the task ends. Current guidance from the NIST Cybersecurity Framework 2.0 supports continuous risk management rather than one-time signoff.

Practitioners usually combine:

• identity-aware pipeline access, so each service and job proves what it is before it can act;
• policy checks at commit, build, test, and deploy stages, rather than a single release approval;
• ephemeral secrets and workload identities, so long-lived shared credentials are removed from the process;
• auditable automation, so exceptions are logged as policy decisions rather than informal bypasses.

This model is materially different from adding more approvals because the control is embedded in execution, not appended to it. These controls tend to break down when teams rely on shared CI accounts and manually copied secrets because the workflow no longer has a trustworthy identity boundary.

Common Variations and Edge Cases

Tighter automated controls often increase pipeline complexity, requiring organisations to balance delivery speed against governance depth. That tradeoff is real, especially in legacy environments where tooling was built around human signoff and long-lived service accounts. Best practice is evolving, but there is no universal standard for how much approval is still appropriate versus fully automated policy enforcement.

In regulated environments, some approvals still make sense for high-impact releases, emergency exceptions, or production changes with customer-facing risk. The key is not to confuse oversight with control. A human approval can verify that a change was reviewed, but it cannot reliably reduce secret exposure, stop privilege creep, or enforce least privilege across machine-to-machine activity. NHIMG’s Emerald Whale breach illustrates how pipeline weaknesses can turn into wider identity and access failures when automation is not governed at the point of use.

For teams modernising DevOps, the practical question is whether security changes behaviour or just slows it down. If the answer is only delay, the organisation has likely added an approval layer, not embedded security.

Related resources from NHI Mgmt Group

• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?