Supply Chain Risk Auditor

ユーザーが「audit this project's dependencies」と言ったときに起動します。

使用する場合

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

使用しない場合

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

目的

プロジェクトのすべての依存関係を体系的に評価し、悪用またはテイクオーバーのリスクが高いことを示す危険信号を特定します。これらの問題に関する概要レポートを生成します。

リスク基準

以下のリスク要因のいずれかを持つ場合、依存関係は高リスクと見なされます:

• 単一メンテナまたは少数の個人チーム - プロジェクトが主に単一の個人、または少数の個人によってメンテナンスされている。プロジェクトが Linux Foundation などの組織、または Microsoft などの企業によって管理されていない。その個人が sindresorhus または Drew Devault のようなエコシステムの極めて多作で有名な貢献者である場合、リスクは軽減されますが排除されません。逆に、その個人が匿名である、つまり GitHub アイデンティティが実際の身元と容易に結びつかない場合、リスクは著しく増加します。根拠: 開発者が買収またはフィッシングされた場合、一方的に悪意のあるコードをプッシュできます。left-pad インシデントを参照してください。
• メンテナンスされていない - プロジェクトが古い (長期間更新されていない) または明示的に非推奨/アーカイブされている。メンテナが README.md または GitHub issue にプロジェクトが非アクティブ、スタッフ不足、または新しいメンテナを求めていることを記載している可能性があります。プロジェクトの GitHub リポジトリは、メンテナが応答していないバグやセキュリティ問題を指摘する多数の issue を持つ可能性があります。機能リクエスト issue はカウント対象ではありません。根拠: プロジェクトで脆弱性が特定された場合、タイムリーにパッチが適用されない可能性があります。
• 低い人気度: プロジェクトの GitHub スター数やダウンロード数が、ターゲットが使用する他の依存関係と比較して相対的に低い。根拠: ユーザーが少ないほど、プロジェクトに目を向ける目が少なくなります。悪意のあるコードが導入された場合、タイムリーに検出されません。
• 高リスク機能: プロジェクトが FFI、デシリアライゼーション、サードパーティコード実行など、その性質上悪用されやすい機能を実装している。根拠: これらの依存関係はターゲットのセキュリティ体制の鍵となり、高い精査の基準を満たす必要があります。
• 過去の CVE の存在: プロジェクトが高いまたは重大な severity の CVE を持っている、特にその人気度と複雑さに比べて大量にある。根拠: これは必ずしも極めて人気のあるプロジェクトにとって懸念事項の指標ではありません。そのようなプロジェクトはより多くの精査の対象であり、したがってより多くのセキュリティ研究の対象となっています。
• セキュリティ連絡先の欠落: プロジェクトに .github/SECURITY.md、CONTRIBUTING.md、README.md などにセキュリティ連絡先がリストされていない、またはプロジェクトの web サイト (存在する場合) に別途リストされていない。根拠: 脆弱性を発見した個人は、安全でタイムリーな方法でそれを報告するのに困難に直面します。

前提条件

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

ワークフロー (初期設定)

目的を達成するために:

1. ワークスペース用に .supply-chain-risk-auditor ディレクトリを作成します
   • このディレクトリに results-template.md に基づいた results.md レポートファイルを開始します
2. 直接依存関係のすべての git リポジトリを検索します。
3. git リポジトリエントリを URL に正規化します。つまり、それらが name/project 形式のみの場合、github URL を先頭に追加していることを確認します。

ワークフロー (依存関係監査)

1. 初期設定で特定したリポジトリを持つ各依存関係について、上記のリスク基準に従ってそのリスクを評価します。
   • GitHub issue をカウントするなどのアクションが必要な基準について、gh ツールを使用して正確なデータをクエリします。引用する数値 (スター数、オープン issue 数など) が正確であることが極めて重要です。~ 記号を使用して issue とスターの数を丸めることができます。例えば「~4000 stars」。
2. 依存関係が上記のリスク基準のいずれかを満たす場合、results.md の High-Risk Dependencies テーブルに追加し、高リスクとしてフラグを立てた理由を明確に記載します。簡潔さのために、低リスク依存関係はスキップしてください。少なくとも 1 つのリスク要因を持つ依存関係のみを記載してください。「組織がサポートしている (低リスク)」依存関係などのリスク要因の「対面」を記載しないでください。レポートから依存関係が欠落していることが、それが低またはノーリスクであることの指標になります。

ワークフロー (監査後)

1. High-Risk Dependencies テーブルの各依存関係について、同じまたは同様の機能を提供するがより人気があり、より良くメンテナンスされているなど、代替依存関係で Suggested Alternative フィールドを埋めます。利用可能な場合は、直接の後継者とドロップイン交換を優先してください。提案の短い根拠を提供してください。
2. Counts by Risk Factor テーブルで各リスク要因カテゴリの合計をメモし、Executive Summary セクションで全体的なセキュリティ体制をまとめます。
3. Recommendations セクションで推奨事項をまとめます

注: results-template.md に記載されているセクション以外は追加しないでください。