Skip to content

Application Dependencies Mapping

Info

ID: AT-RE002
Tactic: Reconnaissance

Sub-techniques: Client-Side Commercial Vendor Discovery, Image Metadata Inspection, Manifest Inspection, OpenSource Dependency Enumeration, Package Manifest Scraping, Registry Metadata Query, SBOM Analysis
Platforms: PRE

Adversaries may enumerate and analyze third-party libraries (open-source and commercial software), frameworks, and base images that an application relies upon to uncover potential weaknesses. Common methods include extracting package manifests, examining SBOMs (Software Bill of Materials), and parsing container image metadata to identify unpatched software or suspicious version patterns. By mapping these dependencies, attackers learn precisely where outdated or vulnerable components reside, directing their subsequent exploitation efforts toward the most impactful targets.

This technique is especially relevant in cloud-native stacks, where microservices frequently import dozens of third-party components including both open-source libraries and commercial software packages. Even a single neglected version can become the linchpin for an attacker's supply-chain or runtime compromise. Successfully enumerating dependencies can also reveal developer habits - such as reliance on obscure or newly published packages - that adversaries may exploit by inserting malicious updates upstream.

Mitigations

ID Mitigation Description
M1013 Application Developer Guidance Publish redacted SBOMs/manifest lists—omit internal component versions or non-public dependencies—to reduce attacker reconnaissance value.
M1021 Restrict Web-Based Content Require authentication or scoped access tokens for repository APIs that serve dependency manifests, preventing bulk unauthenticated scraping.
M1045 Code Signing Enforce signed commits and provenance (SLSA level 3+) for dependency files so tampering attempts are detected at CI time.

Detection

Most dependency-mapping reconnaissance occurs entirely on public code-hosting platforms or via unauthenticated package-registry APIs, keeping the activity outside the defender’s on-prem or cloud collection boundary. Consequently there is little to no host- or network-level telemetry inside the target enterprise that exposes enumeration in real time.

Visibility is usually achieved only through:

  • Platform-native audit logs (e.g., GitHub/GitLab API logs, private package-registry telemetry) when the organisation controls the repository and reviews access events.
  • Third-party threat-intelligence feeds that flag bulk scraping of organisation-specific terms or fingerprinted leak-hunting tools.
  • Down-stream effects, such as spear-phishing or exploits that reference manifest data harvested from public sources.
Examples in the Wild

Notable Application Dependency Mapping Attacks:

XZ-Utils Backdoor (CVE-2024-3094) The XZ-Utils backdoor attack demonstrated sophisticated application dependency mapping by targeting the widely-used xz compression library. The attacker (JiaT75) spent years mapping dependencies and understanding how the library was integrated into major Linux distributions, ultimately compromising versions 5.6.0 and 5.6.1. This affected all major Linux distributions including Fedora, RHEL, Debian, and thousands of downstream packages due to the deep understanding of dependency chains.

SolarWinds SUNBURST The SolarWinds supply chain attack involved extensive application dependency mapping to understand how the Orion platform's components interacted. The attackers mapped the dependency chain from the core SolarWinds.Orion.Core.BusinessLayer.dll to identify how it was used across the platform, enabling them to inject malicious code that would be distributed through the trusted update mechanism.

GitHub Actions Supply Chain Attack The GitHub Actions attack showcased dependency mapping at the CI/CD level. APT35 mapped critical GitHub Actions dependencies like reviewdog/action-setup and tj-actions/changed-files, understanding their widespread usage (>2M and >5M monthly downloads respectively) to maximize the attack's impact across thousands of repositories.

ShellTorch Attack The ShellTorch attack demonstrated application dependency mapping in AI infrastructure by targeting PyTorch's TorchServe framework. The attackers mapped how TorchServe was integrated into major platforms including AWS SageMaker, Google Vertex AI, and Kubeflow, allowing them to identify and exploit vulnerabilities that affected multiple AI deployment platforms.

Attack Mechanism

Dependency Mapping Techniques Used in Real Attacks:

  1. Package Manager Analysis
  2. Studying package.json, requirements.txt, and other dependency files
  3. Analyzing version constraints and dependency relationships

  4. Identifying widely-used packages with high impact potential

  5. Build Process Investigation

  6. Examining build scripts and configuration files
  7. Understanding how dependencies are resolved and linked

  8. Identifying points where malicious code can be injected

  9. Integration Point Discovery

  10. Mapping service-to-service dependencies
  11. Understanding API dependencies and data flow

  12. Identifying critical shared libraries and components

  13. Version Control Analysis

  14. Studying commit history for dependency changes
  15. Analyzing merge requests and dependency updates
  16. Identifying patterns in dependency management
Real-World Examples 
# XZ-Utils Dependency Chain
liblzma.so.5:
  - used_by: ["systemd", "apt", "dpkg"]
  - impact: "Critical system components"
  - distributions: ["Debian", "RHEL", "Ubuntu"]

# SolarWinds Component Dependencies
SolarWinds.Orion.Core.BusinessLayer.dll:
  - referenced_by: ["OrionWeb", "OrionServer"]
  - called_by: ["Authentication", "Monitoring"]
  - integrated_with: ["Windows Services", "IIS"]

# GitHub Actions Dependencies
reviewdog/action-setup:
  - monthly_downloads: ">2M"
  - used_by: ["CI/CD pipelines", "Code Review"]
  - integrated_with: ["GitHub Workflows", "PR Checks"]