GitHub Security Labのジョセフ・カツィオルーデス氏は、OSSメンテナーが短時間で有効化できる6つの無料セキュリティ設定を紹介した。
GitHubでオープンソースプロジェクトを運用する場合、コードそのものだけでなく、リポジトリの設定もセキュリティ対策として重要になる。高度な攻撃を完全に防ぐことはできないが、攻撃者にとって侵入しやすい経路を減らすことはできる。
GitHub Security Labのジョセフ・カツィオルーデス氏は2026年7月1日（米国時間）、GitHubのメンテナーが短時間で有効化できる6つの無料セキュリティ設定を紹介した。多くのメンテナーはセキュリティ専任者ではなく、設定画面やドキュメントの多さに戸惑うこともある。だが、基本設定を放置すると、自動化やスケーラビリティを生かせず、脆弱（ぜいじゃく）性が積み上がるリスクがある。
最初に終わらせたいのが「SECURITY.md」ファイルの追加だ。これは、脆弱性を見つけた人がどこに報告すればよいかを示す文書である。
SECURITY.mdがなければ、善意の報告者は公開Issueに投稿するか、メンテナー個人の連絡先を探すしかない。公開Issueに脆弱性情報が書き込まれれば、修正前の脆弱性情報が外部に見えてしまう恐れがある。
SECURITY.mdの内容は複雑でなくてよい。連絡用メールアドレス、報告対象となる不具合の範囲、報告時に添えてほしい情報などを記載するだけでも効果がある。カツィオルーデス氏は、「Linux」のシステム管理ソフトウェア群「systemd」のセキュリティポリシーを参考例として挙げている。再現手順の扱いや対応体制への期待値が明確で、24時間365日の対応チームを前提にしていない点が実用的だという。
SECURITY.mdが「どこに報告すればよいか」を示すものだとすれば、「Private vulnerability reporting」（PVR）は、非公開で脆弱性情報を報告する場を提供する機能だ。
PVRを有効にすると、研究者や利用者はリポジトリに対して非公開のセキュリティアドバイザリを作成できる。メンテナーは公開前に内容を確認し、修正や開示のタイミングを管理できる。設定は「Settings」→「Security」からチェックボックスを有効化するだけで済む。
カツィオルーデス氏は、時間が限られている場合でも、SECURITY.mdとPVRの2つを優先して有効化すべきだとしている。どちらも無料で、コミュニティに対して「脆弱性報告を受け付ける体制がある」と示す分かりやすいシグナルになる。
次に重要なのが、認証情報の流出を防ぐ「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を併用すれば、秘密情報がリポジトリにプッシュされる前にブロックできる。公開リポジトリだけでなく、非公開リポジトリでも有効だ。いったん秘密情報が開発者のローカル環境を離れれば、リポジトリにアクセスできる人全員に見えてしまうためだ。
プロジェクトのリスクは、自分たちが書いたコードだけにある訳ではない。多くのプロジェクトは、数十から数百の外部パッケージに依存している。
「Dependabot」は、依存しているパッケージに既知の脆弱性が見つかった場合に通知する機能だ。一方、「dependency review」は、プルリクエスト内で追加または更新される依存関係を確認し、その中に公開済みのアドバイザリがあるかどうかを示す。
この2つを有効化すれば、Node.jsやJavaScriptプロジェクトの設定ファイル「package.json」などの変更差分を眺めるだけでは分かりにくい依存関係のリスクを、短時間で確認できる。特にプラグインやライブラリを多用するプロジェクトでは、既知の脆弱性を持つパッケージを放置しないための基本設定になる。
「Code scanning」は、リポジトリに対して静的解析を実行し、実際の脆弱性につながりやすいコードパターンを検出する機能だ。SQLインジェクションやコマンドインジェクションに加え、単一形式のデータに変換したデータを元の形式に戻す「デシリアライズ」の処理を悪用される恐れがあるコードなどを見つけるのに役立つ。
GitHubのセキュリティ機能である「Code scanning」は、リポジトリ内のコードを自動解析し、脆弱性につながる恐れのある記述を検出する。
解析には「CodeQL」という仕組みを利用でき、通常のソースコードだけでなく、GitHub Actionsのワークフローに危険な設定が含まれていないかどうかも確認できる。
GitHubは2019年から、オープンソースプロジェクト向けにCode scanningを無料で提供している。現在はリポジトリの「Security and Quality」タブでデフォルト設定を選ぶだけで、細かな設定をしなくても利用を始められる。
メンテナーがこの設定を避けがちな理由は、「複雑な設定が必要そう」に見えるためだ。だが、デフォルト設定ではリポジトリの言語に応じて適切なクエリパックが選ばれ、プルリクエストごとに解析が実行される。最初の導入ハードルは高くない。
最後に有効化すべきなのがBranch protectionだ。具体的には、mainブランチなどに直接プッシュできないようにし、マージ前にプルリクエストと最低1人の承認を必須にする。
この設定は目立たないが、効果は大きい。認証情報が侵害された場合、混乱したコントリビューターが誤った変更を加えた場合、あるいは疲れたメンテナー自身が本番相当のブランチに直接変更を入れそうになった場合の最後の防波堤になる。
Branch protectionは、他の5つの設定を実効性のあるものにする役割も担う。Dependabotの警告やCode scanningの検出結果があっても、マージを止められなければ単なる通知で終わってしまう。ブランチ保護を組み合わせることで、セキュリティチェックを開発フローに組み込める。
これら6つの設定は、プロジェクトを完全に安全にするものではない。だが、脆弱性報告の受け皿を整え、秘密情報の漏えいを防ぎ、依存関係やコードのリスクを検出し、危険な変更をmainブランチに直接入れない仕組みを作ることで、攻撃者が狙いにくいプロジェクトに近付けることが可能だ。
重要なのは、専任のセキュリティチームがなくても始められる点だ。カツィオルーデス氏は、これらの設定は無料で利用でき、30分未満で更新できるとしている。メンテナーに求められるのは、完璧な防御ではなく、まず「開いたままの扉」を閉じることだ。
Copyright © ITmedia, Inc. All Rights Reserved.
瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓
MFA（多要素認証）を入れたから安心という常識が崩れ去っている。フィッシング集団「Tycoon2FA」が摘発されたが、脅威が完全になくなったというわけではない。
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2025年5月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10（2025年5月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年5月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
ITmediaはアイティメディア株式会社の登録商標です。
