Supply Chain Audit

supply-chain-audit.md

argument-hint	[path=/home/anton] [focus=litellm]
allowed-tools	Bash Read Write

Supply Chain Audit — Contextual Dependency Triage

Scan installed packages for known vulnerabilities, then triage by reachability and exploitability — not just CVE count. Produces a prioritized Obsidian note with TUI visualizations and ATT&CK mappings.

Input

$ARGUMENTS optionally contains:

• path=<dir> to scope the scan to a specific project directory (default: system-wide Python + any package-lock.json/requirements.txt found)
• focus=<package> to highlight a specific package's dependency chain in the triage (e.g., focus=litellm)

Configuration

VAULT=Obsidian Vault
PATH -- from args or default (system-wide)
FOCUS -- from args or empty

Prerequisites

Check for available scanners. Install what's missing:

• pip-audit: pip install pip-audit (Python packages against OSV/PyPI advisory DB)
• osv-scanner: Download binary from GitHub releases if not in PATH (covers all ecosystems)

If neither can be installed, fall back to pip list --outdated --format=json + manual CVE lookup.

Workflow

Step 1 — Scan (run all applicable scans in parallel)

1a. Python packages (pip-audit)

pip-audit --format json --output /tmp/pip-audit-results.json

1b. Node packages (if package-lock.json exists)

osv-scanner scan --format json -L <path>/package-lock.json > /tmp/osv-node-results.json

1c. If a focus package is specified, get its dependency chain

pip show <FOCUS> | grep -i requires

1d. Check what's actually running and network-exposed

ss -tlnp  # What ports are listening
ps aux    # What processes own them

Step 2 — Parse scan results

Read the JSON output files. For each vulnerable package, record:

• Package name and installed version
• Number of CVEs and their IDs
• Available fix version(s)
• CVE descriptions (first 120 chars)

Step 3 — Contextual triage (this is the LLM value-add)

For each vulnerable package, determine reachability:

Reachability categories:

1. DIRECT — direct dependency of a network-exposed service (e.g., in the focus package's dep chain, bound to a port)
2. TRANSITIVE (network) — transitive dep in the HTTP/TLS/auth chain (urllib3, requests, cryptography, certifi, pyjwt, etc.)
3. BUILD — only used during package install/build (setuptools, pip, wheel)
4. OFFLINE — only used for local processing, not in any network request path (pillow, pygments)
5. LOCAL — exposed on localhost only, not routable

Severity triage (override scanner severity with context):

• CRITICAL: Package is in the request path of a network-exposed service AND the CVE enables RCE, auth bypass, or credential theft
• HIGH: Package is in the dependency chain of a network service AND the CVE enables data exposure or MitM
• MEDIUM: Package is reachable but exploit requires unusual conditions (specific config, user-controlled input in a specific function)
• LOW: Package is not in any network path, or CVE is theoretical (ReDoS in offline processing, path traversal only during pip install)

Key triage questions for each CVE:

• Is this package imported at runtime by anything network-exposed?
• Does the vulnerable code path get hit with attacker-controlled input?
• Is there a .netrc, proxy config, or SSO flow that makes credential leaks relevant?
• Is the fix a minor version bump (safe) or a major version (may break things)?

Step 4 — ATT&CK mapping

Map the triaged findings to MITRE ATT&CK techniques:

CVE Pattern	Technique
Template injection / RCE	T1190 Exploit Public-Facing Application
Sandbox escape	T1059 Command and Scripting Interpreter
TLS/crypto weakness	T1557 Adversary-in-the-Middle
Credential leak	T1552.001 Credentials in Files
JWT/auth bypass	T1550.001 Application Access Token
Dependency vuln (general)	T1195.002 Supply Chain: Software Supply Chain
ReDoS	T1499.004 Application or System Exploitation (DoS)

Step 5 — Generate TUI visualizations

Create two visualizations using Python scripts to guarantee alignment:

5a. Triage table

A framed box (║ borders) showing all vulnerable packages sorted by triage priority, with columns: PACKAGE, VERSION, CVEs, REACHABLE?, TRIAGE. Group by severity tier with section headers. Use ██ for critical/high, ░░ for medium, .. for low.

5b. Scanner vs Context comparison

An unframed chart showing raw scanner output vs triaged results — the before/after that demonstrates the value of contextual analysis. Include a reachability bar chart.

Step 6 — Write Obsidian note

Note name: Supply Chain Audit — <YYYY-MM-DD>

obsidian create vault="{VAULT}" name="Supply Chain Audit — $(date +%Y-%m-%d)" overwrite content="..."

Note structure:

---
scan_date: <YYYY-MM-DD>
host: <hostname>
scanners: <tools used and versions>
total_packages_python: <N>
total_packages_node: <N>
total_cves: <N>
critical_findings: <N>
high_findings: <N>
medium_findings: <N>
low_findings: <N>
---

# Supply Chain Audit — <YYYY-MM-DD>

> [!failure] Audit Summary
> **Host:** <name>  |  **Python packages:** <N>  |  **Node packages:** <N>
> **Total CVEs found:** <N>
> **After triage:** <N> fix today, <N> fix this week, <N> noise
> **Key exposure:** <one-line summary of worst finding>

## Supply Chain Triage

(TUI triage table — framed, all packages by priority)

## Scanner vs Context

(TUI comparison chart — scanner output vs triaged results)

## Findings

### CRITICAL

> [!failure] <package> <version> — <summary> (<N> CVEs)
> **Direct/transitive dependency of:** <what service>
> **CVEs:** <list>
> **Worst case:** <specific exploit scenario for this host>
> **ATT&CK:** <technique ID and name>
> **Fix:**
> ```bash
> pip install "<package>>=<fix_version>"
> ```

### HIGH / MEDIUM / LOW
(Same pattern, use [!warning], [!caution], [!info] callouts)

## ATT&CK Mapping

(Table: Technique | ID | Vulnerable Package | Scenario)

## Dependency Chain

(ASCII tree showing focus package -> deps -> vulnerable packages with CVE counts)

## Remediation

### Fix Today (CRITICAL + HIGH)
```bash
pip install "<pkg1>>=<ver>" "<pkg2>>=<ver>" ...

Fix This Week (MEDIUM)

Fix at Convenience (LOW)

Recommendations

(Numbered, severity-tagged, prioritized by exploitability not CVE count)

### Step 7 — Summary

Report to the user:
- Total packages scanned and CVEs found
- Scanner count vs triaged count (the value-add number)
- Top 3 findings by exploitability
- ATT&CK techniques covered
- Confirm note written to Obsidian