Dependabot トリアージ
機能概要
「Takumi」は Slack や WebUI を通じて手動で仕事を依頼できるだけでなく、イベント駆動でレビューを行う機能も提供していま す。
具体的には、GitHub で Dependabot が有効化されている場合に、Dependabot が作成したプルリクエスト(PR)を自動で精査し、セキュリティ的な観点から安全かどうかを判断します。
継続的な依存関係の更新はセキュリティの向上に役立ちますが、大量に生成されたPRを一つ一つ手動で確認し、セキュリティリスクがないかを分析することは大きな負担となります。
Takumiは、この課題を解決します。人間の代わりに自動的かつ迅速にセキュリティ分析を行い、リスクを検知・判断することで、チームの負担軽減とプロジェクトの安全性向上に貢献します。
設計思想
本機能は「脆弱性を見逃さない」ことを最優先に開発されています。そのため、安全な更新についても「問題がある可能性がある」と報告する場合があります。
理由として、重大な脆弱性の見逃しはセキュリティインシデントに直結する可能性を高め、その対応コストは誤検知を確認するコストを大幅に上回るためです。
Takumiの分析は、公開されている脆弱性情報と、お客様のソースコードを読み解くホワイトボックス検証などを組み合わせた独自のアプローチに基づいています。
しかしながら、このアプローチには制約も存在します。例として、公開されている情報は時として、脆弱性の具体的な説明が乏しい場合や、その脆弱性を再現する方法などが不足している場合があります。
このような制約があるからこそ、Takumiは偽陰性(実際の脅威の見 逃し)を最小限に抑えることに注力しています。言い換えると、偽陽性を許容していると言えます。
その結果、偽陽性(ノイズとなりうる場合)を許容している側面もありますが、より精度の高い分析を実現するため、日々継続的な研究開発に取り組んでいます。
実行フロー
DependabotがPRを作成すると、Takumiは以下のステップを自動的に実行します。
- PRの監視: GitHubでDependabotがPRを作成すると、Takumiがこれを検知し、即座に分析を開始します。
- 分析の実行: PR内の依存関係について以下の分析を行います。
- セキュリティに関連するか判断(フェーズ1): PRの内容がセキュリティ分析の対象であるかどうかを判断します。セキュリティとは関係のない更新と判断した場合は、その時点で分析を中断し、不必要なクレジットの消費を防ぎます。
- 既知の脆弱性の特定(フェーズ2): ライブラリにCVEやGHSAといった主要なデータベースに登録されている脆弱性がないかを確認します。
- コードベースにおける悪用可能性の分析(フェーズ3): 脆弱性がお客様のコードベースで実際に悪用可能かどうかを分析・判断します。
- リスクの評価: 脆弱性の深刻度と悪用可能性を総合的に評価し、セキュリティリスクを判断します。
- 分析結果の通知: 分析結果をSlackに直接投稿します。重大かつ悪用可能な脆弱性 が発見された場合は、チャンネル全体へ即座に通知し、迅速な対応を促します。
使用方法
本機能を利用するには、外部連携(GitHub)と Takumi の設定を完了している必要があります。詳細は以下のページをご参照ください。
上記の設定がされていること確認をしてください。その後、以下の画面のようにダッシュボードから、対象の Slack チャンネルで 「Dependabotのトリアージ」 を有効化してください。

この時、レビュー結果の表示言語として、日本語または英語を選択してください。
以上で設定は完了です。これより、Dependabot が PRを作成すると、以下のようなメッセージが該当チャンネルに送信されます。

レビュー結果は最終的にスレッド内に送信されます。以下は、レビュ ー対象の PR がセキュリティ関連ではないと判断された場合のメッセージ例です。

以下は、レビュー対象の PR が特定の脆弱性に関連し、悪用可能と判断された場合のメッセージ例です。

レビュー結果
セキュリティへの影響度に基づいて、PRを内部的に4段階で分類します。この評価は、お客様が次に取るべき対応を判断するのに役立ちます。
以下に、分類ごとの詳細と推奨される対応を説明します。
- SECURITY_CRITICAL
- 重大または高深刻度の脆弱性であり、高リスクと判断され、かつ実際にコードベースで悪用可能と判断されたものです。
- チャンネルに緊急早急な対応が必要であることを通知し、即座のレビューとパッチ適用を強く推奨します。
- SECURITY_HIGH
- 高リスクと判断された、重大・高深刻度の脆弱性ですが、現時点のコードベースでは悪用可能ではないものです。
- メッセージはスレッド内に投稿されます。即座の対応は不要ですが、速やかなレビューを推奨します。
- SECURITY_MODERATE
- 中程度のリスクと判断された、中・低深刻度の脆弱性です。
- メッセージはスレッド内に投稿され、必要に応じたレビューを推奨します。
- IRRELEVANT
- 最終的な分類が「セキュリティに関連しない」と判断されたものです。
- メッセージはスレッド内に投稿されます。通常のメンテナンス更新として対応することを推奨します。
悪用可能と判断された重大な脆弱性の場合のみ、チャンネルにメッセージをブロードキャストします。 それ以外の場合、Takumi からの通知はスレッド内にのみ投稿されます。
これは、普段の業務に不要なノイズを生み出すことなく、対応が必須なセキュリティリスクにチームが迅速かつ確実に気づけるようにするためです。
PR の自動クローズ機能
Takumi は分析結果を PR に直接コメントすることができます。加えて、最終的な分析結果に基づいて対象の PR を自動でクローズすることも可能です。 この機能により、効率的に PR を自動的に処理し、開発者の手動管理の負担を軽減します。
PR 処理モードの設定方法
Takumi は 3 つの PR 処理モード(保守的、バランス、積極的)を提供しています。各モードは、セキュリティリスクの評価結果に基づいて、どの PR を自動的にクローズするかを決定します。
GitHub 書き込み権限の設定
PR を自動的にクローズする機能を使用するには、現在連携中の GitHub App に加えて、新たに書き込み処理専用の GitHub App との連携が必要です。
書き込み処理専用の GitHub App を連携するには:
- 「設定」->「サービス連携」タブを開きます
- GitHub 連携の「書き込み権限を有効化」をクリックします
- 既存の設定と同様に対象の GitHub 組織にインストールします

処理モードの選択
PR 処理モードは、各 Slack チャンネルごとに設定できます。
- ダッシュボードから本機能を有効化しているチャンネルの設定画面を開きます
- 「PR 処理モード」から、以下のいずれかを選択します :
- 保守的モード
- バランスモード
- 積極的モード
- 設定を保存します

デフォルトでは 保守的モード が設定されています。後述の説明を読んだ上で必要に応じて変更してください。
各処理モードの違い
Takumi は 3 つの PR 処理モードを提供しています。チームの方針やセキュリティ要件に応じて、最適なモードを選択してください。
- 保守的モード
- PR を一切自動クローズしません。 Takumi は分析結果のコメントのみを投稿します。
- バランスモード
- 低リスクのセキュリティ更新(SECURITY_MODERATE)のみをクローズします。
- 積極的モード
- Takumi が悪用不可能と判断したセキュリティ更新(SECURITY_MODERATE、SECURITY_HIGH)をクローズします。
以下の表は、各分類に対する各モードの動作をまとめたものです。
| 分類 | 保守的モード | バランスモード | 積極的モード |
|---|---|---|---|
| IRRELEVANT | keep | keep | keep |
| SECURITY_MODERATE | keep | close | close |
| SECURITY_HIGH | keep | keep | close |
| SECURITY_CRITICAL | keep | keep | keep |
どのモードを選択しても、以下の動作が保証されます:
- SECURITY_CRITICAL(悪用可能な脆弱性)は自動クローズされません
- IRRELEVANT(非セキュリティ更新)は自動クローズされません
- 分析コメントは全てのモードで投稿されます
- 書き込み用 GitHub App を連携していない場合 PR への操作は行われません(PR へのコメントを含む)
トリアージ精度
当社では、公開されている複数の脆弱性情報に基づき、実際に攻撃が可能な状態(悪用可能な状態)を再現した複数のサンプルプログラムを独自に構築し、ベンチマークに使用しています。
データセットの概要
最新のベンチマークでは、Dependabot が作成したPR(合計 21 件)をデータセットとして使用しています。
このデータセットは、Takumi が「早急な対応が必要」と判断すべきPR(9 件)と、「リスクが低いもしくは無い」と判断すべきPR(12 件)で構成されています。
なお、「早急な対応が必要」なPR (9 件) には、Log4j に関する脆弱性や Next.js における認証バイパスなど、影響度が大きい脆弱性を修正するケース等が含まれています。
ベンチマーク結果
このデータセットに対し、Takumi のトリアージ精度は以下の通りです。
| メトリクス | 結果 |
|---|---|
| 所要時間 | 1.84 時間 |
| 精度 | 95.2 % |
| 真陽性 (TP) | 100 % (9 件) [^1] |
| 偽陰性 (FN) | 0 % (0 件) [^1] |
| 真陰性 (TN) | 91.7 % (11 件) [^2] |
| 偽陽性 (FP) | 8.3 % (1 件) [^2] |
[^1]: 「早急な対応が必要」のPR (9 件) が基準
[^2]: 「リスクが低いもしくは無い」PR (12 件) が基準
ベンチマークの結果、Takumi はこのデータセットにおいて、以下の 2 点で優れた性能を持つと言えます。
脆弱性を見逃さない
「早急な対応が必要」なケースでは偽陰性(見逃し)は 0 件でした。これは「設計思想」で言及している「脆弱性を見逃さない」という本機能の最優先事項を達成していることを示しています。
レビュー業務の大幅な削減
「リスクが低いもしくは無い」ケースでは 12 件のうち 11件(91.7 %) を正しく判別し、開発者のノイズになり得る件数を大幅に抑えています。
また工数削減効果を試算します。仮に、人間が手動でレビューする場合、単純な更新(12 件)に 10 分/件、脆弱性調査が必要な更新(9 件)に 30 分/件かかると仮定すると、推定される所要時間の合計は 6.5 時間に達します。
これに対し、Takumi は 1.84 時間で 21 件すべてのトリアージを完了しました。 このデータセットにおいて、Takumi は人間が手動で行う場合に比べてトリアージ工数を約 72 % 削減したと試算できます。
クレジット消費(推定コスト)
実際の利用データに基づく、各ケースの推定コストは以下の通りです。
-
シンプルな更新(早期終了): 0.01-0.49 credits
- セキュリティに関連しない変更など、フェーズ1で終了するケース
-
完全な詳細分析: 0.50-1.00 credits
- コードベースの調査を含む、全3フェーズの悪用可能性分析を実行するケース
これらの値は概算であり、正確なコストを保証するものではありません。 実際のコストは、コードベースの複雑さや検出された脆弱性の数、その他の要因により変動します。
Takumiの詳細な活用方法については、Takumi を効果的に活用するにはをご確認ください。