Has compromised CI/CD pipelines by gaining access to high privilege engineering accounts on Git version control, BrowserStack, JFrog and other cloud project management platforms.1
Compromise Software Dependencies and Development Tools T1195.001
- Tactic
- Initial Access
- Platforms
- Linux, macOS, Windows
- Version
- 1.3
- Created
- 11 March 2020
- Last modified
- 12 May 2026
- Contributors
- Enis Aksu; Joe Gumke, U.S. Bank; Liran Ravich, CardinalOps
Adversaries may manipulate software dependencies and development tools prior to receipt by a final consumer for the purpose of data or system compromise. Applications often depend on external software to function properly. Popular open source projects that are used as dependencies in many applications, such as pip and NPM packages, may be targeted as a means to add malicious code to users of the dependency.[1][2][3] This may also include abandoned packages, which in some cases could be re-registered by threat actors after being removed by adversaries.[4] Adversaries may also employ "typosquatting" or name-confusion by choosing names similar to existing popular libraries or packages in order to deceive a user.[5][6][7]
Compromise Software Dependencies and Development Tools MITRE reference T1195.001
2 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has conducted coordinated supply chain attacks targeting open-source developer infrastructure including the NPM, VS Code, Docker, and PyPi ecosystems to compromise multiple software packages.123456789101112
All 2 groups for this technique
7 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Has published itself on compromised victim code repositories to propagate malicious versions of packages to other victims.122
Has spread through an automated process that infects and publishes npm packages.12
Has used the Node Package Manager (npm) to download malicious packages and to deliver the payload.1
Has spread through Visual Studio extensions.123 GlassWorm has also spread through JavaScript projects hosted on Github.2
Has published itself on compromised code repository maintainers within infected packages in attempts to propagate to other victims.12345 Shai-Hulud has also modified versions of code packages.1235
Has been hosted on code repositories and disseminated to victims through NPM packages.12345
All 7 software entries for this technique · 6 newest in this preview
Offense vs defense T1195.001
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Compromise Software Dependencies and Development Tools detection strategy DET0009
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Supply-chain tamper in dependencies/dev-tools (manager→write/install→first-run→egress)
AN0021 · Windows
Adversary manipulates dependencies/dev tools used by developers or CI: a package manager (npm/yarn/pnpm, pip/pipenv, nuget/dotnet, chocolatey/winget, maven/gradle) or a compiler/IDE downloads or restores content; files are written under project paths and execution paths (node_modules, packages, .nuget, .gradle, .m2, %AppData%\npm, %UserProfile%\.cargo\bin, temp build dirs). First run of newly written components triggers scripts (preinstall/postinstall), shell/PowerShell spawning, or loader DLLs, followed by network egress to non-approved registries/CDNs.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Module LoadDC0016 | WinEventLog:Sysmon | EventCode=7 |
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| File CreationDC0039 | WinEventLog:Sysmon | EventCode=11 |
| File MetadataDC0059 | WinEventLog:Microsoft-Windows-CodeIntegrity/Operational | Invalid/Unsigned image when developer tool launches newly installed binaries |
| Windows Registry Key ModificationDC0063 | WinEventLog:Sysmon | EventCode=13, 14 |
| Network Traffic FlowDC0078 | NSM:Flow | First-time outbound connections to package registries or unknown hosts immediately after restore/build |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TimeWindow | Correlate file write by package manager to first execution and egress (default 90 minutes). |
| ApprovedRegistries | Allow-listed registries (e.g., registry.npmjs.org, pypi.org, nuget.org, maven.apache.org, company proxies/CDNs). |
| DevHosts | Limit analytics to engineering endpoints/CI agents to reduce noise. |
| TrustedPublishers | Code-signing publishers acceptable for dev tools. |
AN0022 · Linux
Developer or CI invokes package managers/compilers (apt/yum + build-essential, npm/yarn/pnpm, pip/pip3, gem, cargo, go, maven/gradle). These write executable or script files into PATH or project dirs and immediately execute embedded lifecycle hooks (preinstall/postinstall, setup.py, npm scripts) that spawn shells or curl/wget, followed by egress to unfamiliar registries or domains.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process ModificationDC0020 | auditd:SYSCALL | rename, chmod |
| Process CreationDC0032 | auditd:SYSCALL | execve |
| File MetadataDC0059 | journald:package | dpkg/apt or yum/dnf transaction logs (install/update of build tools) |
| Network Traffic FlowDC0078 | NSM:Flow | First-time egress to new registries/CDNs post-install/build |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| ApprovedRepos | Allowed APT/YUM repos and GPG keys for build tools. |
| PathScope | Monitor /usr/local/bin, /usr/bin, /opt/*/bin, ~/.local/bin, node_modules/.bin, .venv/bin, .cargo/bin, .gradle, .m2. |
| TimeWindow | Default 90 minutes for write→exec→egress linkage. |
AN0023 · macOS
Developer tools (Homebrew, pip, npm/yarn, Xcode builds) install or update dependencies; new Mach-O or scripts appear under /usr/local, /opt/homebrew, ~/Library/Application Support, project dirs (node_modules/.bin, venv/bin). First run spawns sh/zsh/osascript/curl and new outbound flows; Gatekeeper/AMFI may flag unsigned components.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | macos:endpointsecurity | exec |
| File MetadataDC0059 | macos:unifiedlog | softwareupdated/homebrew/install logs, pkginstalld events |
| Network Traffic FlowDC0078 | NSM:Flow | First-time egress to non-approved registries after dependency install |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AllowedTeamIDs | Apple Developer Team IDs for approved dev tools (Xcode, JetBrains, etc.). |
| BrewTapsAllowList | Homebrew taps allowed in your environment. |
| TimeWindow | Default 90 minutes. |
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. GitHub Actions may be pinned to a specific commit hash rather than a tag or branch.
Where possible, consider requiring developers to pull from internal repositories containing verified and approved packages rather than from external ones.
A patch management process should be implemented to check unused dependencies, unmaintained and/or previously vulnerable dependencies, unnecessary features, components, files, and documentation.
Continuous monitoring of vulnerability sources and the use of automatic and manual code review tools should also be implemented as well.