T1195
Supply Chain Compromise
Linux · Windows · macOS · SaaS5 pieces on this siteT1195 on attack.mitre.org
Adversaries may manipulate products or product delivery mechanisms prior to receipt by a final consumer for the purpose of data or system compromise. Supply chain compromise can take place at any stage of the supply chain including: * Manipulation of development tools * Manipulation of a development environment * Manipulation of source code repositories (public or private) * Manipulation of source code in open-source dependencies * Manipulation of...
If this is happening now
Checklists and playbooks to open while the alert is still live.
A supplier tells you they were breached
A notification from a vendor, or their name in the news before their email arrives.
A malicious package was installed
A registry advisory, a vendor alert or a dependency scanner says a package version you use was malicious, or a build or a developer laptop ran an install script it should not have.
Read
Analyses, case studies, guides, references and interview questions.
Case study: the update was signed, and that was the problem
A trusted software update that carried a backdoor, worked as a case. Signing proved the build was the vendor's; it proved nothing about what was in it. Eight questions on detection, scope and the uncomfortable part, which is that nothing your endpoint controls were watching for was wrong.
Evidence Gap Challenge No. 2: the proxy only kept the domain
A developer laptop, a package that should not have been installed, and a proxy that logged where the traffic went but not what was asked for. Work out what the truncation costs you, what you can still prove, and whether a full-URL log would have been worth what it costs to keep.
Gitea's diffpatch endpoint plants a Git hook, and the hook does the rest
CVE-2026-60004 turns repository write access into shell execution as the Gitea service account. The interesting part is not the injection. It is that Git hooks are executable files sitting inside a directory your developers write to all day.
how MITRE says to see it
Behavioral detection for Supply Chain Compromise (package/update tamper → install → first-run)
- 1) New or updated software is delivered/installed from atypical sources or with signature/hash mismatches; 2) installer/updater writes binaries to unexpected paths or replaces existing signed files; 3) first run causes unsigned/abnormally signed modules to load or child processes to execute, optionally followed by...
- 1) Package manager or curl/wget installs/upgrades from non-approved repos or unsigned packages; 2) new ELF written into PATH directories or replacement of existing binaries/libraries; 3) first run leads to unexpected child processes or outbound connections.
- 1) pkg/notarization installs from atypical sources or with Gatekeeper/AMFI warnings; 2) new Mach-O written into /Applications or ~/Library paths or substitution of signed components; 3) first run from installer spawns unsigned children or exfil.
what reduces it
- M1016 Vulnerability Scanning. Continuous monitoring of vulnerability sources and the use of automatic and manual code review tools should also be implemented as well.
- M1033 Limit Software Installation. Where possible, consider requiring developers to pull from internal repositories containing verified and approved packages rather than from external ones.
- M1013 Application Developer Guidance. Application developers should be cautious when selecting third-party libraries to integrate into their application. Additionally, where possible, developers should lock software dependencies to specific versions rather than pulling the latest version on build.
- M1046 Boot Integrity. Use secure methods to boot a system and verify the integrity of the operating system and loading mechanisms.
- M1018 User Account Management. Implement robust user account management practices to limit permissions associated with software execution. Ensure that software runs with the lowest necessary privileges, avoiding the use of root or administrator accounts when possible.
- M1051 Update Software. A patch management process should be implemented to check unused dependencies, unmaintained and/or previously vulnerable dependencies, unnecessary features, components, files, and documentation.