Pythonサプライチェーン保護のための多層防御（Defense in Depth）実装ガイド

要点まとめ
Pythonパッケージエコシステムを狙ったサプライチェーン攻撃に対応するため、単一のコントロールに依存しない多層防御戦略が求められる。本文では、RuffのS（Bandit）ルールを活用した静的な脆弱性の遮断、uvを用いた暗号学的ハッシュベースの依存関係固定、CI環境でのpip-auditおよびSBOM（CycloneDX）生成を推奨する。パッケージ配布時には、長期APIトークンの代わりにOIDCベースのTrusted Publishingを導入し、新規パッケージ導入を意図的に遅延させる（Delayed Ingestion）ことで、悪意あるパッケージに対するコミュニティ検証の時間を確保する実務的なパイプラインを提示する。

詳細分析

• サプライチェーン攻撃ベクトルと推移的依存関係（Transitive Dependency）: 現在のPyPIには74万件を超えるパッケージが存在し、ctxドメイン乗っ取り、Ultralytics（YOLO）のCIスクリプト注入、GhostActionのトークン窃取など、大規模なセキュリティ事故が継続的に発生している。単一パッケージ（例: Flask）をインストールするだけでも、多数の推移的依存関係（例: MarkupSafeなど）が同時に導入されるため、開発者が明示的に宣言していないパッケージ群まで巨大な攻撃対象領域（Attack Surface）となる。
• 自前コード内の脆弱性を事前に遮断: 外部パッケージ以前に、まず内部コードの欠陥を防がなければならない。ハードコードされたシークレット、脆弱なハッシュアルゴリズム（MD5、SHA1）、タイムアウト未設定のネットワークリクエスト（DoSを誘発）、安全でないシリアライズ（pickle）などは、コードレビューの過程で見落とされやすい。これを防ぐため、CI/CDパイプラインおよびIDEにRuffのBanditセキュリティルールを連携し、自動検知と遮断を行うことが不可欠である。
• 依存関係の固定と遅延導入（Delayed Ingestion）: 依存関係のインストールでは単にバージョンを明記するだけでなく、パッケージの暗号学的ハッシュを固定して、ランタイム環境での改ざんを防ぐ必要がある。また、新たに配布された悪意あるパッケージが遮断されるまでのリスクを減らすため、uvの--exclude-newerフラグを使う、あるいは社内ミラーリポジトリに「7日間のインジェスト待機キュー（Ingestion Queue）」を設け、コミュニティによる一次検証を経たパッケージのみを内部ネットワークへ取り込むよう制御する戦略が有効である。
• 安全なパッケージ配布: オープンソースメンテナおよびパッケージ公開者は、窃取リスクが常に存在する静的APIトークンを廃止し、Sigstoreを活用したOIDC（OpenID Connect）ベースのTrusted Publishingへ移行すべきである。これにより、ソースリポジトリとの結び付きを暗号学的に証明するAttestationが自動生成される。

主要なコードとデータ

1. 推移的依存関係（Transitive Dependencies）の確認

# 単一パッケージ（Flask）をインストールした際に付随する見えない依存関係ツリーを確認  
uv pip install flask  
uv pip tree  
  
# Output:  
flask v3.1.0  
├── blinker v1.9.0  
├── click v8.1.8  
├── itsdangerous v2.2.0  
├── jinja2 v3.1.5  
│   └── markupsafe v3.0.2  
└── werkzeug v3.1.3  
    └── markupsafe v3.0.2  
  
2. Ruffを活用したセキュリティルールセット（Bandit）の適用  
# pyproject.toml設定例  
[tool.ruff]  
line-length = 120  
# E（Error）、F（Pyflakes）とともにS（Banditセキュリティルール）を有効化  
lint.select = ["E", "F", "S"]  
  
# Ruffの'S'ルールセットによって自動検知される代表的な脆弱パターンの例  
# FLAGGED: S301 - pickle.loads()は任意コード実行の危険がある（json.loads()推奨）  
import pickle  
data = pickle.loads(untrusted_input)  
  
# FLAGGED: S608 - 文字列フォーマットによるSQLインジェクション脆弱性  
cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'")  
  
# FLAGGED: S113 - タイムアウトが設定されていない外部リクエスト（無限待機およびDoS攻撃にさらされる）  
import requests  
response = requests.get("[https://api.example.com/data](https://api.example.com/data)")  
  
3. 遅延導入（Delayed Ingestion）による新規パッケージ制御  
# 特定日付以前（例: 7日前）に公開されたパッケージのみを依存関係としてコンパイルし、初期のマルウェア/不具合を回避  
uv pip compile --exclude-newer 2026-03-02 requirements.in -o requirements.txt  
  
4. 組織内インジェスト制御（Ingestion Control）パイプライン  
| 処理段階 | システム構成要素 | セキュリティ目的と説明 |  
|---|---|---|  
| 流入 | PyPI ➜ Ingestion Queue | PyPIに登録された新規パッケージを社内システムへ即時配布せず、待機キューに取り込む |  
| 待機 | Wait (ex. 7日) | パッケージが悪意あるものか、また脆弱性を持つかをコミュニティとセキュリティ研究者が分析するための絶対的な時間を確保 |  
| 検証 | Security Scan ➜ Approved | 待機期間終了後、既知の脆弱性（CVE）およびマルウェアスキャンを通過した場合のみ承認 |  
| 配布 | Internal Mirror ➜ Developers | 検証完了済みのパッケージだけを内部ミラーリポジトリにキャッシュし、開発チームが安全に利用できるよう許可 |