TL;DR: DevSecOps shifts security into planning, design, and CI/CD execution so teams can catch vulnerabilities, secret leakage, and certificate risks earlier, according to GlobalSign, while Gartner is cited as finding that 60% of respondents see the transition as technically challenging. Security only works when it is embedded into delivery mechanics, because delayed controls turn speed into exposure.
At a glance
What this is: This is a DevSecOps explainer that argues security must move into CI/CD and PKI governance early to reduce exposure from vulnerabilities, leaked secrets, and certificate handling.
Why it matters: It matters because application delivery, secrets management, and certificate governance increasingly intersect with IAM and NHI controls, so security teams need to shift from end-stage review to embedded control.
By the numbers:
- 60% of respondents consider the DevSecOps transition technically challenging, according to Gartner research cited by GlobalSign.
Context
DevSecOps is the practice of building security checks into the software delivery lifecycle instead of treating security as a late-stage gate. In this article, the governance gap is familiar: fast CI/CD pipelines can amplify risk when vulnerabilities, secrets, certificate handling, and access controls are not managed as part of the workflow.
For identity and access teams, the important intersection is not just code quality. CI/CD systems, PKI automation, and secrets handling all depend on governed credentials, service accounts, and machine trust, which makes this a practical NHI and IAM topic as much as a software delivery topic.
Key questions
Q: What breaks when security is added only at the end of the pipeline?
A: Teams find issues after code, infrastructure, and approvals have already moved forward, so remediation becomes slower and more expensive. That pattern also creates audit gaps, because evidence is assembled retroactively instead of generated by the workflow itself. Late-stage security turns into a queue rather than a control system.
Q: Why do CI/CD secrets and certificates need identity governance?
A: Because they are machine credentials that authenticate services, deployments, and software trust. If those credentials are not inventoried, scoped, rotated, and revoked like other identities, they become standing access paths inside the delivery system. Identity governance has to cover non-human authentication material, not only employee accounts.
Q: What are the signs that secrets management is failing in a DevSecOps environment?
A: Common signs include developers storing access keys on local machines, secrets appearing in source repositories, insufficient monitoring of non-production environments, and weak visibility into developer activity. Another warning sign is assuming production controls automatically cover DevOps tooling. When teams cannot locate where secrets live or how they are used, governance is already incomplete.
Q: Should teams prioritise secret scanning or certificate automation first?
A: Start with the control that addresses the highest likelihood of immediate abuse. If exposed credentials are already appearing in code or logs, secret scanning and removal come first. If service-to-service trust is already dependent on manual certificate handling, automation and lifecycle governance should move up the list immediately.
Technical breakdown
How CI/CD turns into an exposure path when security is bolted on late
Traditional DevOps optimises for speed, automation, and collaboration, but that same compression of delivery time leaves little room for late security review. When scanning, policy checks, and access validation happen after code is effectively ready to ship, teams are forced to choose between shipping fast and fixing issues slowly. The result is not just technical debt but an exposure pipeline: weak code, misconfigurations, and leaked credentials can move into production before they are governed. DevSecOps changes the timing of control enforcement, not just the tooling stack.
Practical implication: move security checks into the build and merge flow, not the release gate.
Why secrets and certificate governance are part of identity security
The article links DevSecOps to secret detection and automated certificate management because delivery pipelines handle machine credentials continuously. Secrets include API keys, tokens, certificates, and other non-human authentication material that can be abused if exposed or left ungoverned. PKI automation matters because certificates authenticate services, protect data in transit, and support software integrity, but manual renewal and revocation do not scale inside modern release cycles. This is where NHI governance and IAM intersect with DevSecOps: the pipeline itself becomes a credential-consuming system that must be inventoried, scoped, and rotated.
Practical implication: treat CI/CD credentials and certificates as governed NHIs with lifecycle controls.
How shift-left security changes remediation economics
The article’s core operational claim is that fixing security issues earlier is cheaper and less disruptive than correcting them after deployment. That is not just a development efficiency argument; it is a governance argument about control timing. Threat modelling during design, security criteria in user stories, automated scans, and policy-as-code all reduce the chance that unsafe changes survive long enough to become expensive incidents. For identity practitioners, this matters because the same logic applies to service accounts, deployment identities, and certificate lifecycles. The earlier a trust decision is made, the more durable its control boundary must be.
Practical implication: align control points to the earliest decision that creates trust, privilege, or release authority.
Threat narrative
Attacker objective: The attacker seeks to turn delivery trust into production access by abusing weak pipeline controls, exposed credentials, or unmanaged certificates.
- Entry occurs when insecure code, misconfigurations, or exposed secrets move through CI/CD without being caught during development or build validation.
- Credential abuse follows when hardcoded secrets or unmanaged certificate material provide machine access to services, APIs, or deployment paths.
- Impact occurs when those weaknesses reach production, where they can enable breach activity, supply chain compromise, or service disruption.
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.
- 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 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shift-left security is now a governance problem, not just a developer workflow problem. The article correctly frames DevSecOps as a cultural and technical change, but the deeper issue is control timing. If security is evaluated only after code is functionally complete, the organisation has already accepted too much risk into the delivery system. Practitioner conclusion: governance has to move into planning, build, and release authorization.
CI/CD systems are identity systems because they issue, consume, and depend on machine trust. Pipelines rely on service accounts, secrets, tokens, and certificates to move code and artifacts. That makes them part of the NHI estate whether teams model them that way or not. Practitioner conclusion: include build runners, deployment agents, and certificate automation in identity inventory and access review scope.
PKI automation is the control boundary that stops certificate management from becoming release friction. Manual issuance and renewal do not survive modern deployment cadence, and late renewal is a trust failure, not just an operations inconvenience. Practitioner conclusion: treat certificate lifecycle as a governed machine identity workflow with ownership, expiry oversight, and revocation discipline.
DevSecOps exposes a familiar problem: delivery speed often outruns assurance maturity. The Gartner figure cited in the article shows the transition is technically difficult for many organisations, which is consistent with what we see in security programmes that treat tooling adoption as the finish line. Practitioner conclusion: measure whether security checks are actually changing release decisions, not just adding dashboard noise.
Cloud-native release pipelines create secret leakage and overprivileged automation risks that OWASP-NHI already names explicitly. The strongest conceptual frame here is not generic AppSec, but NHI governance over non-human credentials in build and deployment paths. Practitioner conclusion: model pipeline credentials as first-class identities and apply lifecycle control, not ad hoc exception handling.
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
CI/CD governance is becoming identity governance. The article’s strongest implication is that build and release automation must be treated as part of the NHI estate, because the pipelines themselves rely on secrets, certificates, and delegated machine access. That shifts control ownership from only AppSec and DevOps into IAM and PAM territory as well.
Pipeline secrets are the new standing access problem. When credentials live in repositories, build variables, or deployment scripts, the organisation has created a durable exposure path that can outlast the code change itself. The operational answer is to govern issuance, rotation, and revocation at the point where the pipeline consumes the credential, not after the fact.
Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec. That gap explains why shift-left programmes fail when they stop at awareness and do not hardwire controls into the delivery path.
For practitioners
- Embed security criteria into design and user stories Define security acceptance criteria alongside functional requirements so threats, access assumptions, and certificate handling are addressed before implementation begins.
- Automate secret detection in the build path Scan repositories, build logs, and pipeline variables for hardcoded API keys, tokens, and certificates before code is promoted.
- Classify CI/CD credentials as NHI assets Inventory service accounts, tokens, and signing certificates used by pipeline automation, then assign ownership and expiry controls to each one.
- Automate certificate issuance and revocation Use PKI automation to remove manual renewal and revocation steps from release workflows so certificates do not become release bottlenecks.
- Run threat modelling before merge approval Review deployment paths, trust boundaries, and privileged automation before code is merged so risky changes are intercepted while they are still cheap to fix.
Key takeaways
- DevSecOps fails when security remains a late-stage review, because the pipeline has already accepted risk by the time vulnerabilities or secret leaks are discovered.
- The article ties CI/CD governance to secrets and certificates, which makes machine identity control part of delivery security rather than a separate operational concern.
- The practical move is to embed threat modelling, automated scanning, and PKI lifecycle control into the workflow where code and credentials are first handled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article explicitly discusses secret detection in CI/CD pipelines and exposed credentials. |
| NHI-07 — Long-Lived Secrets | The article’s automation advice targets credentials and certificates that persist across releases. | |
| Recommendation — Scan pipeline repositories and logs for leaked secrets and remove exposed credentials immediately. Replace long-lived pipeline credentials with short-lived, governed secrets wherever release flow permits. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is central to the pipeline and PKI controls discussed here. |
| Recommendation — Apply IA-5 to rotate, protect, and revoke pipeline authenticators on a defined lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CI/CD automation depends on tightly scoped machine access and release permissions. |
| Recommendation — Limit pipeline and deployment permissions to the minimum entitlements required for each release path. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern described is credential exposure leading to deeper access through delivery systems. |
| Recommendation — Map exposed pipeline secrets to TA0006 and TA0008 to prioritise detection and containment. | ||
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.
- CI/CD Pipeline: The automated systems that build, test, and deploy software, often holding privileged credentials for source control, cloud access, and release automation. When these pipelines leak secrets, they can turn a software delivery function into a high-trust compromise path.
- PKI Lifecycle Automation: PKI lifecycle automation is the process of issuing, renewing, reissuing, deploying, and retiring certificates through policy-driven workflows rather than manual handling. It reduces expiry risk and operational drift, but only if the automation is governed so that credentials are not exposed inside the process.
- 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.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to the delivery systems their programmes depend on.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org