Supply-chain credential harvesting is the theft of login secrets from software suppliers, build systems, or third-party services so attackers can move into downstream environments. In practice, adversaries target service accounts, API keys, tokens, and certificates embedded in pipelines, dependencies, updates, or integrations, then reuse them to access trusted systems.
What Supply-Chain Credential Harvesting Looks Like
Supply-chain credential harvesting is most dangerous because the stolen secret often belongs to a trusted supplier, build pipeline, or integration point. That trust lets attackers bypass normal perimeter checks and appear to be a legitimate upstream dependency or automation workflow.
The practical issue is not only theft, but reuse. Once a service account, API key, token, or certificate is exposed inside a supplier environment, the attacker can pivot into customer systems that would otherwise treat that upstream actor as trusted.
Where Credentials Get Harvested in the Supply Chain
These incidents usually begin where secrets are created, copied, cached, or logged. Common targets include CI/CD runners, package registries, developer tools, build images, deployment scripts, support portals, SaaS integrations, and source code repositories.
Attackers favour locations where credentials accumulate over time. A single leaked token can open access to multiple systems if it is reused across environments, stored in environment variables, or embedded in automation that reaches production.
For concrete examples of how upstream compromise turns into downstream exposure, see Miasma and Hades Supply Chain Worms, Code Formatting Tools Credential Leaks, and tj-actions/changed-files compromise 2025.
Why This Trust Model Is So Dangerous
Supply-chain credential harvesting is effective because defenders often trust upstream identities more than endpoints. If the supplier account, plugin, package, or workflow is already authorised, the attacker inherits that trust and can move laterally with less friction than in a direct intrusion.
The blast radius can be wide because one harvested secret may unlock signing, publishing, support, storage, or administrative access. In the worst case, attackers use the trusted path to tamper with software distribution, exfiltrate customer data, or stage further compromise inside downstream environments.
Related incidents show the range of outcomes, from PyPI secrets exposure 2023 and CircleCI breach 2023 to BeyondTrust breach 2024 and Sisense breach 2024.
How Organisations Reduce Exposure and Recover
Exposure checks should start with inventory: which suppliers, build services, and integrations hold secrets, which systems those secrets can reach, and whether any of them are overprivileged or long-lived. Vendor advisories and trusted build provenance become especially important when a credential might be embedded in a package, plugin, or automation path.
If abuse is suspected, organisations should assume that any exposed secret may already be copied and should review logs, pipeline history, release artefacts, and downstream access trails. Rotation alone is not enough if the attacker has already used the credential to create persistence or extract additional secrets.
For defensive context on build integrity and supply-chain controls, useful references include NIST SSDF (SP 800-218), SLSA, and OpenSSF.
Risk and Threat Considerations
When credentials are harvested upstream, the main risk is trust transference: downstream systems may treat the stolen secret as legitimate even after the original compromise is discovered. That creates a hidden access path that can outlast the initial incident and spread into multiple customer environments.
Failure mechanism: Secrets are captured from supplier tooling, build steps, or third-party integrations, then reused before they are revoked or detected. Because the credential originates from a trusted party, normal access controls may not flag the activity until after data exposure or tampering has occurred.
Impact: Attackers can impersonate trusted automation, reach protected systems, exfiltrate data, poison releases, or pivot into customer environments through a path that looks operationally normal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Defines build provenance and artifact integrity for software supply chains. |
| Recommendation — Verify build provenance and signing before trusting released artifacts or pipeline outputs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are central when stolen secrets are reused across suppliers. |
| AC-6 — Least Privilege | Excessive supplier and automation permissions increase blast radius after secret theft. | |
| Recommendation — Rotate compromised authenticators and revoke exposed secrets as soon as abuse is suspected. Reduce supplier and automation access to the minimum permissions needed for each workflow. | ||
| MITRE ATT&CK | Credential Access | Credential theft and reuse are the core adversary behaviours in this attack pattern. |
| Recommendation — Map observed theft and reuse activity to credential-access techniques in detection and hunting. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The term centers on leaked secrets from upstream systems and integrations. |
| Recommendation — Eliminate exposed secrets from code, pipelines, logs, and integrated services. | ||
Practitioner Guidance
Why practitioners should care: Treat upstream secrets as high-value attack surface, not as implementation detail. The security question is not just whether the supplier is trusted, but whether its credentials can be abused to reach your environment without friction.
What to watch for: Long-lived tokens, shared credentials, broad-scoped service accounts, and secrets that appear in logs, build artefacts, or developer tools deserve priority review because they create durable reuse opportunities for attackers.
Practitioner takeaway: The safest supply chain is one where trusted integrations have narrowly scoped, short-lived credentials and where compromise can be invalidated quickly without guessing where the secret was copied.
Related resources from NHI Mgmt Group
- Why do credential-harvesting supply chain attacks create so much downstream risk?
- When does a leaked machine credential become a supply-chain risk?
- Who is accountable when a supply-chain breach persists because an NHI credential survived rotation?
- Why do incomplete credential rotations keep supply chain incidents alive?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org