TL;DR: DevSecOps shifts security into the planning, build, and deployment stages so teams can catch vulnerabilities, secrets, misconfigurations, and certificate handling issues before production, according to GlobalSign. The operating model matters because pipeline speed without embedded controls turns delivery into an exposure window, not a resilience gain.
At a glance
What this is: This is an analysis of how DevSecOps embeds security into CI/CD pipelines so issues like vulnerabilities, secret leakage, misconfiguration, and certificate handling are addressed earlier in the delivery lifecycle.
Why it matters: It matters because IAM, PKI, and NHI governance teams need pipeline controls that reduce exposure windows for credentials, certificates, and access policies before code reaches production.
By the numbers:
- 60% of respondents said implementing DevSecOps is technically challenging, according to a Gartner survey cited by GlobalSign.
Context
DevSecOps is the practice of embedding security into the software delivery lifecycle instead of treating it as a final checkpoint. In CI/CD environments, that shift matters because vulnerabilities, insecure configurations, exposed secrets, and certificate handling issues can move from development into production if controls appear too late.
For IAM, PKI, and NHI governance teams, the relevant change is not just process discipline but control placement. Secrets, service credentials, certificates, and access approvals all become part of pipeline governance, which means identity controls need to operate at build time, deploy time, and runtime rather than only after release.
Key questions
Q: What breaks when security is added too late in a DevSecOps pipeline?
A: When security is added after development work is mostly complete, teams usually find secrets exposure, privilege issues, and configuration errors only at release time. That delay turns simple fixes into expensive production problems. The pipeline also accumulates trust debt because credentials, certificates, and dependencies remain active longer than intended.
Q: Why do CI/CD secrets create more risk than many teams expect?
A: CI/CD secrets often have broad blast radius because they can authenticate to source control, cloud platforms, package registries, and deployment systems. If those secrets are long-lived or reused across repositories, one exposure can open several downstream paths. The risk is highest when secrets are stored in workflow contexts where third-party code can read them.
Q: How can organisations tell whether DevSecOps controls are actually working?
A: Look for fewer late-stage exceptions, faster remediation of found issues, and clear ownership for secrets, certificates, and pipeline permissions. If the team still depends on manual approvals or emergency fixes before deployment, security is still reactive. Effective DevSecOps produces traceable controls that keep pace with release frequency.
Q: Should IAM and PKI teams own part of DevSecOps governance?
A: Yes. If pipelines issue service credentials, certificates, or trust policies, IAM and PKI teams already influence delivery risk. Their role is to define ownership, rotation, issuance, and revocation rules that engineering can execute automatically, so identity controls remain aligned with deployment frequency.
Technical breakdown
Why late-stage security fails in CI/CD pipelines
Traditional DevOps optimises for speed, automation, and fast feedback loops, but security reviews that happen only near release create a structural delay. By then, the code path, deployment logic, and related credentials have often already been propagated through build stages, test environments, and artifact stores. That means vulnerabilities and misconfigurations are discovered when remediation is more expensive and more disruptive. In identity terms, the same delay lets secrets, service accounts, and certificates remain usable longer than intended, which expands the attack window. The control problem is not a lack of scanning alone. It is the mismatch between where risk enters the pipeline and where security is actually enforced.
Practical implication: Shift scanning, policy checks, and identity controls into the earliest pipeline stages where exposure first appears.
How DevSecOps changes secrets and certificate governance
DevSecOps treats secrets management and PKI as delivery concerns, not just infrastructure concerns. Secrets detection catches hard-coded credentials before they are committed, while automated certificate issuance, renewal, and revocation reduce manual handling errors across containers, APIs, and signed artifacts. This is especially important where service identities are machine-owned and short-lived, because human-operated ticketing cannot keep pace with deployment frequency. ACME-style automation helps maintain trusted communication without slowing the pipeline, but only if inventory, ownership, and revocation paths are tied to the same lifecycle. The technical issue is governance of identity material, not just encryption.
Practical implication: Automate secret discovery and certificate lifecycle events wherever CI/CD creates or consumes machine identity material.
Where infrastructure as code becomes a security control
Infrastructure as code is only as safe as the policies embedded in it. When teams codify security baselines for network access, permissions, encryption, logging, and deployment rules, they turn repeatable configuration into repeatable control. That is why DevSecOps works best when security requirements are versioned alongside application code and infrastructure templates. It also reduces drift between environments, which is a common source of misconfiguration and accidental overexposure. For identity teams, this is where access policy, service account configuration, and certificate trust settings can be enforced before deployment rather than patched afterwards.
Practical implication: Use policy-as-code to make access, secret, and certificate rules part of every deployment definition.
Threat narrative
Attacker objective: The objective is to reuse delivery-time trust material to reach production systems, steal data, or manipulate the software supply chain.
- Entry occurs when hard-coded secrets, weak pipeline permissions, or insecure configuration are introduced into the CI/CD process before code is released.
- Credential access follows when those secrets, service identities, or certificates are discovered and reused outside their intended scope.
- Impact appears when vulnerable code, misconfigured infrastructure, or exposed delivery credentials reach production and create breach or supply-chain risk.
Breaches seen in the wild
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
DevSecOps is increasingly an identity-governance problem, not just an application-security model. Once pipelines issue secrets, certificates, and service credentials at machine speed, IAM and PKI controls become part of delivery governance. That changes the operating assumption from "secure code later" to "controlled identity material now". Practitioners should treat the pipeline as a governed identity environment, not a passive transport layer.
Pipeline speed without policy enforcement creates secret persistence risk. The article points to the same failure mode repeatedly: security appears after the point where secrets and configuration have already been replicated. That is how hard-coded credentials, weak cloud permissions, and unmanaged certificates become durable exposure rather than short-lived implementation mistakes. The practical conclusion is that lifecycle control must exist before release, not only after incident response.
Certificate automation and secret detection are now delivery controls, not convenience features. When release cadence accelerates, manual review cannot keep up with the issuance, renewal, and revocation of machine credentials. This is where NHI governance intersects with DevSecOps: service identities, tokens, and certificates need inventory, ownership, and expiry discipline. Practitioners should align DevSecOps with identity lifecycle management or risk building scale into their exposure window.
CI/CD security debt accumulates when organisations separate engineering and governance too sharply. The article makes clear that late security review increases both cost and operational drag, which means the business case is no longer only about breach prevention. It is about whether the delivery model can absorb control checks without becoming brittle. Security leaders should frame DevSecOps as a control-design problem that spans development, operations, IAM, and PKI.
Secret leakage remains the clearest named concept here: the pipeline can only be secure if leaked credentials are assumed exploitable. That assumption changes prioritisation. Instead of relying on trust in developer discipline alone, practitioners need pipeline-wide discovery, revocation, and rotation tied to build and deploy events. The governance task is to reduce the lifespan of exposed machine secrets, not to hope they are never copied.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
Secret leakage is now a delivery-lifecycle issue, not a repository-only issue. When build pipelines handle credentials, the organisation has to assume exposure can happen in code, logs, artifacts, and deployment outputs. That means the control surface spans IAM, NHI lifecycle management, and PKI lifecycle events, not just developer education.
Teams should expect DevSecOps to shift governance from post-release review to pre-release enforcement. The practical effect is that access policy, secret rotation, and certificate renewal become pipeline events, with ownership and auditability attached to each one.
The gap is less about awareness than repeatability: security habits that depend on individual developers do not scale inside fast CI/CD systems. A governed delivery model needs automated checks, enforced policy, and clear identity ownership for every machine credential that enters the pipeline.
For practitioners
- Embed security gates in early pipeline stages Add threat modelling, policy checks, and code scanning before merge and build so defects are caught before deployment artifacts are created.
- Automate secrets discovery and revocation Scan repositories, build logs, and deployment outputs for exposed credentials, then rotate or revoke any secret that appears in the delivery path.
- Treat certificate lifecycle as CI/CD governance Use automated issuance, renewal, and revocation for certificates used by services, containers, and signed artifacts so manual handling does not become a bottleneck.
- Codify security baselines in infrastructure as code Bake encryption, access control, logging, and environment segregation rules into templates so every deployment inherits the same baseline.
- Train developers on secure delivery patterns Use shared workshops and review loops to make secure coding, secret handling, and pipeline hygiene part of day-to-day engineering practice.
Key takeaways
- DevSecOps changes the main control question from how fast code ships to where security checks are enforced in the delivery lifecycle.
- CI/CD pipelines create identity risk when secrets, certificates, and access rules are handled after build and deployment decisions are already in motion.
- The strongest governance model treats pipeline security as a shared responsibility across development, operations, IAM, and PKI rather than a late review step.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | CI/CD pipelines rely on managed service and developer accounts that must not carry excess standing access. |
| Recommendation — Apply CIS-5 to tighten account ownership, access review, and removal across delivery tooling. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on controlling who and what can use pipeline credentials and deployment permissions. |
| Recommendation — Use PR.AA-05 to enforce least-privilege permissions for CI/CD users, services, and automation. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets and pipeline abuse are direct credential-access and lateral-movement patterns. |
| Recommendation — Map CI/CD exposure paths to TA0006 and TA0008 to prioritize detection and containment. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article explicitly discusses secrets, certificates, and credential lifecycle management. |
| Recommendation — Apply IA-5 to govern credential issuance, rotation, and revocation in pipeline workflows. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article explicitly covers hard-coded credentials and secret detection in CI/CD pipelines. |
| Recommendation — Use NHI-02 to find, remove, and revoke secrets that leak into code, logs, or build artifacts. | ||
Key terms
- DevSecOps: A software development approach that integrates security practices, including NHI governance, secrets scanning, and secure credential handling, throughout the CI/CD pipeline rather than treating security as a post-deployment activity.
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
- Public Key Infrastructure: Public Key Infrastructure is the trust system that issues, manages, and revokes digital certificates used to prove identity. In practice it binds keys to entities and policies, making authentication, encryption, and non-repudiation possible across users, devices, and services.
- Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the delivery and access patterns that modern pipelines now depend on.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org