Secret Harvesting

Expanded Definition

secret harvesting is not the same as password cracking or token theft from a login page. It is the recovery of credentials, API keys, certificates, or session material from places an execution environment already trusts, such as source trees, build logs, memory, temp files, or environment variables. In NHI operations, that distinction matters because the attacker is often bypassing authentication entirely and targeting the hidden operational layer that powers service accounts, automation, and Agent workflows.

Definitions vary across vendors when the theft occurs inside CI/CD, container, or endpoint telemetry, but the practical risk is consistent: once a secret is present in a runtime context, it can often be copied faster than defenders can rotate it. The issue is central to the OWASP Non-Human Identity Top 10, especially where secret exposure overlaps with poor rotation, over-privileged accounts, and weak lifecycle controls.

The most common misapplication is treating secret harvesting as a generic data loss problem, which occurs when teams miss that the attacker’s real target is valid NHI access rather than the secret value alone.

Examples and Use Cases

Implementing protection against secret harvesting rigorously often introduces friction in developer workflows, requiring organisations to weigh operational speed against tighter inspection, shorter-lived credentials, and more aggressive redaction.

• A CI job prints an environment variable containing a cloud access key, and the key is harvested from logs before the pipeline owner notices.
• A developer commits a configuration file with embedded tokens, then an attacker scrapes the repository and reuses the secret for lateral access, a pattern discussed in NHIMG’s Guide to the Secret Sprawl Challenge.
• A build container mounts credentials for package publishing, but a supply chain compromise extracts them during execution, similar to the Reviewdog GitHub Action supply chain attack.
• A workload retrieves an API key from memory, yet a malicious process reads process memory or debug output and reuses the token before it expires.
• A mobile or serverless app stores a long-lived certificate in local configuration, creating a high-value target when the runtime is exposed to insiders or injected code.

These scenarios are easier to interpret when paired with broader NHI guidance from the Ultimate Guide to NHIs — Static vs Dynamic Secrets and with the OWASP Non-Human Identity Top 10, which emphasizes secret handling as a core control surface.

Why It Matters in NHI Security

Secret harvesting is dangerous because one exposed credential can unlock many downstream systems, especially where the same token is reused across environments, pipelines, or third-party integrations. NHI Mgmt Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools, and 79% have experienced secrets leaks, with 77% causing tangible damage. That combination turns a single mistake into a repeatable attack path.

For NHI governance, the operational lesson is simple: the presence of a secret in a trusted execution context should be treated as a liability, not as proof of controlled access. Attackers routinely chain harvesting with privilege escalation, persistence, and exfiltration, which is why incidents like the Shai Hulud npm malware campaign and the CI/CD pipeline exploitation case study matter to defenders who manage automation at scale. Organisations typically encounter the consequence only after a pipeline abuse, repository compromise, or workload intrusion, at which point secret harvesting becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between an identity, a credential, and a secret?
• Why is proactive secret scanning important for NHI security?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between rotating a secret and revoking access?