MITRE ATT&CK T1195 Supply Chain Compromise: Detecting Tampered Software and Stolen Publisher Identities

A supply chain compromise arrives through a channel you already trust, a signed update, a package your build pulls or a device from your distributor, so most preventive controls wave it straight through. MITRE ATT&CK tracks this as T1195 Supply Chain Compromise in the Initial Access tactic (TA0001), with three sub-techniques for dependencies and development tools, software supply chains and hardware. This guide covers T1195 as it stands in ATT&CK v20 (technique version 1.7), translates its detection strategies into log sources and correlation logic, and focuses on the identity that sits behind almost every recent case: the maintainer account, publishing token or build credential that let the attacker ship code. It is for detection engineers, platform and DevSecOps teams and third-party risk owners. For the programme view read the Software Supply Chain Security Guide; for response use the Supply Chain Compromise Response Playbook.

Key takeaways

• Three sub-techniques, very different defences. T1195.001 targets dependencies and developer tools, T1195.002 targets vendor software and update channels, and T1195.003 targets hardware and firmware.
• The upstream identity is the real entry point. Stolen npm and PyPI tokens, hijacked maintainer accounts and over-scoped CI tokens explain most open-source compromises since 2024; protect them as privileged credentials.
• Detect the install-to-first-run chain. ATT&CK v20 analytics look for a package or update written from an unusual source, then unexpected child processes or unsigned modules on first run, then first-time egress.
• CI/CD runners are high-value victims. Malicious dependencies and poisoned actions run with pipeline secrets in memory, so the blast radius is every token the runner holds.
• Second-order compromise is real. ATT&CK notes attackers using access from one supply chain compromise to compromise another component, so rotate downstream credentials, not just the affected package.

How T1195 works in ATT&CK v20

ATT&CK defines T1195 as manipulating products or product delivery mechanisms before the final consumer receives them. It lists manipulation of development tools, development environments, source repositories, open-source dependencies and update or distribution mechanisms, as well as infected system images, counterfeit products and shipment interdiction. Platforms in v20 are Linux, Windows, macOS and SaaS.

Groups linked to T1195 or its sub-techniques in ATT&CK v20 include APT41 (G0096), Sandworm Team (G0034), Dragonfly (G0035), Moonstone Sleet (G1036), TeamPCP (G1056) and ShinyHunters (G1057). Related techniques to chain in detection are T1199 Trusted Relationship (abuse of a supplier's access rather than its product), T1072 Software Deployment Tools and T1554 Compromise Host Software Binary.

Where identity fits

Recent cases show a consistent pattern: the attacker does not break the build, they become someone allowed to publish.

• Long-game maintainer takeover: in the XZ Utils backdoor a persona spent about two years earning release rights, then placed the payload in release tarballs and test files rather than the git source most reviewers read. Release rights are a privileged role.
• Stolen bot tokens: in the tj-actions/changed-files case (CVE-2025-30066), a stolen bot personal access token was used to push a malicious commit and repoint version tags; the payload printed runner secrets into workflow logs. More than 23,000 repositories used the action.
• Build identity to federation: after SUNBURST was delivered in signed Orion updates, the attackers stole a SAML token-signing certificate in selected victims and added credentials to existing application service principals. See the Golden SAML and Federation Trust Abuse Defence Guide.
• Worms that harvest publishing tokens: self-propagating npm malware steals the tokens of developers who install it and reuses them to publish further packages. See the Shai-Hulud npm Worm Guide. See the npm Tokens Security Guide and the PyPI API Tokens and Trusted Publishing Security Guide.

The controls that follow are identity controls: phishing-resistant MFA on registry and source accounts, trusted publishing (OIDC) in place of long-lived registry tokens, least-privilege GITHUB_TOKEN permissions, separate release approval from commit rights, and short-lived cloud credentials for runners. See the CI/CD Pipeline Identity Security Guide.

Detection logic and log sources

ATT&CK v20 maps four detection strategies: one for T1195 overall (package or update tamper, then install, then first run), one per sub-technique. The analytics share a three-step chain. The table lists the log sources ATT&CK names and how to correlate them.

Identity and pipeline signals to add

• Registry and source audit logs: new publishing tokens, tokens used from new IPs, package versions published outside the normal release workflow, and changes to maintainers or two-factor settings.
• Git tag movement: a release tag that suddenly points to a different commit is the tj-actions signature; alert on force-pushed tags in repositories you consume.
• Runner egress: build jobs reaching domains outside an allow list, especially paste sites, webhook services or newly registered domains.
• Secrets in logs: scan workflow logs for credential patterns; a payload that prints secrets to logs leaves evidence there.
• Cloud credential use after a build: CI cloud roles used from outside the runner network shortly after a dependency update.

Prevention controls mapped to ATT&CK mitigations

GitHub's hardening guidance says pinning an action to a full-length commit SHA mitigates a backdoor added to the action's repository, that the SHA must come from the action's repository rather than a fork, and that lockfiles, where adopted, give stronger protection. It also recommends read-only GITHUB_TOKEN defaults and OIDC to cloud providers instead of long-lived secrets. For provenance, SLSA's Build track runs from L1 (consistent build with provenance) to L3 (isolated builds where user-defined steps cannot reach the provenance signing secret); SLSA v1.2 is the current specification.

How to implement

1. Inventory what you consume: list package registries, CI actions and plugins, IDE extensions and vendor agents with auto-update. Record who can publish each internal package.
2. Harden publisher identities first: enforce phishing-resistant MFA on source control and registries, replace long-lived publishing tokens with trusted publishing, and remove dormant maintainers.
3. Put a proxy in front of public registries: start in log-only mode to see what builds pull, then enforce allow lists and a minimum package age. Roll back by switching the proxy to pass-through.
4. Pin and verify: pin CI actions and base images by digest, verify signatures and provenance where publishers provide them, and fail builds on unverified artefacts in a pilot repository before rolling out.
5. Constrain runners: ephemeral runners, network egress allow lists, OIDC-issued short-lived cloud credentials and minimal job permissions.
6. Deploy the detection chain: endpoint and server analytics for install to first run to egress, plus registry, tag and runner alerts. Tune in alert-only mode for two to four weeks.
7. Rehearse response: run a tabletop where a widely used dependency is found malicious: identify every build and host that pulled it, rotate every secret those runners held, and record how long it took.

Decision guidance

• SHA pinning versus version ranges: pinning blocks silent tag or version swaps but needs an update bot to stay current; use it for CI actions and critical dependencies at minimum.
• Vendor software you cannot inspect: rely on staged deployment rings, behavioural monitoring after updates and contractual SBOM and incident notification terms. See the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.
• Small organisations: focus on MFA for developer accounts, SHA pinning for actions, dependency scanning and short-lived cloud credentials in CI. A private registry proxy can come later.
• Large organisations: centralise package intake through one proxy, require provenance for internal builds and feed registry and runner telemetry into the SOC.

Detection and measurement

• Time to blast-radius answer: how long to list every build and host that consumed a named package version.
• Pinned action coverage: percentage of workflow steps that reference third-party actions by full SHA.
• Long-lived publishing tokens: count remaining, trending to zero as trusted publishing replaces them.
• Runner egress exceptions: number of blocked or alerted connections from build jobs per month.
• Secret rotation time after a supply chain alert: from alert to rotation of every secret the affected runners held.

Common failure patterns

• Trusting tags: referencing actions or images by mutable tag, which an attacker with a stolen token can repoint.
• Removing the package but not rotating secrets: the malicious version is gone but the tokens it stole remain valid.
• Reviewing source, shipping tarballs: as XZ Utils showed, the payload can sit in release artefacts that differ from the reviewed repository.
• Over-scoped CI tokens: one compromised dependency inherits write access to repositories, registries and cloud accounts.
• Ignoring signed updates: SUNBURST was signed; signature checks prove origin, not intent, so behaviour after update still needs monitoring.
• No owner for consumed components: nobody is accountable for deciding when a dependency or extension is too risky to keep.

Framework mapping

Practitioner checklist

• Inventory of consumed registries, actions, extensions and auto-updating agents, with owners.
• Phishing-resistant MFA on every source control and registry account with publish rights.
• Trusted publishing in place of long-lived registry tokens for internal packages.
• Third-party CI actions pinned to full commit SHAs; images pinned by digest.
• Ephemeral runners with egress allow lists and OIDC short-lived cloud credentials.
• Install to first-run to egress analytics running on endpoints, servers and runners.
• Alerts on tag movement, out-of-band publishes and new publishing tokens.
• Tested runbook to find every consumer of a package version and rotate their secrets.

Standards and references

• MITRE ATT&CK: Supply Chain Compromise (T1195)
• MITRE ATT&CK: Compromise Software Dependencies and Development Tools (T1195.001)
• MITRE ATT&CK: Compromise Software Supply Chain (T1195.002)
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• OpenSSF SLSA: Security levels
• GitHub Docs: Security hardening for GitHub Actions

Related NHI Mgmt Group resources: Software Supply Chain Security Guide, Top 10 Supply Chain Attacks, GitHub and GitHub Actions Security Guide, MITRE ATT&CK T1199 Trusted Relationship Guide.