MITRE ATT&CK technique T1195, Supply Chain Compromise, describes attackers manipulating a product or its delivery path before the customer receives it. For developers, MITRE's six listed mitigations translate into concrete habits: vet and pin dependencies, use approved internal repositories, patch, run with least privilege and scan continuously.
Where tampering can happen
MITRE's description lists many points, and the first three are in a developer's daily path:
- Development tools, environments and source code repositories.
- Open-source dependencies, where malicious code is inserted.
- Software update and distribution mechanisms.
Others include system images, removable media, modified copies of legitimate software, counterfeit products and interdicted shipments. The page also mentions "second-order" compromises, where access gained in one supply chain attack is used to compromise another.
The technique has three sub-techniques: compromise of software dependencies and development tools, compromise of the software supply chain, and compromise of the hardware supply chain.
The six mitigations, as developer habits
Application developer guidance. MITRE says to vet third-party libraries and lock dependencies to specific versions. In practice: lockfiles in every repository, and a review step when a lockfile changes.
Limit software installation. Developers use internal repositories with verified, approved packages. In practice: a proxy or mirror in front of public registries, with a short allowlist for build tools.
Update software. Keep a patch process that also checks for unused, unmaintained or vulnerable dependencies. In practice: a monthly pass that removes packages nobody imports.
User account management. Run software with the lowest privileges needed. In practice: build jobs without root and without long-lived cloud keys.
Vulnerability scanning. Continuously monitor vulnerability sources and use automated and manual code review. In practice: a scanner in CI plus a human look at risky changes.
Boot integrity. Use secure boot to verify the operating system and its loading. This one belongs mostly to your platform or IT team.
Why second-order matters
If a build system or developer machine is compromised, its output may carry the compromise to your customers. The same risk applies in reverse to you as a consumer. A short list of questions helps: who can publish to our internal registry, who can change the pipeline, and which secrets does a build job hold?
Where tooling fits
An SBOM and dependency scan answers the first question every incident asks: do we use this component, and where? Safeguard offers SBOM generation and dependency scanning, with reachability analysis to show which findings your code can actually hit. You can try it at https://gold.safeguard.sh/scan. Treat it as one control among the six, not a replacement for review habits.
Quick check
Does locking dependencies stop supply chain attacks?
It stops silent version changes. It does not make a pinned bad version safe, so combine it with review and scanning.
What is a second-order supply chain compromise?
One where access from one supply chain compromise is used to compromise another.
Sources
Last reviewed: 19 October 2026.
