Episode 175 - GluuFederation/identerati-office-hours GitHub Wiki
Title: Secrets Leak! ... Why Do We Have Secrets?
- Host: Mike Schwartz, Founder/CEO Gluu
- Guest: Dwayne McDaniel, Developer Advocate at GitGuardian
Channels
Description
Secrets were designed for humans logging into systems. But modern software is no longer human-driven. Today, non-human identities (NHIs), such as CI/CD pipelines, cloud workloads, microservices, and now Agentic AI systems, are driving everything, but they still authenticate using long-lived credentials. But why? Let's explore how bad the issue is and what the future can look like, based on new approaches gaining steam
Homework
- GitGuardian Blog Identities Do Not Exist in a Vacuum
- The State of Secrets Sprawl 2025
- Entro Security Blog What 27 Million NHIs Taught Us About Identity Sprawl, Secret Exposure, and Shadow Access
- CyberArk 2025 State of Machine Identity Security Report
Shai Hulud articles
- Shai Hulud Attacks Persist Through GitHub Actions Vulnerabilities
- An AI Agent Just Pwned Trivy's 32K-Star Repo via GitHub Actions
Takeaways
-
⚡ Supply-chain attacks are now “secret-harvesting worms,” not one-off incidents. The Shai-Hulud virus steals credentials, exfiltrates them, reinfects the downstream infrastructure dependency graph, and has mutated to wreak havoc, like wiping Github project stars--which just serves to distract from the real objective of stealing credentials.
-
⚡ Key binding can prevent replayability, but at the expense of developer simplicity. Even if you developers use the new SPIFFIE OAuth token grant, the token would still need proof of possession to prevent replay.
-
⚡ GitGuardian increases visibility, which is essential for enterprisess to govern secrets management. Their recommended first move is inventory: scan repos, CI/CD, secret managers, and even developer machines to find usable credentials (not just high-entropy strings). Governance is defined as: desired state → current state → remediation path, measured by drift and progress, emphasizing remediation workflows rather than hard enforcement gates.
-
⚡ One of the core consistent failures is standing privilege mapped against a specific software identity. Automated decisions to grant access or share information should be driven by claims + context. Yes, software identity is needed for accountability. But the software's claims are the magic input to policy. We need to move away from identity based security ("PARC")--where the principal is the software identity, towards capability based security ("ARC"), where the identity of the software is attested by tokens (e.g. JWTs) signed by trusted issuers, and is part of the context.