Topic starter
11/07/2026 8:45 pm
TL;DR: DevSecOps fails when security stays late in the pipeline, because vulnerabilities, secret leakage, and certificate risks are found after delivery has already moved on, GlobalSign says. CI/CD governance has to bring secrets and certificate controls into the workflow before code and credentials advance.
Editorial analysis by NHI Mgmt Group, based on content published by GlobalSign: “DevOps vs. DevSecOps: Cuál es la Diferencia y Por Qué la Seguridad No Puede Esperar”.
By the numbers:
- 60% of respondents consider the DevSecOps transition technically challenging, according to Gartner research cited by GlobalSign.
Key questions
Q: Why do CI/CD secrets and certificates need identity governance?
A: Because they are machine credentials that authenticate services, deployments, and software trust.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Glossary terms: DevSecOps, CI/CD Pipeline, PKI Lifecycle Automation, Secrets Management
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 hours ago by NHI Mgmt Group
11/07/2026 9:11 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: DevSecOps shifts security left in CI/CD and PKI governance