Honeytokens expose software supply chain intrusions before secrets fail

At a glance

What this is: This is an analysis of honeytokens as a deception-based control for software supply chain monitoring, with a key finding that they can surface intrusion attempts before attackers reach real NHI credentials.

Why it matters: For IAM and NHI practitioners, honeytokens matter because they add a signal for compromise in environments where static secret scanning and perimeter controls do not reliably show misuse.

👉 Read GitGuardian's analysis of honeytokens for software supply chain intrusion detection

Context

Software supply chain environments create a persistent NHI governance gap because service credentials, API keys, and tokens can move through source control, CI/CD pipelines, registries, and internal collaboration tools faster than teams can validate them. Honeytokens address that gap by acting as decoys, so an unexpected use becomes evidence of exposure rather than a routine access event. In practice, this is about detecting compromised non-human identities, not just finding leaked text strings.

GitGuardian’s framing places honeytokens inside the broader problem of secret sprawl: once credentials are embedded in code, logs, or configuration, the organisation may have no reliable way to know whether they were copied, replayed, or used by an attacker. That is a typical starting point for modern NHI risk, which is why the control is best understood as early warning for compromise rather than as a replacement for rotation or revocation.

Key questions

Q: How should security teams use honeytokens in software supply chains?

A: Security teams should place honeytokens where real secrets are likely to be copied, committed, or executed, then tie every callback to an incident workflow. The control works best when it sits beside rotation, revocation, and access review, because the alert proves misuse but does not contain it by itself.

Q: What is the difference between honeytokens and secret scanning?

A: Secret scanning finds exposed credentials that match known patterns, while honeytokens are decoys meant to be touched or used. Scanning tells teams where secrets may exist; honeytokens tell teams whether an exposed path is active. Both are useful, but only a decoy gives direct evidence of interaction.

Q: When do honeytokens add the most value for NHI governance?

A: Honeytokens add the most value when secrets spread across many systems and the organisation cannot reliably tell whether a leaked credential has been used. They are especially useful in CI/CD, source control, and internal tools, where a callback can confirm compromise faster than manual review.

Q: Why do honeytokens matter if a team already rotates secrets?

A: Rotation reduces the lifespan of exposed credentials, but it does not show whether an attacker has already discovered and validated them. Honeytokens fill that gap by turning access attempts into a detectable event. In a mature NHI programme, they work as an early warning layer, not a substitute for lifecycle control.

Technical breakdown

How honeytokens create a compromise signal in CI/CD and source control

A honeytoken is a deliberately fake credential, key, or marker placed where a real secret might appear. If an attacker discovers and uses it, the resulting callback proves that the surrounding system has been accessed in a way that normal application traffic should not produce. In software supply chain settings, that signal can come from a Git commit, a pipeline variable, a registry entry, or an internal document. The value is not in the decoy itself, but in the fact that only an unauthorised actor should touch it.

Practical implication: place decoys where real NHI secrets already travel, then alert on any use as a high-confidence compromise indicator.

Why honeytokens work differently from secret scanning

Secret scanning looks for known patterns of exposed credentials, while honeytokens are designed to be used and therefore detected. That difference matters because many incidents do not end at discovery of a secret in code. Attackers often wait, test access, and move laterally before defenders see impact. Honeytokens give teams a behavioural signal that a secret has crossed a trust boundary. In NHI terms, the control helps distinguish dormant exposure from active misuse, which is often the harder operational question.

Practical implication: use honeytokens alongside scanning and rotation, because detection of exposure and detection of use solve different problems.

How alert context changes incident response for NHI exposure

A good honeytoken alert should include metadata such as source system, timestamp, IP address, triggering event, and where the decoy was placed. That context turns a simple callback into incident evidence that helps teams decide whether to revoke access, invalidate related tokens, or search for lateral movement. For NHI governance, this matters because the response is usually broader than one credential. A triggered decoy often indicates that the surrounding repository, pipeline, or registry should be treated as compromised until proven otherwise.

Practical implication: predefine response steps for a triggered decoy, including revocation, triage, and scoping of adjacent NHI assets.

Threat narrative

Attacker objective: The attacker wants to turn exposed software supply chain material into access that can be reused, expanded, or hidden inside the environment.

1. Entry occurs when an attacker reaches a repository, pipeline, or internal system that contains a decoy credential or token.
2. Escalation follows when the attacker attempts to validate or use the decoy, revealing access patterns and possible surrounding trust relationships.
3. Impact is reached when the decoy callback confirms compromise and gives defenders a chance to contain adjacent secrets before real NHI abuse spreads.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Honeytokens are best understood as behavioural controls for NHI compromise, not as secret management. They do not prevent leakage, and they do not replace rotation, revocation, or access review. Their value is that they convert uncertain exposure into a measurable event, which is exactly what many NHI programmes lack when secrets are distributed across code, pipelines, and collaboration systems. Practitioners should treat them as a detection layer inside a broader identity control stack.

Decoy credentials expose the identity blast radius of modern software delivery. In a world where a single secret can be copied into multiple repositories, artifacts, and internal tools, the question is no longer whether a credential exists, but how far it has propagated. Honeytokens help teams see propagation pathologically, because a trigger often reveals where the trust boundary failed. The right response is to map every adjacent NHI asset that may share the same exposure path.

Secret scanning alone is insufficient once attackers automate validation. Attackers can search, test, and reuse exposed material faster than most manual response processes can react. A decoy that trips early is only useful if the organisation has already decided who investigates, which systems get quarantined, and how related secrets are invalidated. That makes honeytokens a governance discipline as much as a technical control.

Honeytokens sharpen the case for zero standing privilege in software delivery. If a decoy can be used at all, then the surrounding environment has already accumulated unnecessary trust. Persistent access to CI/CD, repositories, and internal tooling should be narrowed so that compromise has less room to spread. The practical conclusion is clear: reduce standing NHI access first, then use decoys to detect what remains.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For adjacent analysis, review The 52 NHI breaches Report for recurring compromise patterns that turn exposure into operational risk.

What this signals

Identity blast radius: the real problem is not whether a credential exists, but how many delivery surfaces can reuse it before a defender notices. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the pressure on NHI governance is moving from prevention to rapid detection and containment. Teams should align their response model with NIST AI Risk Management Framework principles when autonomous tooling is part of the path.

Honeytokens should be folded into a broader control stack that includes The 52 NHI breaches Report and NHI lifecycle controls for discovery, rotation, and offboarding. The practical signal for programme owners is that deception controls are most effective when they are tied to ownership, alert routing, and deterministic revocation. Without those links, decoys create visibility but not resilience.

For practitioners

• Place decoys across high-value NHI paths Deploy honeytokens in repositories, CI variables, registries, internal wikis, and messaging systems where real secrets are likely to appear. Prioritise assets that already support software delivery and coordinate placement with repository owners and SRE teams.
• Define a trigger response before rollout Map a triggered decoy to an incident playbook that includes revocation, scoping, log review, and containment of related service accounts and tokens. Make sure the SOC knows which alerts demand immediate action and which require enrichment first.
• Pair deception with secret rotation Use honeytokens to identify misuse, then rotate or revoke the adjacent secrets that may share the same exposure path. Link the workflow to your credential lifecycle process so the alert leads to measurable containment rather than just another ticket.
• Monitor CI/CD runners and internal systems closely Treat CI/CD runners, build environments, and internal collaboration tools as high-risk NHI surfaces because they often carry secrets outside primary code paths. Cross-check alerts against pipeline activity to determine whether the compromise is local or system-wide.

Key takeaways

• Honeytokens turn uncertain secret exposure into an actionable compromise signal across software delivery environments.
• The scale problem is broader than code because secrets now move through CI/CD, registries, and internal collaboration systems.
• Teams should treat decoys as part of a lifecycle control model that includes rotation, revocation, and incident playbooks.

Key terms

• Honeytoken: A honeytoken is a deliberately fake secret, credential, or marker placed in a system so that any use of it is suspicious. In NHI programmes, it functions as a deception control that converts accidental discovery into a high-confidence alert about unauthorized access or probing behaviour.
• Identity Blast Radius: Identity blast radius is the amount of damage that can spread once a non-human identity or secret is exposed. It depends on how many systems reuse the credential, how broad the permissions are, and how quickly the organisation can detect and contain misuse.
• Software Supply Chain: The software supply chain is the collection of repositories, build systems, registries, dependencies, and delivery tools that move code into production. For NHI security, it is a major trust boundary because secrets and service identities often pass through multiple systems before deployment.

What's in the full article

GitGuardian's full article covers the operational detail this post intentionally leaves for the source:

• How the Honeytoken dashboard and API are used to create and deploy decoys at scale
• What metadata appears in triggered alerts, including source context and intruder details
• How the workflow integrates with SIEM and ITSM tools through webhooks
• How GitGuardian positions honeytokens across developers, SREs, and secops teams

👉 GitGuardian's full post covers deployment workflow, alert context, and response detail

Deepen your knowledge

Honeytokens and software supply chain intrusion detection are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a response model for exposed secrets and decoy credentials, it is worth exploring.