1．「SECURITY.md」を追加する

　最初に終わらせたいのが「SECURITY.md」ファイルの追加だ。これは、脆弱性を見つけた人がどこに報告すればよいかを示す文書である。

　SECURITY.mdがなければ、善意の報告者は公開Issueに投稿するか、メンテナー個人の連絡先を探すしかない。公開Issueに脆弱性情報が書き込まれれば、修正前の脆弱性情報が外部に見えてしまう恐れがある。

　SECURITY.mdの内容は複雑でなくてよい。連絡用メールアドレス、報告対象となる不具合の範囲、報告時に添えてほしい情報などを記載するだけでも効果がある。カツィオルーデス氏は、「Linux」のシステム管理ソフトウェア群「systemd」のセキュリティポリシーを参考例として挙げている。再現手順の扱いや対応体制への期待値が明確で、24時間365日の対応チームを前提にしていない点が実用的だという。

2．「Private vulnerability reporting」を有効化する

　SECURITY.mdが「どこに報告すればよいか」を示すものだとすれば、「Private vulnerability reporting」（PVR）は、非公開で脆弱性情報を報告する場を提供する機能だ。

　PVRを有効にすると、研究者や利用者はリポジトリに対して非公開のセキュリティアドバイザリを作成できる。メンテナーは公開前に内容を確認し、修正や開示のタイミングを管理できる。設定は「Settings」→「Security」からチェックボックスを有効化するだけで済む。

　カツィオルーデス氏は、時間が限られている場合でも、SECURITY.mdとPVRの2つを優先して有効化すべきだとしている。どちらも無料で、コミュニティに対して「脆弱性報告を受け付ける体制がある」と示す分かりやすいシグナルになる。

3．Secret scanningとpush protectionを有効化する

　次に重要なのが、認証情報の流出を防ぐ「Secret scanning」と「push protection」だ。

　APIキーやトークン、パスワードなどの秘密情報が誤ってリポジトリに含まれると、被害は大きくなりやすい。GitHubに特化したセキュリティツールを提供するGitGuardianが公開している調査レポート「State of Secrets Sprawl 2026」によると、2025年にGitHubの公開リポジトリ上で新たに漏えいしたAPIキーやトークンなどの秘密情報は2865万件に上り、前年から34％増加した。AIコーディングツールを使って生成、修正したコードでは、通常より高い頻度でAPIキーやトークンなどの認証情報が誤ってリポジトリに含まれているという。

　IBMが公開している「2025 Cost of a Data Breach Report」では、データ侵害の平均コストは世界全体で444万ドル、米国では1022万ドルとされている。秘密情報の漏えいは、単なる設定ミスではなく、重大な事業リスクになり得る。

　Secret scanningは、リポジトリ内に含まれたキーやトークンを検出するためのものだ。push protectionを併用すれば、秘密情報がリポジトリにプッシュされる前にブロックできる。公開リポジトリだけでなく、非公開リポジトリでも有効だ。いったん秘密情報が開発者のローカル環境を離れれば、リポジトリにアクセスできる人全員に見えてしまうためだ。

4．Dependabotとdependency reviewを有効化する

　プロジェクトのリスクは、自分たちが書いたコードだけにある訳ではない。多くのプロジェクトは、数十から数百の外部パッケージに依存している。

　「Dependabot」は、依存しているパッケージに既知の脆弱性が見つかった場合に通知する機能だ。一方、「dependency review」は、プルリクエスト内で追加または更新される依存関係を確認し、その中に公開済みのアドバイザリがあるかどうかを示す。

　この2つを有効化すれば、Node.jsやJavaScriptプロジェクトの設定ファイル「package.json」などの変更差分を眺めるだけでは分かりにくい依存関係のリスクを、短時間で確認できる。特にプラグインやライブラリを多用するプロジェクトでは、既知の脆弱性を持つパッケージを放置しないための基本設定になる。

5．Code scanningを有効化する

　「Code scanning」は、リポジトリに対して静的解析を実行し、実際の脆弱性につながりやすいコードパターンを検出する機能だ。SQLインジェクションやコマンドインジェクションに加え、単一形式のデータに変換したデータを元の形式に戻す「デシリアライズ」の処理を悪用される恐れがあるコードなどを見つけるのに役立つ。

　GitHubのセキュリティ機能である「Code scanning」は、リポジトリ内のコードを自動解析し、脆弱性につながる恐れのある記述を検出する。

　解析には「CodeQL」という仕組みを利用でき、通常のソースコードだけでなく、GitHub Actionsのワークフローに危険な設定が含まれていないかどうかも確認できる。

　GitHubは2019年から、オープンソースプロジェクト向けにCode scanningを無料で提供している。現在はリポジトリの「Security and Quality」タブでデフォルト設定を選ぶだけで、細かな設定をしなくても利用を始められる。

　メンテナーがこの設定を避けがちな理由は、「複雑な設定が必要そう」に見えるためだ。だが、デフォルト設定ではリポジトリの言語に応じて適切なクエリパックが選ばれ、プルリクエストごとに解析が実行される。最初の導入ハードルは高くない。

6．デフォルトブランチの「Branch protection」を有効化する

　最後に有効化すべきなのがBranch protectionだ。具体的には、mainブランチなどに直接プッシュできないようにし、マージ前にプルリクエストと最低1人の承認を必須にする。

　この設定は目立たないが、効果は大きい。認証情報が侵害された場合、混乱したコントリビューターが誤った変更を加えた場合、あるいは疲れたメンテナー自身が本番相当のブランチに直接変更を入れそうになった場合の最後の防波堤になる。

　Branch protectionは、他の5つの設定を実効性のあるものにする役割も担う。Dependabotの警告やCode scanningの検出結果があっても、マージを止められなければ単なる通知で終わってしまう。ブランチ保護を組み合わせることで、セキュリティチェックを開発フローに組み込める。

無料設定でも「攻撃しにくいプロジェクト」にはできる

　これら6つの設定は、プロジェクトを完全に安全にするものではない。だが、脆弱性報告の受け皿を整え、秘密情報の漏えいを防ぎ、依存関係やコードのリスクを検出し、危険な変更をmainブランチに直接入れない仕組みを作ることで、攻撃者が狙いにくいプロジェクトに近付けることが可能だ。

　重要なのは、専任のセキュリティチームがなくても始められる点だ。カツィオルーデス氏は、これらの設定は無料で利用でき、30分未満で更新できるとしている。メンテナーに求められるのは、完璧な防御ではなく、まず「開いたままの扉」を閉じることだ。