Supply Chain Advisory
Triage suspected PyPI or dependency supply-chain compromises with lockfile scans, containment steps, and documented compromised versions.
Overview
Supply Chain Advisory is an agent skill most often used in Ship (also Operate) that guides triage and containment when Python dependencies may be compromised in a supply-chain attack.
Install
npx skills add https://github.com/athola/claude-night-market --skill supply-chain-advisoryWhat is this skill?
- Curated compromised package version metadata (e.g. litellm 1.82.7–1.82.8) with severity and sources
- Five-minute scope checklist: lockfiles, installed METADATA, malicious artifact search
- Containment playbook: stop processes, preserve venv for forensics, env snapshot
- Indicators such as litellm_init.pth and modified proxy_server.py called out explicitly
- SessionStart hook integration for ongoing advisory awareness
- Scope assessment triage checklist targets roughly 5 minutes
- Documented critical litellm compromised versions 1.82.7 and 1.82.8 (March 2026 advisory)
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You heard a PyPI package was compromised but do not know which versions are in your lockfiles, venvs, or running processes.
Who is it for?
Indie developers and agent users who manage uv/pip lockfiles locally and need a fast, repeatable incident checklist when advisories drop.
Skip if: Organizations wanting full SOC playbooks, non-Python ecosystems only, or greenfield projects with zero third-party dependencies.
When should I use this skill?
Supply chain compromise reported, SessionStart hook runs, or user needs to assess PyPI package versions against known compromised metadata and respond.
What do I get? / Deliverables
You complete scoped lockfile and artifact checks, contain active risk, preserve evidence, and align actions to documented compromised versions and indicators.
- Scoped list of affected packages/versions in lockfiles and venvs
- Containment actions with forensic preservation notes
- Environment snapshot command guidance for incident records
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship is the primary shelf because the skill targets dependency risk before and during release, with follow-on containment relevant when operating compromised environments. Security matches supply-chain incident response, credential-theft indicators, and advisory checks—not generic CI wiring alone.
Where it fits
Before tagging a release, scan lockfiles for advisory-listed versions and block deploy if indicators match.
After a public PyPI compromise post, verify whether your agent-installed deps pulled affected builds.
When suspicious env access appears, run containment steps and snapshot environment without wiping the venv.
Adding a new LLM proxy dependency and wanting SessionStart awareness of known bad litellm builds.
How it compares
Use as a focused dependency-incident skill, not as a substitute for full SAST/DAST or platform-wide SIEM operations.
Common Questions / FAQ
Who is supply-chain-advisory for?
Solo and indie builders who install Python dependencies via agents or CI and need structured steps when package compromises are reported.
When should I use supply-chain-advisory?
During Ship before releasing or after a security bulletin, and in Operate when monitoring running services that might have pulled a bad version.
Is supply-chain-advisory safe to install?
It references real incidents and may trigger filesystem searches; review the Security Audits panel on this Prism page and validate commands before running them on production machines.
SKILL.md
READMESKILL.md - Supply Chain Advisory
{ "_meta": { "description": "Known compromised PyPI package versions. Used by supply-chain-advisory skill and SessionStart hook.", "last_updated": "2026-03-27", "format": "package_name -> list of { versions, date, description, indicators, source }" }, "litellm": [ { "versions": ["1.82.7", "1.82.8"], "date": "2026-03-24", "description": "Compromised maintainer credentials via Trivy supply chain attack. Credential stealer harvesting env vars, SSH keys, cloud credentials, k8s tokens, db passwords.", "indicators": ["litellm_init.pth", "modified proxy_server.py"], "source": "https://docs.litellm.ai/blog/security-update-march-2026", "severity": "critical" } ] } # Incident Response ## Triage Checklist When a supply chain compromise is reported: ### 1. Scope Assessment (5 minutes) - [ ] Identify affected package name and versions - [ ] Search all lockfiles on machine: `rg "package.*version" --glob "uv.lock" ~` (or `grep -r --include="uv.lock"`) - [ ] Check installed versions: `find ~ -path "*/.venv/*/METADATA" -exec rg Version {} +` (or `grep`) - [ ] Search for malicious artifacts: `find ~ -name "indicator_file" 2>/dev/null` ### 2. Containment (if affected) - [ ] Stop any running processes using the affected package - [ ] Do NOT delete the virtualenv yet (preserve for forensics) - [ ] Disconnect from sensitive services if credential theft suspected - [ ] Capture current environment: `env > /tmp/env_snapshot_$(date +%s).txt` ### 3. Remediation - [ ] Add version exclusions to `pyproject.toml`: `!=affected.version` - [ ] Remove malicious artifacts from virtualenvs - [ ] Regenerate lockfile: `uv lock` - [ ] Reinstall: `uv sync` - [ ] Rotate ALL credentials that were accessible to the process ### 4. Credential Rotation Priority If a credential-stealing payload was present, rotate in this order: 1. **Cloud provider keys** (AWS, GCP, Azure): highest blast radius 2. **Database passwords**: data exfiltration risk 3. **SSH keys**: lateral movement risk 4. **API tokens**: service access 5. **Kubernetes tokens**: cluster compromise 6. **Environment variables**: may contain any of the above ### 5. Documentation - [ ] Add incident to `docs/dependency-audit.md` - [ ] Update `known-bad-versions.json` blocklist - [ ] File GitHub issue linking to advisory - [ ] Notify team members who may have affected environments ## Post-Incident Review After containment, evaluate: 1. Why did existing tooling not catch this? 2. What detection layer would have caught it earliest? 3. Should scanning frequency be increased? 4. Are there similar packages in our dependency tree at risk? # Scanning Patterns ## Lockfile Audit For each lockfile type, extract package names and versions, then compare against the known-bad-versions blocklist. ### uv.lock ```python import re from pathlib import Path def parse_uv_lock(path: Path) -> dict[str, str]: """Extract package->version mapping from uv.lock.""" packages = {} content = path.read_text() for match in re.finditer( r'^name\s*=\s*"([^"]+)".*?^version\s*=\s*"([^"]+)"', content, re.MULTILINE | re.DOTALL, ): packages[match.group(1)] = match.group(2) return packages ``` ### requirements.txt ```python def parse_requirements(path: Path) -> dict[str, str]: """Extract package->version from pinned requirements.""" packages = {} for line in path.read_text().splitlines(): line = line.strip() if "==" in line and not line.startswith("#"): name, version = line.split("==", 1) packages[name.strip()] = version.strip() return packages ``` ## Artifact Scanning Search for known malicious file indicators across a directory tree: ```python from pathlib import Path def scan_for_artifacts(root: Path, indicators: list[str]) -> list[Path]: """Find known malicious artifacts in a directory tree.""" found = [] for indicator in indicators: