karpathy-supply-chain-hygiene

スキル 11：サプライチェーンとセキュリティの衛生管理

ソース：https://x.com/karpathy/status/2036487306585268612 「ソフトウェアの恐怖：litellm の PyPI サプライチェーン攻撃」— 約 2.8 万件の「いいね」

基本原則

すべての依存関係は、自分が作っていない扉です。そして、誰が保守しているのかも分かりません。

Karpathy が警告した litellm のインシデントでは、広く使われている LLM ライブラリが、その推移的依存関係を通じて侵害されました。プロジェクトに litellm を取り込んでいた場合、影響を受ける可能性がありました。手遅れになるまで、litellm が自分のスタックに含まれていることすら知らなかったかもしれません。

Karpathy の対応策は、依存関係を最小限にし、シンプルな実装を優先し、すべてを監査することです。

依存関係の完全な監査

デプロイ前、または依存関係の更新後に、すべてのプロジェクトで次を実行します。

Perform a full supply chain security audit for this project.

Dependency file contents:
[PASTE requirements.txt / package.json / Gemfile / go.mod]

For each direct dependency, analyze:
1. Maintainer health: single maintainer? Last commit? GitHub stars?
2. Transitive depth: how many packages does it pull in?
3. Install-time code execution: does it run arbitrary code on install?
4. Network calls on import: does importing trigger outbound connections?
5. Version pinning: are we using exact versions or ranges?

Risk assessment per package:
- HIGH RISK: (list criteria)
- MEDIUM RISK: (list criteria)  
- LOW RISK: (list criteria)

Priority actions: [what to fix first]

インストール前の 5 分チェック

新しいパッケージを追加する前に、次を実行します。

Security pre-check for: [PACKAGE NAME] v[VERSION]

1. PyPI/npm stats: weekly downloads? Known? Established?
2. GitHub: https://github.com/[owner/repo] — stars, last commit, open issues?
3. Transitive deps: run `pip show [package]` or `npm ls [package]` — how deep does it go?
4. setup.py / postinstall: does it run code on install?
5. Import-time behavior: what does `import [package]` actually do?

Risk verdict: SAFE / VERIFY_FURTHER / AVOID
Alternative: if risky, what can I use instead or implement myself?

requirements ファイルの強化

緩やかな requirements ファイルを、バージョンを固定して監査済みのものに変換します。

Harden this requirements.txt / package.json for production security.

Current file:
[PASTE FILE]

Output a new version that:
1. Pins all packages to exact versions (== not ~=)
2. Adds a comment for each package: what it's used for, why we need it
3. Flags any packages that could be eliminated with minimal effort
4. Groups by category: core / dev / testing
5. Adds a header comment with: last audited date, total dep count, audit command to run

Also: what command should I run to check for known vulnerabilities?

依存関係を最小限にする考え方

パッケージを使って追加しようとしている機能ごとに、次を確認します。

I'm about to add [PACKAGE] to solve [PROBLEM].

Before I do: help me evaluate if I should implement this myself instead.

The function I need: [SPECIFIC FUNCTION/CAPABILITY]

Can this be implemented with:
- Python stdlib only (in < 50 lines)?  YES/NO
- One simple function I can paste inline?  YES/NO

If yes to either: write the minimal implementation I need.
If no: confirm the package is the right choice and suggest the safest way to import it.

コンテナ化と分離のテンプレート

外部依存関係を取り込むすべてのプロジェクトで、次を使います。

# Dockerfile template — minimal, audited, isolated
FROM python:3.11-slim  # pin exact base image

# Create non-root user
RUN useradd -m -u 1000 appuser

WORKDIR /app

# Copy ONLY requirements first (layer caching)
COPY requirements.txt .

# Install with hash verification
RUN pip install --no-cache-dir --require-hashes -r requirements.txt

# Copy application code
COPY --chown=appuser:appuser . .

USER appuser

CMD ["python", "app.py"]

# requirements.txt with hashes (generate with pip-compile --generate-hashes)
requests==2.31.0 \
    --hash=sha256:58cd2187423839823... \
    --hash=sha256:942c5a758f98d79...

インシデント対応チェックリスト

サプライチェーンの侵害を発見した場合：

IMMEDIATE (within 1 hour):
- [ ] Identify: which version of which package is compromised?
- [ ] Check: is this version in our requirements.txt / lock file?
- [ ] Check: is this version installed in any running service?
- [ ] Isolate: take affected services offline if credentials could be exposed

SHORT-TERM (within 24 hours):
- [ ] Rotate: any credentials, tokens, API keys that ran in the affected environment
- [ ] Audit: what data could have been accessed/exfiltrated?
- [ ] Update: pin to a safe version or remove the package
- [ ] Scan: check all other packages for similar issues

LONG-TERM:
- [ ] Add automated scanning (pip-audit, npm audit, Dependabot)
- [ ] Implement hash pinning for critical projects
- [ ] Consider: can we eliminate this dependency entirely?

スキャンコマンドのリファレンス

# Python
pip-audit                           # check for known vulns
pip freeze | pip-audit --stdin      # audit installed packages
safety check                        # alternative scanner

# Node.js  
npm audit
npm audit fix                       # auto-fix where safe

# Check transitive deps
pip show [package]                  # see direct deps
pip-tree [package]                  # see full tree

# Generate hashed requirements
pip-compile --generate-hashes requirements.in

ワークフロー

アイデアからリリースまでのワークフローに属します（第 4 ステップ）

位置	上流	下流
第 4 ステップ（セキュリティチェック）	karpathy-minimalism（スリム化後）	karpathy-vibe-to-agentic（最終仕上げ）

完全な流れ：idea-files → agentic-engineering → minimalism → supply-chain-hygiene → vibe-to-agentic

プロンプトの契約

Audit this dependency before I install it: <PACKAGE_NAME> v<VERSION>. Produce: 1) Transitive dependency count and tree, 2) Maintainer activity (last commit, bus factor), 3) Known CVEs or security advisories, 4) Any postinstall hooks or network calls on import, 5) Safer minimal alternative (or "implement yourself in N lines"), 6) Pinned install command if approved. Risk score: LOW/MEDIUM/HIGH. Recommendation: USE/AVOID/IMPLEMENT_YOURSELF.

検証チェックリスト

• すべての依存関係でバージョンが固定されています（>= ではなく ==）。
• 推移的依存関係の数を確認しました。
• postinstall フックがないか、その内容を確認済みです。
• 保守担当者が 1 人だけのパッケージにリスクの印を付けました。
• リスクの高い依存関係に対し、自前で実装する代替案を用意しました。
• lockfile（requirements.txt / package-lock.json）をリポジトリにコミットしました。