Notifications
Clear all
Topic starter
17/08/2026 4:39 pm
TL;DR: Developer-first secrets management reduces friction across Git, CI/CD, containers, and local development, but Akeyless’s analysis also shows how easily secrets still spread across toolchains when access, injection, and lifecycle controls are not tightly governed. The real challenge is not convenience but whether runtime access, versioning, and revocation are enforced consistently enough to limit blast radius and prevent hardcoded exposure.
NHIMG editorial — based on content published by Akeyless: developer-first secrets management for modern engineering workflows
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams handle exposed secrets in modern software pipelines?
A: Treat exposed secrets as identity incidents, not just code defects.
Q: Why do hardcoded secrets remain such a serious risk in modern DevOps?
A: Because one exposed credential can be copied into multiple systems and reused long after the original leak.
Q: What breaks when secrets management is separated from identity governance?
A: When secrets management is separated from identity governance, credentials can outlive approvals, regions, or vendor relationships.
Practitioner guidance
- Inventory every secret-bearing workflow Trace credentials from local development through Git, CI/CD, containers, and IaC so each path has an owner, rotation rule, and revocation trigger.
- Replace hardcoded credentials with runtime delivery Move secrets out of source code and disk, then inject them only at execution time with short TTLs and strict runtime boundaries.
- Align secrets policy with identity lifecycle Tie secret issuance and revocation to joiner-mover-leaver processes so onboarding, role changes, and offboarding remove access from the same control plane.
What's in the full article
Akeyless's full article covers the implementation detail this post intentionally leaves for the source:
- CLI, SDK, and REST API workflow details for pulling secrets during builds and runtime jobs
- GitOps and IaC configuration patterns for Terraform, Helm, ArgoCD, and Kubernetes
- CI/CD integration steps for GitHub Actions, GitLab CI, Jenkins, and CircleCI
- Local development handling for .env files, environment variables, and identity provider authentication
👉 Read Akeyless's article on developer-first secrets management for modern toolchains →
Developer-first secrets management: where do trust gaps remain?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:45 pm
Developer-first secrets management is really lifecycle governance for non-human identities. Once a credential enters a pipeline, container, or local development workflow, it behaves like any other NHI and needs issuance, access, rotation, and revocation rules that survive engineering speed. The mistake is treating developer convenience as separate from identity governance. Practitioners should manage these secrets as governed identities, not as disposable implementation details.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: How do organisations know if secrets management is actually working?
A: Secrets management is working only when credentials are absent from endpoints, build logs, environment variables, and source-controlled configuration. If secret scanners still find high-value tokens in routine developer paths, the control is not operating as designed, regardless of policy statements or vault adoption.
👉 Read our full editorial: Developer-first secrets management still leaves trust gaps
