Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Adversaries may manipulate software dependencies and development tools prior to receipt by a final consumer for the purpose of data or system compromise.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-05 | ✗→✓ | ▲ Improved | 46% | 0% |
| case-09 | ✗→✓ | ▲ Improved | -15% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 212% | 0% |
| case-18 | ✗→✓ | ▲ Improved | -17% | 0% |
| case-07 | ✓→✓ | ＝ Same ✓ | 5% | 0% |
> Sub-technique of: T1195
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. This may also include abandoned packages, which in some cases could be re-registered by threat actors after being removed by adversaries. Adversaries may also employ "typosquatting" or name-confusion by choosing names similar to existing popular libraries or packages in order to deceive a user.
Additionally, CI/CD pipeline components, such as GitHub Actions, may be targeted in order to gain access to the building, testing, and deployment cycles of an application. By adding malicious code into a GitHub action, a threat actor may be able to collect runtime credentials (e.g., via Proc Filesystem) or insert further malicious components into the build pipelines for a second-order supply chain compromise. As GitHub Actions are often dependent on other GitHub Actions, threat actors may be able to infect a large number of repositories via the compromise of a single Action.
Targeting may be specific to a desired victim set or may be distributed to a broad set of consumers but only move on to additional tactics on specific victims.
Platforms: Linux, macOS, Windows
> Note: No Atomic Red Team tests available for this technique. See Atomic Red Team GitHub for updates.
Where possible, consider requiring developers to pull from internal repositories containing verified and approved packages rather than from external ones.
Continuous monitoring of vulnerability sources and the use of automatic and manual code review tools should also be implemented as well.
A patch management process should be implemented to check unused dependencies, unmaintained and/or previously vulnerable dependencies, unnecessary features, components, files, and documentation.
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.
| Finding | Severity | Impact | | --------------------------------------------------------------------------- | -------- | -------------- | | Compromise Software Dependencies and Development Tools technique applicable | High | Initial Access |
| CWE ID | Title | | ------ | ------------------------- | | CWE-20 | Improper Input Validation |
Other measured skills in the registry, with their headline benchmark lift.