脆弱性を見つけるのは簡単なことです。セキュリティ担当者の役割は、その修正をマージしてデプロイすることです。脆弱な依存関係に対しては、Coroidが自らアップグレードpull requestを作成し、チームがそれをレビューしてマージします。
Coroidがそれを作成するとき
「脆弱な依存関係を修正する」を有効にすると、修正が必要な重大度以上（デフォルトでは「高」）の依存関係の問題が、該当プロジェクト内で修正タスクとして作成されます：
- パッケージごとに1つのタスクとpull request、それに影響を与えるすべての勧告を対象とします。
- まず重要な問題から対処、次に「高」の問題です。
- プロジェクトあたり最大5件の修正プルリクエストが同時に開かれます（デフォルトでは最大50件）。次の修正作業は空きが出るまで待機します。
オーナーや管理者は「修正」を、公開されている勧告がある未解決の依存関係の問題に適用できます。固定バージョンがまだリリースされていない場合、「修正」機能は緩和策タスクを提供します：パッケージを削除または置き換える、パッチ適用済みのフォークを指定する、または脆弱な呼び出しを保護するなどです。
現在、npmプロジェクト向けには自動アップグレードが利用可能です。他のエコシステムの場合、該当するエコシステム向けの自動修正機能はまだ用意されていないため、「修正」機能が緩和策タスクを提供します。
費用の負担先
修正タスクにはAIモデルが使用されるため、他の作業と同様にエージェント時間が消費されます。これらは組み込みのセキュリティ修正命令の下で実行され、すべての組織に適用されます：
- 対象範囲：依存関係のアップグレードとセキュリティ上の緩和策のみで、それ以外は含まれません。
- 予算：エージェント時間のみで、デフォルトでは月間プランのエージェント時間の4分の1です。オーナーは「セキュリティ」→「設定」→「脆弱な依存関係を修正する」で、使用時間や週単位/月単位での計算方法を変更できます。
- レビューの有効期限はありません。これは常に適用されるデフォルト設定であり、更新する必要はありません。
- 優先順位：セキュリティ修正は、他の自己発起の作業よりも優先的に処理されます。
組織のデフォルト設定で「脆弱な依存関係を修正する」を無効にすると、この命令が一時停止されます。この命令は他の命令とともに品質管理 → 命令。
既に接続済みのリポジトリを持つ組織がSecurityを利用開始すると、オーナーにはベルの通知が届きます：「セキュリティ修正機能は7日後に開始します」。修正作業はその通知が送信されてから7日後に始まるため、オーナーは最初のpull requestが作成される前に機能を無効にできます。新規の組織では即座に開始されます。
修正が遅延する理由
問題の修正セクションには、待機中の理由が記載されています。主な理由は以下の通りです：
- プロジェクトの開かれているpull requestの上限数に達している;
- 命令の予算またはプランのエージェント時間が使い切られている（検出作業は継続される）；
- Mission Controlでエージェント作業が一時停止されている、または利用可能なエージェントスロットがない;
- 7日間の通知期間がまだ終了していない;
- 互換性のある修正版がまだリリースされていない、または該当エコシステムに自動修正機能がない;
- 「脆弱な依存関係を修正する」が無効になっている。
アップグレードの選定方法
脆弱なパッケージがインストールされている各場所において、Coroidはインストール済みバージョンよりも新しく、影響を与えるすべての勧告を修正できる最小のバージョンを選びます。ただし、宣言されたバージョン範囲およびメジャーバージョン内に限られ、ダウングレードは行いません。異なるメジャーバージョンを必要とするワークスペースごとに、それぞれ別のパッチ適用済みバージョンがpull request内に作成されます。推移的なパッケージは、親パッケージのアップグレードまたはパッケージマネージャーの上書き設定に従って更新されます。メジャーな変更や単一バージョンへの統合が行われる場合、その理由がpull requestに記載されます。単一のアップグレードですべてを修正できない場合、プルリクエストでは修正可能な部分だけを対応し、残りの部分は未修正として記載されます。
pull requestが含む内容
- 修正される勧告とその重大度。
- パッケージの一覧変更前と変更後で、脆弱なバージョンがなくなったことが確認できます。
- プロジェクトのチェック機能：プロジェクトのDeliveryグラフに実行可能なチェックが設定されている場合、プッシュされた変更に対してGO AHEADの結果が出るまでCoroidはpull requestを作成できません。そうでない場合、タスクはその理由とともに終了します。プロジェクトにチェック機能が設定されていない場合でもpull requestは作成され、Coroidがプロジェクトチェックを実行しなかったこと、リポジトリ自身のCIがpull request上で実行されること、および品質管理でチェックを設定する場所が記載されます。
- メジャーな変更やバージョン範囲の変更が生じた理由。
- 修正できなかった勧告が未修正として一覧表示されます。
最終的な結果は次の通りです：「人がレビューしてマージを行う。デプロイメントのステータスは、デプロイされたリビジョンをスキャンした結果のみで決定される。」この検出結果は、次回の完全なインベントリ時点でコードに反映され、各環境においてはその環境で実行されているリビジョンをスキャンした結果に基づいて修正されます。詳細はこちらをご覧ください。検出結果とそのライフサイクル。
コード上の検出結果
コード上の検出結果が発生した場合、修正ファイルに、そのプロジェクト内で修正するためのタスクを作成します。オーナーや管理者は、開いている任意のコード上の検出結果に対してこの機能を利用できます。このタスクでは、開発者にコミットメッセージおよびpull request内で攻撃内容ではなく修正内容を記載し、リグレッションテストを追加するよう求めます。このタスクは他のタスクと同様のルールに従い、エージェントの作業時間を消費します。
パブリックリポジトリ、またはCoroidが可視性を確認できないリポジトリの場合、まだ公開されていない検出結果の修正内容はそこにはコミットされません。Coroidは、オーナーまたは管理者が公開できるよう、準備済みの変更内容を非公開で保持します。詳細はこちらをご覧ください。開示。
漏洩したシークレット
漏洩した認証情報はローテーションによって修正されますが、これを実行するのはCoroidではありません。シークレットに関する検出結果の修正では、チェックリストタスクが作成されます。詳細はこちらをご覧ください。漏洩したシークレット。