導入: なぜ公開リポジトリでの脆弱性修正は危険なのか
OSSの運用において、脆弱性の報告を受けた際、不用意にパブリックなリポジトリでIssueやPull Request（PR）を作成することは極めて危険です。修正途中のコードや議論の内容が公開されると、悪意のある攻撃者に「どこを修正すれば脆弱性が塞がるか（＝どこが弱点か）」を教えることになり、修正が完了する前に攻撃される「ゼロデイ攻撃」を誘発するリスクがあるからです。本記事では、この課題を解決するためのGitHub標準機能「Security Advisories」と「プライベートフォーク」を活用した安全な運用手順を解説します。
基礎知識: Security Advisories と プライベートフォークとは
GitHub Security Advisoriesは、リポジトリの脆弱性を安全に報告・管理するための公式機能です。この機能を使うと、メンテナーと報告者のみが参加できる隔離された空間で議論が可能です。
プライベートフォークとは、そのSecurity Advisory内に作成される一時的なプライベートリポジトリのことです。通常のフォークとは異なり、このプライベートリポジトリ内では修正コードをプッシュし、レビューを完結させることができます。修正が完了した後にマージを行うことで、公開リポジトリには「修正済みの状態」のみが反映される仕組みです。
実装/解決策: 脆弱性対応の標準的なワークフロー
1. GitHubリポジトリの「Security」タブから「Security Advisories」を作成します。
2. 脆弱性の詳細を記載し、報告者とメンテナーを招待して議論を開始します。
3. Advisory内で「Create a private temporary fork」を選択し、プライベートリポジトリを作成します。
4. プライベートリポジトリに対して修正コードをプッシュし、レビューを行います。
5. 修正完了後、Advisoryページから「Publish」を実行し、パブリックリポジトリへ修正をマージします。この際、CVE番号の発行や公開通知も同時に行えます。
サンプルプログラム: 修正確認用テストコード（例）
脆弱なコードを修正する際の検証コード例です。例えば、ユーザー入力をそのままシェルコマンドに渡している箇所を、エスケープ処理を通す形に変更するようなケースを想定します。
[修正前の脆弱な処理]
// ユーザー入力を直接実行してしまう危険なコード
const userInput = “input_data”;
exec(“ls ” + userInput); // ここが攻撃ポイント
[修正後のセキュアな処理]
const { execFile } = require(‘child_process’);
// 入力値をバリデーションし、安全な関数を使う
function secureExecute(input) {
// 許可されたパターンのみを受け付ける（ホワイトリスト方式）
const regex = /^[a-zA-Z0-9_-]+$/;
if (!regex.test(input)) {
throw new Error(“不正な入力です”);
}
// コマンド引数として安全に渡す
execFile(‘ls’, [input], (error, stdout) => {
if (error) {
console.error(“実行エラー:”, error);
return;
}
console.log(“出力:”, stdout);
});
}
応用・注意点: 現場で陥りやすい罠
修正コードの漏洩防止: プライベートフォーク内で行ったコミット履歴は、公開リポジトリにマージする際に「一つの大きなコミット」としてまとめる（Squash and Merge）ことを推奨します。これにより、修正に至るまでの試行錯誤の過程や、脆弱性の詳細を推測させるような中間コミット履歴を公開リポジトリに残さずに済みます。
依存関係の更新: 脆弱性がライブラリ経由である場合、プライベートフォーク内での修正だけでは不十分なことがあります。必要に応じて、公開リポジトリの依存関係（package-lock.json等）の更新も忘れずに行い、Dependabotによる自動更新が阻害されないよう注意してください。
コメント