supply-chain-risk-auditor

サプライチェーンリスク監査ツール

ユーザーが「このプロジェクトの依存関係を監査して」と言ったときに起動します。

使用する場面

• セキュリティ監査前に依存関係のリスクを評価する
• プロジェクトのサプライチェーン攻撃対象領域を評価する
• メンテナンスされていない、またはリスクの高い依存関係を特定する
• サプライチェーンに関する懸念事項の事前スコープ設定

使用しない場面

• 脆弱性のアクティブスキャン（npm audit、pip-audit などの専用ツールを使用してください）
• ランタイム依存関係の分析
• ライセンスコンプライアンスの監査

目的

プロジェクトのすべての依存関係を体系的に評価し、悪用や乗っ取りのリスクが高いことを示す危険信号を特定して、それらの問題を記載した概要レポートを作成します。

リスク基準

依存関係に次のリスク要因が一つでもある場合、リスクが高いと見なされます。

• 単独のメンテナー、または少数の個人によるチーム - プロジェクトが主に、または全面的に一人の個人、あるいは少数の個人によってメンテナンスされています。Linux Foundation のような組織や、Microsoft のような企業が管理しているプロジェクトではありません。個人が sindresorhus や Drew Devault のように、エコシステムで極めて多くの貢献をしている著名な人物であればリスクは軽減されますが、解消されるわけではありません。反対に、個人が匿名、つまり GitHub のアカウントから現実の身元を容易に確認できない場合、リスクは大幅に高まります。理由： 開発者が買収されたり、フィッシング被害に遭ったりすると、悪意あるコードを単独でプッシュできてしまいます。left-pad のインシデントを考慮してください。
• メンテナンスされていない - プロジェクトが長期間更新されておらず、停滞しているか、明示的に非推奨またはアーカイブされています。メンテナーが README.md や GitHub の issue に、プロジェクトが活動を停止している、人手が足りない、または新たなメンテナーを探していると記載している場合があります。メンテナーが対応していないバグやセキュリティ問題を報告する issue が、プロジェクトの GitHub リポジトリに多数ある場合もあります。機能リクエストの issue は対象外です。理由： プロジェクトに脆弱性が見つかった場合、適時に修正されない可能性があります。
• 人気が低い： 対象で使用されている他の依存関係と比べて、プロジェクトの GitHub スター数やダウンロード数が比較的少ない状態です。理由： ユーザーが少なければ、プロジェクトを確認する人も少なくなります。悪意あるコードが導入されても、適時に気づかれない可能性があります。
• リスクの高い機能： FFI、デシリアライズ、サードパーティコードの実行など、その性質上、特に悪用されやすい機能をプロジェクトが実装しています。理由： これらの依存関係は対象のセキュリティ対策の要となるため、厳しい精査基準を満たす必要があります。
• 過去の CVE の存在： プロジェクトに重大またはクリティカルな CVE があり、特に人気や複雑さに比べて件数が多い状態です。理由： これは必ずしも、人気が非常に高く、精査を受ける機会が多いためにセキュリティ調査の対象にもなりやすいプロジェクトで懸念事項になるとは限りません。
• セキュリティ連絡先の不在： .github/SECURITY.md、CONTRIBUTING.md、README.md などにセキュリティ連絡先が記載されておらず、プロジェクトのウェブサイトがある場合も、そこに掲載されていません。理由： 脆弱性を発見した人が、安全かつ適時に報告するのが難しくなります。

前提条件

続行する前に、gh ツールが利用可能であることを確認してください。見つからない場合は、ユーザーにインストールを依頼してください。

ワークフロー（初期設定）

1. 作業用の .supply-chain-risk-auditor ディレクトリを作成します。
   • このスキルディレクトリにある resources/results-template.md を基に、results.md レポートファイルを開始します。
2. 直接依存関係に対応するすべての Git リポジトリを見つけます。
3. Git リポジトリの項目を URL に正規化します。name/project 形式の場合は、先頭に GitHub URL を付けます。

ワークフロー（依存関係の監査）

1. 初期設定でリポジトリを特定した依存関係ごとに、上記のリスク基準に従ってリスクを評価します。
   • GitHub のオープンイシュー数のカウントなど、操作が必要な基準については、gh ツールを使用して正確なデータを照会してください。記載する数値（スター数、オープンイシュー数など）は、必ず正確であることが非常に重要です。イシュー数やスター数は、たとえば「約 4000 スター」のように、~ 記号を使って概数にしてもかまいません。
2. 依存関係が上記のリスク基準のいずれかに該当する場合は、results.md の高リスク依存関係テーブルに追加し、高リスクとしてフラグを付けた理由を明確に記載します。簡潔にするため、低リスクの依存関係は省略し、リスク要因が少なくとも 1 つある依存関係のみ記載してください。「組織の支援あり（低リスク）」の依存関係を記載する列を設けるなど、リスク要因の「反対」にあたる情報は記載しないでください。レポートに依存関係が記載されていないことを、その依存関係が低リスクまたはリスクなしであることの指標とします。

ワークフロー（監査後）

1. 高リスク依存関係テーブルに記載されている依存関係ごとに、「推奨される代替案」フィールドに、同じまたは類似した機能を持ち、より人気がある、メンテナンス状況が良好であるなどの代替依存関係を記入します。利用可能な場合は、直接の後継やドロップイン置換を優先してください。提案の簡潔な根拠も記載します。
2. リスク要因ごとの合計件数を「リスク要因別件数」テーブルに記載し、「エグゼクティブサマリー」セクションで全体的なセキュリティ状況を要約します。
3. 「推奨事項」セクションに推奨事項をまとめます。

注： resources/results-template.md に記載されているもの以外のセクションを追加しないでください。