依存関係の「無法地帯」をコード化して封じ込める：cargo-denyによる防衛戦略
Rustの `Cargo.toml` に一行追加するだけで、世界中の有志が書いた膨大なコードをプロジェクトに取り込める――これはRustの最大の強みですが、同時に「サプライチェーン攻撃」や「ライセンス違反」という現代のDevOpsにおける最大の急所でもあります。
多くの現場では、脆弱性やライセンス問題を「個人の善意」や「PRレビュー時の目視」に依存しています。しかし、数百の依存クレートを抱える商用プロダクトにおいて、それはもはや破綻した設計です。本稿では、`cargo-deny` を単なるチェックツールとしてではなく、「開発速度を落とさずに信頼性を担保するゲートキーパー」としてCI/CDパイプラインに深く組み込む手法を伝授します。
—
1. なぜ「ツールによる自動ゲート」が不可欠なのか
OSSの脆弱性データベースである `RUSTSEC` は日々更新されています。手動チェックでは、昨日まで安全だった依存関係が今日から脅威に変わる「時限爆弾」を見逃します。
`cargo-deny` をCIに組み込む意義は、「人間が法務やセキュリティの細かなルールを暗記しなくても、コードを書くことに集中できる環境を強制する」点にあります。これがチームの心理的安全性を高め、結果として開発スピードの加速に繋がります。
2. 戦略的設定ファイル：`deny.toml` のベストプラクティス
多くの人がデフォルト設定をそのまま使いますが、商用開発で真価を発揮させるには「厳格さと柔軟性の両立」が必要です。以下は、私が大規模プロダクトで採用している、最も堅牢な構成例です。
deny.toml – 依存関係の品質管理ゲート
[advisories]
RUSTSECデータベースから脆弱性をチェック
vulnerability = “deny”
未修正の脆弱性に対する猶予期間（日数）
修正パッチが出るまでの間、開発を止めないための現実的な戦略
notice-period = “7 days”
[licenses]
ライセンスのホワイトリスト定義
allow = [
“MIT”,
“Apache-2.0”,
“BSD-3-Clause”,
]
未知のライセンスやコピーレフト系（GPL等）は即座にブロック
default = “deny”
[bans]
特定のクレートのバージョンを強制的に絞る
依存関係の爆発（dependency hell）を防ぐための制約
multiple-versions = “deny”
明示的に禁止するクレート（例：非推奨やセキュリティリスクの高いもの）
deny = [
{ name = “unsafe-crate-name” },
]
[sources]
信頼できないソースからのクレートを遮断
allow-git = false
allow-path = true
【アーキテクトの知見】なぜこの設定なのか？
- `notice-period` の活用: 脆弱性が発見された瞬間にビルドを全停止させると、開発者の生産性が著しく低下します。重要度に応じて「7日間」の猶予を与えることで、パッチのリリースを待つ余裕を持たせつつ、放置を防ぐ運用が可能です。
- `multiple-versions` の禁止: Rustのコンパイル時間は、同じクレートの異なるバージョンが混在することで劇的に悪化します。これを `deny` することで、バイナリサイズとコンパイル時間を最適化する副次効果も狙っています。
—
3. CI/CDパイプラインへの統合：開発速度を最大化する戦略
GitHub Actions等のCIで `cargo-deny check` を走らせる際、単に「エラーで止める」だけでは不十分です。以下の工夫で、開発者のストレスを最小化してください。
.github/workflows/security.yml
jobs:
security-audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install cargo-deny
run: cargo install cargo-deny
- name: Run audit
# –all-featuresを付けるのが鉄則。
# 特定の機能フラグでのみ脆弱性が現れるケースを逃さないため
run: cargo deny check –all-features
プロのテクニック:
ローカル開発時、`cargo-deny` のエラーでビルドが止まるのが面倒な場合は、`pre-commit` フックを活用してください。コミットする瞬間に気づかせることで、CIを回して「Redになったから修正して再プッシュ」という手戻りの時間をゼロにできます。
—
4. チーム開発で役立つ「設定共有化」と運用ルール
ルールはツールだけでは守れません。以下の運用を徹底してください。
1. `deny.toml` はプロジェクトのルートに配置し、リポジトリにコミットする: 設定はコードの一部です。CIとローカルで異なる基準が走ることは絶対に避けなければなりません。
2. `cargo deny fix` を活用せよ: 依存関係の問題が見つかった際、手作業で修正するのは時間の浪費です。`cargo deny fix` コマンドで、設定に従った自動修正を試みる文化を作りましょう。
3. 例外は「理由」と共に記述する: どうしても特定のGPLクレートを使わなければならない場合は、`deny.toml` 内の `[licenses.exceptions]` に、誰がいつ承認したかのコメントと共に明記します。これにより、監査時に「なぜこれが入っているのか？」と悩む必要がなくなります。
—
最後に：ゲートキーパーは「敵」ではなく「道標」である
`cargo-deny` を導入した当初は、大量のエラーに驚くかもしれません。しかし、それは「これまで見えていなかったリスク」が可視化された証拠です。
「品質の低いコードを入れない」という制約は、逆説的に「一度取り込んだ依存関係を信頼して開発に集中できる」という最高の自由を生みます。
このツールを使いこなすことは、単なるセキュリティ対策ではありません。依存関係という複雑な樹形図を管理下に置き、プロダクトの寿命を延ばすためのアーキテクチャ設計そのものなのです。明日からのCIに、このゲートを組み込んでください。あなたのチームが、より速く、より安全にコードを出荷できるようになることを約束します。