Integrating security into DevOps remains a governance problem

At a glance

What this is: DigiCert’s survey shows nearly half of enterprises are integrating security into DevOps, with the report arguing that this improves both delivery and security outcomes.

Why it matters: For IAM, NHI, and platform security teams, the lesson is that identity controls must move into the delivery pipeline rather than remain a late-stage gate that developers route around.

By the numbers:

• 49% of enterprises are currently integrating security into their existing DevOps practices.
• The survey assessed more than 300 individuals at hundreds of organizations throughout the U.S.

👉 Read DigiCert's report on integrating security into DevOps

Context

Security in DevOps is the practice of building security into the same workflow that delivers software, infrastructure, and configuration. When it sits outside that workflow, teams trade speed for friction and often end up with brittle controls that developers bypass.

For IAM and NHI programmes, the deeper issue is governance. Identity decisions about access, secrets, approvals, and automation need to be made where code and infrastructure are created, not after deployment has already widened the blast radius.

Key questions

Q: How should security teams integrate identity controls into DevOps pipelines?

A: Start by moving identity checks to the earliest practical stage in delivery, such as pre-merge, build, or pre-deploy gates. Focus on the controls that most often create operational risk, including service account permissions, secret exposure, and deployment credentials. The goal is to make secure identity behaviour the default path for release, not a separate review step.

Q: Why do security controls fail when they sit outside DevOps workflows?

A: They fail because they arrive after the design choices are already locked in and teams are under pressure to ship. That produces exceptions, manual overrides, and bypasses that undermine both speed and security. In DevOps, governance must shape the workflow itself or it will be treated as an obstacle rather than a control.

Q: How do teams know whether integrated security is actually working?

A: Look for fewer ad hoc exceptions, less manual rework, and more consistent handling of identities, secrets, and policy across delivery teams. If the same control behaves differently from one pipeline to another, standardisation has not been achieved. Effective integration should reduce friction while making identity decisions more predictable.

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

A: 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.

Technical breakdown

Why security bolted outside DevOps fails

When security is treated as a separate approval stage, it usually arrives too late to influence how code, infrastructure, and access patterns are designed. DevOps emphasises rapid change, so disconnected security reviews tend to create delays, exceptions, and shadow workarounds. The real failure is not a lack of intent but a governance model that assumes security can remain external to the delivery system. Once infrastructure is ephemeral and access is automated, out-of-band controls lose visibility into the state they are meant to govern.

Practical implication: move identity and security checks into the pipeline so they operate on the same artefacts developers ship.

What integrated security changes in identity governance

Integrated security means access decisions, secrets handling, and policy enforcement are embedded in the delivery process itself. For IAM and NHI, that changes the control point from post-deployment review to pre-merge or pre-release enforcement, where permissions can be evaluated against what the system is actually about to do. This matters because many DevOps risks are identity risks in disguise: overbroad service account permissions, exposed credentials, and unattended exceptions. Integration also enables standardisation, which is essential when teams manage many services and environments at once.

Practical implication: standardise controls for credentials, service accounts, and deployment permissions before teams scale the pipeline.

Why automation only works when it is bounded

The report’s recommendation to use automation where it makes sense reflects an important limit. Automation can accelerate scans, policy checks, and rotation workflows, but it cannot fix a broken operating model that leaves ownership unclear or exceptions unmanaged. In practice, automation works best when the decision logic is stable and the control objective is precise. If teams automate weak assumptions, they simply produce failures faster. The stronger pattern is automation plus explicit governance, so the machine executes policy rather than improvising it.

Practical implication: automate repetitive identity checks, but keep ownership and exception handling explicit.

NHI Mgmt Group analysis

Security outside DevOps is a governance failure, not a tooling gap. The report’s central tension is that enterprises want speed and control at the same time, but separate processes force them to choose one over the other. That creates predictable bypass behaviour, especially when development teams are under delivery pressure. The practitioner conclusion is straightforward: if security is not part of the delivery system, it will be treated as optional.

Identity controls belong in the same lifecycle as code and infrastructure. Access to pipelines, build systems, deployment tooling, and secrets stores is itself part of DevOps governance, not a separate administrative concern. Once teams accept that service accounts and deployment credentials are production assets, the control model shifts from periodic review to continuous operational assurance. The practitioner conclusion is to manage identity where change happens, not where audit happens.

Automation without standardisation only speeds up inconsistency. The report’s call to integrate and standardise is the right one because DevOps magnifies every exception and every local workaround. In identity terms, that means the same approval logic, credential handling, and role boundaries should be applied across environments rather than reinvented per team. The practitioner conclusion is to use shared policy as the foundation for scale.

The named concept here is security-in-DevOps drift: security controls that remain organisationally adjacent but operationally detached from delivery. That drift turns identity and access decisions into delayed afterthoughts, which is exactly where they lose usefulness. The report shows that the market has already reached the point where integration is no longer optional for mature programmes. The practitioner conclusion is to close the distance between governance intent and delivery execution.

For NHI programmes, DevOps is the control plane for machine identity. Build pipelines, release systems, and automation tooling routinely create and consume the credentials that service workloads depend on. That means NHI governance cannot sit only in vaults or periodic reviews; it has to be enforced in the same workflows that mint, use, and retire access. The practitioner conclusion is to treat DevOps as a core NHI control surface.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For the broader market context, Ultimate Guide to NHIs , Key Challenges and Risks maps the control gaps that make integration into delivery pipelines so difficult.

What this signals

Security-in-DevOps drift: programmes that keep identity and security controls outside delivery will keep paying for exceptions, rework, and inconsistent enforcement. The operational signal to watch is whether service account governance, secret handling, and release approvals are converging into one control model or fragmenting across teams.

The market is moving toward embedded governance because the old separation between build-time and security-time is increasingly artificial. Teams that still rely on late-stage checks will find that their identity controls are least effective exactly where change is fastest.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per the State of Non-Human Identity Security, the lesson for DevOps programmes is that delivery pipelines and delegated access need the same integrated oversight.

For practitioners

• Embed security checks in pipeline gates Apply policy checks to code, infrastructure, and configuration before deployment so access and secret issues are caught while change is still cheap to fix.
• Standardise identity controls across delivery teams Define the same rules for service accounts, secrets, and deployment permissions across environments to reduce exceptions and shadow practices.
• Assign security ownership to DevOps initiatives Name a security lead for each major delivery stream so identity risk is handled as part of delivery design rather than after release.
• Automate repetitive identity tasks with clear guardrails Use automation for credential rotation, policy validation, and drift detection, but keep exception approval and ownership explicit.

Key takeaways

• Security works better in DevOps when it shapes delivery decisions early rather than acting as a late-stage gate.
• Identity and access controls are part of the release process, especially where pipelines mint, use, and retire credentials.
• Automation only improves governance when teams standardise policy, ownership, and exception handling across delivery workflows.

Key terms

• DevSecOps: DevSecOps is the practice of integrating security into software delivery rather than treating it as a separate review function. In identity terms, it means access, secrets, and policy controls are enforced within the build and release lifecycle where change is created and deployed.
• Pipeline identity: Pipeline identity is the collection of service accounts, tokens, keys, and permissions used by build and deployment systems. These identities are non-human identities because they act in software workflows, and they need lifecycle, scope, and rotation controls just like any other production credential.
• Security-in-DevOps drift: Security-in-DevOps drift describes the gap that appears when security controls remain organisationally adjacent to delivery but operationally separate from it. The result is inconsistent enforcement, manual exceptions, and weaker identity governance at the point where infrastructure and access are changing fastest.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: New Report Gives Recommendations for Integrating Security into DevOps. Read the original.