Topic starter
11/07/2026 8:37 pm
TL;DR: DevSecOps moves security checks into planning, build, and deployment so pipeline issues surface before production, according to GlobalSign. CI/CD governance works best when secrets, certificates, and permissions are controlled before release pressure hardens mistakes into risk.
Editorial analysis by NHI Mgmt Group, based on content published by GlobalSign: “DevOps vs. DevSecOps: Worin der Unterschied liegt und warum Sicherheit nicht warten kann”.
By the numbers:
- 60% of respondents said implementing DevSecOps is technically challenging, according to a Gartner survey cited by GlobalSign.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: DevSecOps changes the main control question from how fast code ships to where security checks are enforced in the delivery lifecycle.
Glossary terms: DevSecOps, Secrets Management, Public Key Infrastructure, Policy as Code
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 53 minutes ago by NHI Mgmt Group
11/07/2026 9:03 pm
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.
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 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.
👉 Read our full editorial: DevSecOps is closing the security gap in CI/CD pipelines