OWASP NHI2: Secret leakage and the four checks after discovery

Revised October 4, 2026. An earlier version listed incidents without source links, treated possible outcomes as inevitable, and described coverage beyond the connected sources. This guide separates an exposed secret from an active credential, an access path, and evidence of misuse.

What OWASP NHI2 means

OWASP NHI2:2025 describes machine credentials such as API keys, access keys, database passwords, and tokens leaking into places that should not hold them. Source files, configuration, logs, chat, and SaaS documents can each become an exposure location. An NHI is the workload or account using access; the secret is one way it authenticates. Finding a string does not by itself establish that the credential still works or that someone used it.

The first four questions after a finding

1. Where was it found? Save the exact source, access setting, and earliest supported exposure time. A private repository with broad team access and a public paste have different audiences. Check copies and history within the systems you can inspect; do not assume one scan covers every store.

2. Does it still work? Use the issuing service or a supported safe validation method. Record the check time and result. “Unknown” is a real state when a type cannot be checked. GitHub documents that validity checks apply to supported patterns and configurations; a pattern match alone is not an active-key verdict.

3. What access does it grant? At the issuer, identify the principal, scopes or policies, expiry, and resources. A live key may have narrow access; an inactive key may still require investigation of earlier use. Exposure, privilege, and misuse are separate findings.

4. Who can act? Confirm the application owner and a responder. A commit author or document editor is a lead, not necessarily the current owner. Note dependencies before replacement so the owner can change the key without leaving an application broken.

Containment and prevention

For a potentially active exposed credential, coordinate promptly with its issuer and service owner. Revoke or rotate at the issuer, verify that the old value fails, update dependent workloads, and review available issuer logs for unexpected use. Absence of a log event is limited by the logs collected and retained. Remove exposed copies and address the route that put the secret there. GitHub advises revocation or rotation before any repository-history rewrite; rewriting has operational side effects and cannot erase other people’s copies.

For new integrations, prefer short-lived credentials where the issuer supports them, keep secrets in a dedicated manager, limit their scope, and scan the repositories and other stores your team actually uses. These are the prevention measures OWASP lists for NHI2. They reduce exposure risk but do not prove that every secret is found.

How Cremit helps investigate

Cremit searches supported connected code repositories, GitHub Packages, S3, Google Drive, Slack, Jira, Confluence, and Notion for credential exposures. Supported credential types can be checked with their issuers; other types need manual review. AWS access keys and GCP API keys can receive permission context when configured. A team can assign and track a finding. Cremit does not inspect every possible store, prove attacker use, monitor every API call, or revoke and rotate the credential for the issuer. Confirm the source, issuer, owner, and response separately.

Related Cremit guides

OWASP NHI1: Offboard machine access without breaking a service

OWASP NHI Top 10: what to check for each machine identity risk

Primary sources

OWASP — NHI2:2025 Secret Leakage

GitHub Docs — Evaluating secret scanning alerts

GitHub Docs — Removing sensitive data from a repository