Compromise Software Dependencies and Development Tools (MITRE ATT&CK T1195.001) is a sub-technique of supply chain compromise. The attacker manipulates the libraries and tools that developers use, before they reach the final consumer. MITRE files it under Initial Access and lists Linux, Windows and macOS.
Applications depend on external software. That is normal, and it is also the opening.
How attackers use it
MITRE documents several routes.
Popular and abandoned packages. Open-source projects used as dependencies in many applications, such as pip and npm packages, can be targeted to add malicious code for all users of the dependency. MITRE also notes abandoned packages, which in some cases could be re-registered by threat actors after being removed.
Name confusion. Adversaries may use typosquatting, choosing names similar to popular libraries so a user installs the wrong one.
CI/CD components. Pipeline components such as GitHub Actions can be targeted to reach the build, test and deploy cycle. By adding malicious code to an Action, an attacker may collect runtime credentials, for example through the proc filesystem, or insert more malicious components into build pipelines. Because Actions often depend on other Actions, one compromised Action may reach a large number of repositories.
IDE and AI agent configuration. MITRE now also describes files consumed by integrated development environments and AI coding agents. Project files such as tasks.json may run commands when a developer opens or builds a project. Agent skill files (SKILL.md) give an agent instructions and resources that it loads on demand and runs with the permissions of the agent process. To encourage downloads, adversaries may publish these under benign or typosquatted names, upload clean copies first so listings gather installs before the content is weaponized, or hide the malicious instructions in a secondary document that the reviewed entry point references. Because these files are natural language or configuration rather than executable code, they may pass registry screening and signature-based scanning.
Targeting may be narrow or broad. Some campaigns spread to many consumers and only act on specific victims.
The MITRE page lists real incidents involving npm packages, extensions for Visual Studio, and self-propagating code that infects and publishes npm packages. The page is worth reading for those references.
How to detect it
MITRE's detection strategy follows the chain: package manager, then write or install, then first run, then egress.
Windows. A package manager or build tool (npm, yarn, pnpm, pip, pipenv, nuget, dotnet, chocolatey, winget, maven, gradle) restores content. Files appear under project and execution paths such as node_modules, packages, .nuget, .gradle, .m2 and %AppData%\npm. The first run of new components triggers lifecycle scripts such as preinstall or postinstall, shell or PowerShell spawning, or loader DLLs, followed by traffic to non-approved registries or CDNs.
Linux. A developer or CI job invokes package managers or compilers (apt, yum, npm, pip, gem, cargo, go, maven, gradle). Files are written into PATH or project directories and embedded lifecycle hooks (preinstall, postinstall, setup.py, npm scripts) run immediately, spawning shells or curl or wget, then connecting to unfamiliar registries or domains.
macOS. Homebrew, pip, npm or Xcode builds install dependencies. New Mach-O files or scripts appear under /usr/local, /opt/homebrew, ~/Library/Application Support or project directories. First run spawns sh, zsh, osascript or curl and new outbound flows. Gatekeeper and AMFI may flag unsigned components.
Useful signals in short:
- An install command followed within seconds by a shell, curl or PowerShell child process
- Network connections from a build step to hosts outside your approved registries
- New executables in node_modules/.bin, venv/bin or similar directories that were not part of the lockfile
- A CI job that reads credentials it had no reason to touch
How to reduce the risk
From MITRE's mitigations:
- Choose libraries carefully and pin versions. Lock dependencies to specific versions instead of pulling the latest on build. Pin GitHub Actions to a specific commit hash instead of a tag or branch.
- Use approved internal repositories. Where possible, make developers pull from internal repositories that hold verified and approved packages.
- Run patch management that checks for unused, unmaintained or previously vulnerable dependencies and unnecessary components.
- Monitor vulnerability sources continuously and use automatic and manual code review tools.
Check your own environment
- Is every dependency pinned through a lockfile, and does CI install from that lockfile only?
- Are your GitHub Actions pinned to commit hashes?
- Do build jobs have network access to anything beyond your approved registries?
- Who reviews new dependencies before they are added?
- Do developers open unknown repositories in an IDE with project tasks allowed to run automatically?
- Do you review agent skill files and their referenced documents the way you review code?
For a quick look at what a project pulls in, run the free in-browser dependency scan at gold.safeguard.sh/scan. No login is needed, the file never leaves your machine, and it handles up to 100 dependencies. The Gold directory is a place to look up packages.
Try it yourself
This demo shows how malicious packages and typosquats are spotted among legitimate dependencies.
Click through it at your own pace, or open it full screen.
Quick check
Why does MITRE suggest pinning a GitHub Action to a commit hash?
A tag or branch can be moved to new code. A commit hash points to one fixed state, so a later compromise of the Action does not change what your pipeline runs until you update the hash.
Why might an agent skill file pass registry screening?
It is natural language or configuration rather than executable code, so signature-based scanning may not flag it.
What is typosquatting in this context?
Publishing a package under a name close to a popular one so that users install it by mistake.
