これはなに
下記リンク先に従って、GitHubのセキュリティ設定を見直したときにやったことや調べたことのメモ。 公式から「すべてのGitHubメンテナーが有効にする必要がある」と言われたら見直すよね。
ちなみに設定は6つで、30分以内に更新できるらしい。ホントかよ。
結論
パブリックリポジトリの場合、GitHubリポジトリの"Security and quality"にある設定をすべて有効化すると、リポジトリのセキュリティが向上する。
ただし、個人のプライベートリポジトリの場合は下記設定のみ有効である。
- Dependabot alerts
- Secret scanning alerts
1. SECURITY.mdファイルを追加する
これはパブリックリポジトリでのみ有用である。
SECURITY.mdファイルは、プロジェクトの脆弱性をどのように報告するかユーザーに伝えることを目的としたファイルである。公式ドキュメントによれば、「プロジェクトのバージョンと脆弱性の報告方法に関する情報を追加する」ものとのことだ。参考リンク先ではsystemdの例が紹介されている。
脆弱性の情報は公開Issueに書かれると、悪意のあるユーザーに悪用される可能性がある。そのため、公開Issueとは別の経路の報告先を用意する必要がある。この報告先の明示がリポジトリのセキュリティを高めることに繋がるらしい。
SECURITY.mdファイルは下記のいずれかに配置する1。
.githubディレクトリ- リポジトリ直下
docsディレクトリ
この設定は、各リポジトリの"Security and quality"の設定における"Security policy"に該当する。下図のようにDisabledになっている場合は、SECURITY.mdが存在していないことを表す。
上記画像で"Set up a security policy"をクリックすると、GitHub上でリポジトリ直下にSECURITY.mdを作成できる。
個人の意見だが、個人開発では、下記の内容が書かれていれば最低限問題ないと思われる。
- セキュリティ修正対象のバージョン
- 脆弱性の報告先
- 報告時に含めてほしい情報
- 公開Issueに書かないでほしいこと
- 返答にかかる時間の目安
ちなみに、脆弱性の報告先は、GitHubのPVR(Private vulnerability reporting)を使うと便利である。これについては次の項で説明する。
たとえば、拙作のPythonパッケージであるtickoでは、下記のようなSECURITY.mdを作成した。
# Security Policy
## Supported Versions
Security updates are provided for the latest major version of ticko.
| Version | Supported |
| ------- | ------------------ |
| 2.x | :white_check_mark: |
| 1.x | :x: |
Users are encouraged to upgrade to the latest release available on PyPI.
## Reporting a Vulnerability
If you discover a security vulnerability in ticko, please do not report it
through a public GitHub issue.
Instead, please report it privately using GitHub's private vulnerability
reporting feature.
When submitting a report, please include as much of the following information
as possible:
- A description of the vulnerability
- The affected version(s) of ticko
- Steps to reproduce the issue
- A minimal proof of concept, if applicable
- The potential security impact
- Any suggested mitigation or fix, if available
You can expect an initial response within 14 days.
Please allow reasonable time for the issue to be investigated and fixed before
publicly disclosing the vulnerability.
## Scope
Security reports should describe issues that have a meaningful security impact
on applications using ticko.
General bugs, timing inaccuracies, performance issues, feature requests, and
other problems without a security impact should be reported through the public
GitHub issue tracker instead.SECURITY.mdの内容自体は、リポジトリのリンクをLLMに投げれば作成してくれるので、そんなに時間はかからない。他の有用なプロジェクトの記述を真似してもよいだろう。
2. PVR (Private Vulnerability Reporting)を有効にする
これはパブリックリポジトリでのみ有用である。
PVR（Private Vulnerability Reporting）とは、GitHubのリポジトリに対して機密に脆弱性を報告するための、GitHubの機能である。GitHubで公開しているなら、脆弱性の報告は公開IssueではなくPVRを使うべきとされる。
PVRを使う場合はリポジトリの設定から有効にする必要がある。これは一瞬で設定できる。
有効化のしかたは、まず各リポジトリの"Security and quality"の設定を開き、“Private vulnerability reporting"の項を確認する。下図のようにDisabledになっている場合は、PVRが無効であることを表す。
“Enable vulnerability reporting"をクリックすると、下図のような設定画面が表示される。
この"Enable"をクリックすると有効になる。
ちなみに1と2を設定すると、リポジトリの"Security and quality"に、1で作成したSECURITY.mdの内容と"Report a vulnerability"ボタンが表示される。
3. Secret scanning alertsを有効化する
これはパブリックリポジトリ、あるいは組織所有のプライベート/内部リポジトリで有効な設定である。
Secret scanning alertsとは、GitHub上のリモートリポジトリへプッシュした際に走るシークレットスキャンである。キーやトークンといったシークレットにすべき値がリポジトリに漏れ込んでいないかをスキャンしてくれる。シークレットが漏れることを防ぐ防波堤のようなものである。
参考リンク先によると、AI支援によるコミットにより、通常の約2倍の割合でシークレットが漏洩しているらしい。怖…。
有効化のしかたは、まず各リポジトリの"Security and quality"の設定を開き、“Secret scanning alerts"の項を確認する。下図のようにEnabledになっていれば機能は有効である。
この機能が有効になっていると、シークレットの漏洩が検知されたとき、アラートが発せられるらしい2。
ちなみに、実際に漏洩が検知されたときの対応の仕方は、下記公式情報が参考になりそう。
4. Dependabotを有効化する
これはパブリック/プライベートにかかわらず有用な設定である。
Dependabotは、リポジトリが依存している外部ライブラリやパッケージに既知の脆弱性があることを警告するツールである。
たとえばpackage.jsonに記された依存関係を確認し、セキュリティ問題がある場合は警告が出る。デフォルトではメールで通知される。
執筆時点では、Dependabotには関連する5つの機能がある。
| 機能名 | 説明 |
|---|---|
| Dependency graph | 依存関係をGitHubが把握するための機能 |
| Dependabot alerts | 依存ライブラリに既知の脆弱性が見つかったとき警告する機能 |
| Dependabot security updates | 脆弱性を直すバージョンへの更新PRを自動作成する機能 |
| Grouped security updates | 複数のセキュリティ更新をまとめて1つのPRにする機能 |
| Dependabot version updates | 依存パッケージを定期的に最新版へ更新するPRを作成する機能 |
これらのうち、Dependabot version updatesだけは、脆弱性があるかどうかにかからわず最新版への更新PRを作成する。
これらのうち、個人的にはとくにDependabot alertsが最低限必要だと思っている。Dependabot alertsを使うにはDependency graphも必要であるため、これら2つを有効化することにした。
設定は、まず設定したいリポジトリの"Security and quality"の設定を開く。下図のように"Enable Dependabot alerts"のボタンが表示されている場合は有効になっていないので、このボタンをクリックする。
すると、下図のようなAdvanced Securityの設定画面に遷移するので、Dependabot alertsの項のEnableボタンをクリックする。
このとき、Dependency graphが有効化されていない場合は下図のような警告が出る。問題ないのでEnableを押す。
下図のようにDisableボタンになっていれば有効化されている。
ちなみに、上図のDependabot malware alertsも有用そうなので、個人的に有効化した。
5. Code scanningを有効化する
これはパブリックリポジトリ、あるいは組織所有のリポジトリで有効化できる。
Code scanningは、リポジトリ内のコードを静的分析し、セキュリティの脆弱性とコーディングエラーを見つけてくれる機能である。SQLインジェクションとかにフラグを付けてくれる。
CodeQLを用いたコードスキャンでは、安全ではないGitHub Actionsワークフローも検出できる。CodeQLは現在ワンクリックで使えるデフォルト設定としてGitHubに用意されている。ありがたい。
デフォルトのセットアップならすぐに設定は終わる。まず、設定したいリポジトリの"Security and quality"にある"Code scanning alerts"を確認する。 下図のように"Set up code scanning"のボタンが表示されている場合は、まだ有効化されていない。
“Set up code scanning"のボタンをクリックすると、Advanced Securityの設定画面に遷移する。設定はカスタマイズできるが、一番簡単なのはCodeQLをデフォルト設定で使うことになる。有効になっていない場合は下図のようになっているはずなので、Set upからDefaultを選ぶ。
すると、自動でリポジトリが解析されて、デフォルトの設定が生成される。この部分で間違っている場合は編集もできる。
設定が正しければ"Enable CodeQL"ボタンをクリックする。設定には数分時間がかかるので待つ。 きちんと有効化されスキャンされると、設定の部分に表示される。
スキャンの結果は、GitHubのActionsタブから確認できる。
6. デフォルトブランチを保護する
大抵のデフォルトブランチはmainだと思うが、このmainブランチに直接コミットされないように保護できる。例えば、少なくとも1人の承認を得て、マージする前にプルリクエストを要求するように設定できる。 個人的に1人開発のプライベートリポジトリだと面倒なだけだが、パブリックリポジトリなら直接プッシュされないというだけで恩恵は大きいと思っている。また、Dependabotのアラートやコードスキャンの結果を強制して、それによりマージを阻止することも可能になる。
これは個人的に過去に設定してしまっていたため、詳細は下記を参照してほしい。
おわりに
いろいろ調べながら設定したので時間がかかったが、結局のところ時間がかかるのはSECURITY.mdの作成とデフォルトブランチの保護くらいで、ほかは設定画面でEnableにするだけのものばかりだった。たしかに30分以内に更新できるな。