TL;DR: OWASP Global AppSec EU 2026 will centre on application security topics including secrets exposure, supply chain risk, cloud-native AppSec, and the security implications of AI-generated code, according to GitGuardian’s event page. For NHI practitioners, the practical issue is not visibility alone but whether detection and remediation workflows can keep pace with developer and pipeline sprawl.
NHIMG editorial — here’s why we think this discussion matters
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 AI coding tools increase secrets risk?
A: AI coding tools increase secrets risk because they can accelerate the reuse of insecure patterns across repositories, test fixtures, and automation scripts.
Q: What is the difference between secrets scanning and secrets remediation?
A: Secrets scanning finds exposed credentials, while secrets remediation removes their value by revoking, rotating, or replacing them.
Practitioner guidance
- Map every secret to an owning identity Build an inventory that ties each credential, token, and certificate to a human owner, service owner, and revocation path.
- Extend scanning into CI/CD and AI-assisted workflows Run secret detection on pull requests, build logs, pipeline variables, and generated code paths so exposure is caught where it is introduced.
- Automate revocation and rotation playbooks Define step-by-step actions for invalidating exposed secrets across cloud, source control, and downstream services.
Teams should assume that discovery alone will not close the gap and should align secrets governance with identity lifecycle controls, review cadence, and revocation automation?
👉 Read GitGuardian’s event page for OWASP Global AppSec EU 2026 and secrets security →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
A few things worth adding from our research at NHI Mgmt Group.
Secrets sprawl is now an identity governance problem, not just a code hygiene issue. Once credentials are embedded in repositories, pipelines, or automation scripts, they behave like unmanaged NHI assets with unclear ownership and uneven revocation. That shifts the control problem from simple discovery to lifecycle governance. Practitioners should treat secret exposure as a persistent identity surface that must be inventoried, reviewed, and retired.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: When does a leaked secret become a broader IAM problem?
A: A leaked secret becomes a broader IAM problem when ownership, scope, and revocation are unclear. At that point the credential is no longer just a coding mistake. It is an unmanaged non-human identity that can persist across systems, pipelines, and cloud services.
👉 Read our full editorial: OWASP Global AppSec EU 2026 puts secrets risk back in scope