なぜ誰もが依存関係クールダウンを使うべきなのか

(blog.yossarian.net)

15 ポイント投稿者 GN⁺ 2025-11-22 | まだコメントはありません。 | WhatsAppで共有

依存関係クールダウン(dependency cooldown) は、オープンソースのサプライチェーン攻撃の大半を緩和できる シンプルで効果的なセキュリティ手法
攻撃者は通常、人気のあるオープンソースプロジェクトを乗っ取って悪意あるコードを配布するが、ほとんどの攻撃は 露出期間が1週間以下 と短い
新バージョン公開後に一定期間（例: 7日）待機するクールダウンを設定すれば、自動更新による感染リスクを大幅に減らせる
Dependabot、Renovate、pnpm などはすでに クールダウン機能を標準でサポート しており、設定も簡単で追加コストもない
パッケージマネージャーのレベルでクールダウンを標準提供すれば、サプライチェーンセキュリティの強化と不要なアラートの削減 に貢献できる

サプライチェーン攻撃の構造と問題点

ほとんどの サプライチェーン攻撃(supply chain attack) は同じパターンを持つ
- 攻撃者が人気オープンソースプロジェクトの 認証情報の窃取 または CI/CD の脆弱性 を利用してアクセス
- 悪意ある変更を配布チャネル(PyPI、npm など)にアップロード
- 自動更新やバージョン固定の不備により、ユーザーが感染したバージョンをインストール
- セキュリティベンダーがこれを検知して警告し、その後パッケージリポジトリが該当バージョンを削除
(1)〜(2) 段階の間隔は長いが、(2)〜(5) 段階は 数時間〜数日以内に処理 されるため、攻撃者の活動期間は短い
最近18か月間の主要事例における 攻撃可能期間(window of opportunity)
- xz-utils: 約5週間
- Ultralytics: 12時間(1段階)、1時間(2段階)
- tj-actions: 3日
- chalk: 12時間未満
- Nx: 4時間
- rspack: 1時間
- num2words: 12時間未満
- Kong Ingress Controller: 約10日
- web3.js: 5時間
このうち8件は 1週間未満の攻撃期間 で、ほとんどはクールダウンで防げる

クールダウン(cooldown) は、新しい依存関係が公開された後、一定期間その使用を遅らせる方式
- この期間中にセキュリティベンダーが悪意の有無を検知できる
利点
- 実証的に効果があり、大規模攻撃の大半を防げる
- 実装が非常に簡単 で、ほとんどのツールで 無料で設定可能
- Dependabot の例
```
version: 2
- package-ecosystem: github-actions
  directory: /
  schedule:
    interval: weekly
  cooldown:
    default-days: 7
```
- セキュリティベンダーの前向きな行動を促す: 過剰なアラートや宣伝ではなく、迅速な検知に集中させる