Supply Chain Attack Analyst

Supply Chain Attack Analyst Skill

Configuration

• $SIEM_PLATFORM - Target SIEM for detection output: splunk, sentinel, elastic, sigma
• $SECURITY_CONTENT_PATH - Path to detection content repository

Overview

Software supply chain attacks compromise the tools, dependencies, and pipelines that developers trust. This skill covers analysis and detection across the major attack surfaces: package registries, CI/CD systems, container images, and code repositories.

Attack Surface Taxonomy

1. Package Registry Attacks

2. CI/CD Pipeline Attacks

3. Container & Image Attacks

Real-World Campaign Analysis Framework

When analyzing a supply chain incident, follow this structure:

Phase 1: Initial Triage

1. What was compromised? — Package name, version range, registry
2. What was the payload? — Data exfiltration, backdoor, cryptominer, ransomware
3. What was the delivery mechanism? — Install script, import hook, build step
4. What was the blast radius? — Download count, dependent packages, time window

Phase 2: Technical Analysis

1. Payload extraction — Deobfuscate and analyze malicious code
2. C2 identification — Network indicators (domains, IPs, protocols)
3. Persistence mechanisms — Does the payload survive package removal?
4. Lateral movement — Does it spread to other packages, repos, or systems?

Phase 3: Detection Opportunities

Map findings to detectable behaviors:

Detection Engineering Framework

npm / Node.js

Install script monitoring:

title: Suspicious npm Install Script Execution
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        ParentCommandLine|contains:
            - 'npm install'
            - 'npm ci'
            - 'yarn install'
        CommandLine|contains:
            - 'curl '
            - 'wget '
            - '/dev/tcp/'
            - 'base64 -d'
            - 'python -c'
    condition: selection
level: high

Key indicators:

• preinstall / postinstall scripts spawning network tools
• eval() or Function() constructors in package code
• Dynamic require() with encoded strings
• Access to process.env collecting CI secrets
• DNS lookups during npm install to non-registry domains

PyPI / Python

Key indicators:

• setup.py with cmdclass overrides executing code at install time
• __init__.py with obfuscated imports
• Use of exec(), eval(), compile() with encoded payloads
• subprocess.Popen or os.system calls in library code
• Typosquat names close to popular packages (e.g., reqeusts)

Detection approach:

title: Suspicious Python Package Install Behavior
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        ParentCommandLine|contains:
            - 'pip install'
            - 'pip3 install'
            - 'python setup.py'
        CommandLine|contains:
            - 'curl '
            - 'wget '
            - '/bin/sh -c'
            - 'base64'
    condition: selection
level: high

GitHub Actions

Workflow injection detection:

Look for untrusted input flowing into run: blocks:

# VULNERABLE — attacker-controlled title goes into shell
- run: echo "Issue: ${{ github.event.issue.title }}"

# SAFE — use environment variable
- run: echo "Issue: $ISSUE_TITLE"
  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}

Key indicators:

• Actions using actions/checkout with persist-credentials: true on PRs from forks
• Workflow triggers on pull_request_target with code checkout
• GITHUB_TOKEN with write permissions in fork-triggered workflows
• Third-party Actions pinned to branch (@main) instead of SHA (@a1b2c3d)
• Self-hosted runners used for public repo workflows

Container Supply Chain

Key indicators:

• Images pulled by tag instead of digest (nginx:latest vs nginx@sha256:abc...)
• Multi-stage builds with unpinned base images
• RUN curl ... | sh patterns in Dockerfiles
• Images from unofficial registries or unverified publishers

MITRE ATT&CK Mappings

Investigation Checklist

When a suspected supply chain compromise is reported:

• Identify affected package name, version(s), and registry
• Determine download count / install window
• Extract and deobfuscate payload
• Identify C2 infrastructure (domains, IPs)
• Check if payload persists after package removal
• Enumerate dependent packages (transitive dependencies)
• Search for similar typosquat variants still active
• Check if maintainer account was compromised vs new account
• File registry takedown request (npm: npm unpublish, PyPI: admin report)
• Create IOC-based detections for immediate response
• Create behavioral detections for long-term coverage
• Update package lockfiles across affected projects
• Audit CI/CD pipelines for exposed secrets during compromise window

Prevention Recommendations

Adapting Detections to Your SIEM

The Sigma rules above are platform-agnostic. Convert to your target SIEM:

# Splunk
sigma convert -t splunk -p sysmon rule.yml

# Sentinel / KQL
sigma convert -t microsoft365defender rule.yml

# Elastic
sigma convert -t elasticsearch rule.yml

For SIEM-native rules, adapt the detection logic using the appropriate field schema:

• Splunk CIM: process_name, parent_process_name, process
• Elastic ECS: process.name, process.parent.name, process.command_line
• Sentinel MDE: FileName, InitiatingProcessFileName, ProcessCommandLine

Resources

• SLSA Framework — Supply chain Levels for Software Artifacts
• OpenSSF Scorecard — Automated security health checks for OSS
• Socket.dev — Package supply chain security
• Sigstore — Keyless signing and verification
• CISA Supply Chain Security — Government guidance