Notifications
Clear all
Topic starter
24/06/2026 9:24 pm
TL;DR: Secrets exposure in GitHub is driven by hardcoding, accidental commits, private-to-public repo changes, and misconfigured access controls, and contextual prioritisation matters more than simple detection, according to Entro Security. The key governance issue is that exposed secrets are only manageable when teams know what access they grant, how long they remain valid, and how quickly they can be revoked.
NHIMG editorial — based on content published by Entro Security: Prioritizing risks and vulnerabilities in secrets security
By the numbers:
- 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.
Questions worth separating out
Q: How should security teams prioritise exposed secrets in GitHub and related tools?
A: Prioritise secrets by what they can access, whether they are still valid, and how widely they are trusted.
Q: Why do exposed secrets in private repositories still create major risk?
A: Private repositories are not safe by default because access can be over-broad, a team member can be compromised, or a repository can later become public.
Q: What do security teams get wrong about secrets validation?
A: Teams often treat validation as the end of the process when it is only a status check.
Practitioner guidance
- Classify exposed secrets by access scope Create a triage model that groups secrets by production reach, cross-system trust, and whether they can trigger lateral movement.
- Scan commit history and repository metadata Do not limit secret detection to the latest code state.
- Pair validation with immediate revocation Confirm whether a secret is still active, then revoke or rotate it before allowing normal operations to continue.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Detailed examples of leak vectors across source code, commit history, and repository permission changes
- The article's context-based prioritisation approach for ranking exposed secrets by criticality and business impact
- Practical discussion of validation methods, including API checks and log correlation for active credentials
- Remediation considerations for invalidating and rotating secrets without disrupting dependent services
👉 Read Entro Security's analysis of how to prioritise exposed secrets in GitHub →
Secrets sprawl in GitHub: what NHI teams need to prioritise?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:36 am
Context is the real control plane in secrets security. The article is correct that exposed secrets cannot be treated as a flat backlog. In practice, the same token can be low-risk in one system and catastrophic in another because the surrounding identity, trust chain, and workload dependencies determine the blast radius. That is why secrets governance belongs with NHI lifecycle management, not just code scanning. Practitioners should prioritise by context, not by leak count.
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 can organisations reduce the blast radius of leaked credentials?
A: Use least privilege, narrow trust boundaries, and rapid rotation for credentials that can reach production or multiple systems. Then make ownership explicit so each secret has a clear revocation path. If a leaked credential cannot be retired quickly, the blast radius remains larger than the detection capability.
👉 Read our full editorial: Prioritizing secrets risk in GitHub means fixing NHI context
