Notifications
Clear all
Topic starter
11/07/2026 8:37 pm
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.
NHIMG editorial — based on content published by GlobalSign: DevSecOps and the role of PKI in secure software delivery
By the numbers:
- 60% of the respondents said implementing DevSecOps was technically challenging.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
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.
Q: Why do CI/CD pipelines create non-human identity risk?
A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically.
Q: How do security teams know if SoD controls are actually working?
A: SoD controls are working only if live access state matches the approved separation model across systems.
Practitioner guidance
- Implement security gates before merge and before deploy Require code scanning, dependency scanning, secrets detection, and policy checks to pass before changes can move from pull request to deployment.
- Inventory every pipeline identity and secret Catalogue service accounts, API keys, tokens, certificates, and signing keys used by build and release systems.
- Automate certificate lifecycle management Use automated issuance, renewal, and revocation for application and service certificates so expiry does not become an operational incident.
What's in the full article
GlobalSign's full article covers the operational detail this post intentionally leaves for the source:
- Practical DevSecOps implementation guidance for teams moving from manual review to automated pipeline controls.
- PKI automation considerations for certificate issuance, renewal, and revocation inside CI/CD environments.
- Secrets scanning and secret-detection workflow details that go beyond the governance framing in this analysis.
- Cultural and organisational change points for getting development, operations, and security teams aligned.
👉 Read GlobalSign's analysis of DevSecOps, PKI, and CI/CD security →
DevSecOps and CI/CD security: what IAM and PKI teams need now?
Explore further
11/07/2026 9:03 pm
DevSecOps is now an identity governance problem as much as a development model. Once pipelines create, store, and consume service credentials, the delivery system itself becomes a machine identity environment. That means access scope, secret sprawl, and certificate lifecycle are no longer secondary concerns. The useful concept here is pipeline trust debt: each exception, manual override, or hard-coded credential adds future exposure that later remediation cannot fully remove. Practitioners should treat the pipeline as an identity-bearing control surface, not just a build system.
A question worth separating out:
Q: What frameworks help teams govern secrets and workload credentials?
A: OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework are both relevant because they connect credential lifecycle, access control, and operational governance. For teams managing distributed vaults, the key is to align rotation with ownership, inventory, and revocation rather than treating it as an isolated maintenance task.
👉 Read our full editorial: DevSecOps is closing the security gap in CI/CD pipelines
