What breaks when supply chain attacks can steal secrets as well as publish malware?

Why This Matters for Security Teams

Supply chain compromise is no longer just a software integrity problem. When a malicious package, build step, or dependency can also expose secrets, the blast radius shifts from one bad release to persistent access across source control, cloud, and CI/CD. Security teams need to treat packages, pipelines, and developer workstations as identity-bearing assets, because stolen tokens and credentials can outlast the malware itself. Guidance from MITRE ATT&CK Enterprise Matrix helps teams separate initial delivery from post-compromise activity, which is critical when the attacker’s real objective is credential theft.

The practical failure is assuming that removing the malicious artifact ends the incident. In reality, package publishing access, build secrets, signing keys, and cloud tokens can be reused to poison releases, tamper with automation, or impersonate trusted maintainers. That is why incident handling must expand beyond malware removal to include secret inventory, token revocation, and integrity checks on release pipelines. For teams managing non-human identities, this is the point where software supply chain risk becomes NHI governance risk, because machine credentials are often the easiest durable foothold. In practice, many security teams discover the access path only after the attacker has already reused stolen secrets to reach trusted internal systems.

How It Works in Practice

Modern supply chain attacks often blend code execution with credential harvesting. A compromised dependency can run during install, a build plugin can read environment variables, or a maintainer account can publish a clean-looking update after stealing signing or package registry tokens. Once those secrets are exposed, the attacker may not need the malware at all. They can authenticate as a trusted automation identity, alter releases, access artifact repositories, or pivot into cloud services. Current guidance from OWASP Non-Human Identity Top 10 is especially relevant here because CI jobs, bots, and service accounts are often over-privileged and under-monitored.

Operationally, the response should separate artifact removal from access containment:

• Revoke exposed secrets, then rotate all dependent credentials and signing material.
• Invalidate package registry tokens, CI runners, deploy keys, and cloud access keys.
• Review recent publishes, build logs, and provenance records for tampering.
• Compare suspicious activity with known adversary patterns using CISA cyber threat advisories and ATT&CK techniques.
• Contain release channels until artifact integrity, provenance, and signer trust are re-established.

Controls such as short-lived credentials, secrets scanning, workload identity, and signed builds reduce exposure, but they only work when the pipeline architecture prevents long-lived static tokens from being reused silently. These controls tend to break down when legacy CI systems share broad deployment keys across many repositories because a single leak can persist across multiple release paths.

Common Variations and Edge Cases

Tighter release and secrets controls often increase operational overhead, requiring organisations to balance delivery speed against containment and auditability. That tradeoff becomes sharper in open-source ecosystems, multi-tenant CI platforms, and fast-moving DevSecOps environments where ephemeral credentials are difficult to standardise. There is no universal standard for this yet, but the current guidance suggests that provenance, token scope, and automated revocation matter more than trying to manually inspect every package event.

Edge cases matter. A malicious package used only in test may still leak environment variables that later unlock production access. A stolen maintainer token may be more dangerous than the malware because it allows legitimate-looking publishes after the initial compromise has been removed. Agentic systems add another layer: if build or remediation agents have tool access, compromised secrets can be used to instruct automation to approve, deploy, or suppress alerts. This is where the overlap with Anthropic research on AI-enabled intrusion tradecraft and the MITRE ATLAS adversarial AI threat matrix becomes relevant, because identity misuse increasingly extends into AI-assisted operations. Best practice is evolving, but the safe default is to assume stolen secrets remain actionable until every dependent trust path has been explicitly cut.

Related resources from NHI Mgmt Group

• Why do supply chain worms create a secrets management problem as well as a malware problem?
• Why do CI/CD secrets create such a large blast radius in supply chain attacks?
• What breaks when secrets are exposed in a software supply chain incident?
• Why are wallets, tokens, and mnemonic phrases high-risk secrets in supply chain attacks?