Topic starter
11/07/2026 8:45 pm
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.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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