Application Dependencies Mapping

Info

Tactic: Reconnaissance

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.

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"]
Detection Challenges

Why Traditional Security Tools Fail:

  1. Dependency Complexity
  2. Deep nested dependencies are hard to track
  3. Version conflicts mask malicious updates

  4. Transitive dependencies create blind spots

  5. Trust Assumptions

  6. Signed packages bypass security checks
  7. Trusted repositories contain malicious code

  8. Build processes implicitly trust dependencies

  9. Scale Issues

  10. Too many dependencies to manually verify
  11. Automated tools miss context
  12. Updates happen too frequently to track

Required Application Security Strategy: 

# Dependency monitoring rules
- rule: "Suspicious Dependency Change"
  condition: |
    dependency.update_frequency > normal_threshold OR
    dependency.source_changed OR
    dependency.signature_changed
  severity: high

# Integration point monitoring
- rule: "Abnormal Dependency Usage"
  condition: |
    dependency.calls_unexpected_apis OR
    dependency.accesses_sensitive_data OR
    dependency.connects_to_internet
  severity: critical