Notifications
Clear all
Topic starter
14/05/2026 6:57 pm
TL;DR: OWASP AppSec Days France 2026 in Paris puts hardcoded secrets, leaked credentials, and source code attack paths back in focus for AppSec and IAM teams, according to GitGuardian. The security problem is not discovery alone but governing secrets across developer workflows, CI/CD, and AI-generated code before exposure becomes routine.
NHIMG editorial — here’s why we think this discussion matters
Questions worth separating out
Q: How should security teams handle leaked secrets across developer workflows?
A: Treat every leaked secret as an identity incident, not just a code hygiene issue.
Q: When do AI-generated code and assistants increase secret exposure risk?
A: Risk rises when AI-generated output is allowed to write credentials, copy insecure patterns, or bypass review in pipelines.
Q: What is the difference between secret scanning and secret governance?
A: Secret scanning finds leaked credentials.
Practitioner guidance
- Expand secret scanning to every developer touchpoint Scan local commits, pull requests, CI logs, artifact stores, and generated code output, not only primary repositories.
- Tie secret discovery to mandatory revocation workflows When a secret is found, require revocation or rotation within a defined service-level window and record the business owner for the affected credential.
- Classify AI-generated code as a secret-risk source Review prompts, outputs, and code assistants for patterns that propagate credentials, hidden tokens, or insecure access handling.
With 6 distinct secrets manager instances already common in the environment, fragmentation itself becomes a governance risk because no single control plane sees the full credential lifecycle?
👉 Read GitGuardian's event listing for OWASP AppSec Days France 2026 →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/05/2026 6:58 pm
A few things worth adding from our research at NHI Mgmt Group.
Secrets governance is now a developer-identity problem, not just a vaulting problem. The article reinforces a pattern we see repeatedly: credentials leak where developers work, then persist because remediation is treated as a downstream task. That shifts the control objective from storage to lifecycle governance. Practitioners should treat every exposed secret as an unmanaged non-human identity until rotation, revocation, and scope review are complete.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations say they are confident in their secrets management capabilities.
A question worth separating out:
Q: Why do secrets in source code create NHI governance problems?
A: Because a secret is a non-human identity with permissions, scope, and lifetime, and code repositories replicate it faster than teams can manually track it. Once exposed, the credential can be copied into builds, logs, and forks. That makes access control, rotation, and ownership central to the response.
👉 Read our full editorial: OWASP AppSec Days France 2026 and appsec secrets governance
