Integrating security into DevOps remains a governance problem

At a glance

What this is: DigiCert’s report argues that integrating security into DevOps is a governance challenge, not just a tooling choice, and says 49% of enterprises were already doing it in 2017.

Why it matters: For IAM, PAM and NHI programmes, the lesson is that controls fail when they are bolted on after delivery processes are set, because ownership and workflow design determine whether security is actually enforced.

Context

Security in DevOps is the question of whether security controls are built into delivery workflows from the start, or layered on after teams have already optimised for speed. The governance problem is that development, operations and security often optimise different outcomes unless someone explicitly designs the process to reconcile them.

DigiCert’s survey frames that tension as a tipping point, with a material share of enterprises already integrating security into DevOps practices. The important issue for identity teams is not the tooling label but whether identity, certificate and access controls are part of the delivery system itself rather than an external approval step.

When security sits outside the workflow, teams tend to treat it as a gate at the end of the process. That usually creates slower delivery, weaker accountability and less reliable enforcement, which is why the article’s recommendations focus on leadership, embedded security roles, automation and standardisation.

Key questions

Q: How should security teams implement SecDevOps without slowing delivery?

A: Start with advisory controls, not blocking gates. Define security requirements as code, automate the highest-value tests in CI/CD, and move to enforcement only after false positives are low and remediation paths are clear. The goal is to make security decisions repeatable and fast enough to fit engineering flow, not to add a second approval system.

Q: Why do DevSecOps programmes fail when teams keep security knowledge siloed?

A: DevSecOps fails when security is treated as a specialist function instead of a shared practice. The article stresses that engineers need strong communication, teamwork, and enough knowledge of tools, languages, and infrastructure to act on security issues quickly. Without that shared understanding, security work becomes disconnected from development decisions and slows response across the pipeline.

Q: What are the signs that security is being treated as an afterthought in DevOps?

A: Common signs include security teams arriving only near deployment, repeated delays caused by late findings, hardcoded credentials slipping into code, and infrastructure changes shipping without policy checks. Another warning is when developers see security as a separate gate instead of part of daily work. Those patterns usually mean the pipeline is optimized for speed but not resilience.

Q: Who is accountable for security in a DevSecOps model?

A: Accountability should be shared, but not vague. Engineering owns implementation, security owns policy and assurance, and operations owns runtime consistency. The important part is that responsibilities are explicit for each control, because shared ownership fails when no one is responsible for fixing the finding.

Technical breakdown

Why security fails when it sits outside DevOps workflows

DevOps changes the operating model by shortening release cycles and pushing more decisions into automated pipelines. If security is treated as a separate review function, it arrives too late to influence code, infrastructure, certificate handling or access decisions. The result is not just delay, but a split governance model where delivery owns speed and security owns exceptions. That split is unstable because the people closest to the change can bypass the control path, intentionally or otherwise. In identity terms, the control plane must move closer to the workflow that creates or changes access.

Practical implication: put security control points inside the delivery path, not after it.

The governance role of leadership, ownership and standardisation

The report’s recommendations are fundamentally governance moves. Appointing a leader for cultural change creates ownership for how security is introduced into engineering routines. Putting security leads on DevOps initiatives ensures that control requirements are represented when pipelines, environments and release standards are designed. Standardisation matters because security in DevOps breaks down when every team invents its own process for secrets, approvals and deployment exceptions. Without common patterns, controls become tribal knowledge rather than enforceable practice. That is especially relevant where identity and credential handling must remain consistent across multiple delivery teams.

Practical implication: define who owns security design decisions for delivery pipelines and make the operating standard reusable.

Automation only works when it enforces the right policy

The article supports automation, but only where it makes sense. In practice, automation is useful when it removes repetitive steps from secure delivery, such as validation, policy checks, and repeatable control enforcement. It becomes harmful when it automates an immature process or hides exceptions that should be visible to governance. For identity security, this distinction matters because machine credentials, certificates and access grants are often created and consumed by pipelines at machine speed. If the policy is weak, automation simply propagates weakness faster. Automation should therefore serve the control design, not replace it.

Practical implication: automate only the controls that have clear policy, ownership and exception handling.

Threat narrative

Attacker objective: The objective is not a classic intrusion but the preservation of a delivery model that prioritises speed over embedded security, leaving identity and access controls less reliable.

1. Entry occurs when development and security operate as separate functions, allowing insecure changes to move through delivery without early control review.
2. Escalation happens when exceptions, ad hoc approvals or manual workarounds become the normal path for release activity and credential handling.
3. Impact is slower delivery, inconsistent enforcement and a security posture that is patched after the fact instead of governed at design time.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Security-in-DevOps is a governance design problem before it is a tooling problem: the article is really about where control ownership lives in the delivery model. If security decisions are made after pipeline design, they arrive too late to shape release behaviour. The practitioner conclusion is that identity and security governance must be embedded in the process architecture, not appended to it.

Culture change is the control surface that determines whether DevOps security holds: appointing a leader for cultural change is not a soft recommendation, it is a mechanism for making security decisions durable across teams. Without clear accountability, each product group improvises its own exceptions, which fragments policy enforcement. The practitioner conclusion is to treat operating model ownership as a security control.

Automation without governance standardisation simply scales inconsistency: the article’s support for automation is conditional on the process already being well defined. In delivery environments, automated checks only help when the underlying identity, access and release rules are consistent across teams. The practitioner conclusion is to standardise before you accelerate.

Identity controls belong inside the delivery system, not adjacent to it: the DevOps model changes how access, certificates and secrets are created, consumed and revoked. That means IAM and certificate governance cannot be managed as separate afterthoughts if teams want predictable outcomes. The practitioner conclusion is to integrate identity controls into pipeline design and release governance.

Integrated security and development improve together when the workflow is designed for both: the article correctly rejects the false choice between agility and security. In mature environments, the security function shapes the workflow rather than obstructing it, and the delivery function benefits from fewer late-stage surprises. The practitioner conclusion is to measure governance by whether the process itself produces secure outcomes by default.

What this signals

Security in DevOps only becomes durable when governance moves upstream into the delivery model itself. If identity, approval and release rules are still decided after teams have built the workflow, the organisation has not integrated security, it has only added friction.

Delivery-governed security: the useful pattern here is not “more security in DevOps” but security decisions made inside the operating model that produces software. That is the point where IAM, secrets handling and release standards stop being separate programmes and start behaving as one control system.

For practitioners

• Appoint a delivery security owner Assign one accountable leader for how security requirements enter DevOps workflow design, exception handling and release standards.
• Embed security leads in pipeline design Require security representation in every material DevOps initiative so identity, approval and control requirements are set before rollout.
• Standardise identity and release controls Use the same approach for secrets handling, approvals and change promotion across teams so controls are repeatable and auditable.
• Automate only well-defined checks Limit automation to control steps with clear policy, ownership and failure handling, rather than encoding informal exceptions into pipelines.

Key takeaways

• The article’s central point is that DevOps security succeeds or fails as a governance design choice, not a tooling purchase.
• DigiCert’s survey says 49% of enterprises were already integrating security into existing DevOps practices, which shows the shift was already underway in 2017.
• Embedding security early, assigning ownership and standardising controls are the practical levers that make delivery both faster and more reliable.

Key terms

• DevOps Governance: DevOps governance is the set of ownership, policy and decision-making structures that shape how software is built, tested and released. In practice, it determines whether security is embedded in the workflow or left as an external review step that teams can bypass or delay.
• Embedded Security Guidance: Embedded security guidance is inline, context-aware advice delivered inside the developer workflow instead of in separate reports or tickets. It helps developers correct code while they are still working on it. This reduces handoff friction, improves adoption, and makes remediation more actionable at the point of creation.
• Pipeline Standardisation: Pipeline standardisation is the use of common patterns for release, approval, secrets handling and control enforcement across delivery teams. It reduces the chance that each team invents its own security exceptions, which is a common source of inconsistent identity governance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.