オープンソースプロジェクトを運営する際、セキュリティポリシーを明文化することは非常に重要です。本記事では、Giselle プロジェクトの PR を参考に、SECURITY.md と security.txt の効果的な書き方を解説します。
SECURITY.md は、プロジェクトのセキュリティポリシーを記載するファイルです。GitHub では、リポジトリのルートディレクトリに SECURITY.md を配置すると、「Security」タブから自動的にリンクされます。
このファイルには主に以下の内容を記載します。
セキュリティポリシーを明文化することで、以下のメリットがあります。
Giselle は AI アプリビルダーのオープンソースプロジェクトです。このプロジェクトに導入された SECURITY.md の構成を見ていきましょう。
## Supported Versions
As an open source product, we will only provide security patches for the latest major version.
Older versions will not receive retroactive security patches.オープンソースプロジェクトでは、すべてのバージョンをサポートし続けることは現実的ではありません。最新のメジャーバージョンのみサポートすることを明記し、ユーザーに最新版へのアップデートを促しています。
## Bug Bounty Program
Giselle does not currently operate a bug bounty program.
We do not offer monetary rewards for vulnerability reports.
We appreciate responsible disclosure and will acknowledge contributors in our release notes
(with permission), but submitting a report does not guarantee or imply any monetary compensation.バグバウンティプログラムを実施していないことを明確にしています。これは重要なポイントです。報告者が金銭的な報酬を期待している場合、事前に認識のずれを防ぐことができます。
代わりに、リリースノートでの謝辞という形で貢献を認めることを提示しています。
Giselle では 2 つの報告方法を提供しています。
### case1: Report via Email
1. **Email us** at oss@giselles.ai. Please do not create a public GitHub issue.
2. Include as much detail as possible, including steps to reproduce the vulnerability,
potential impact, and any other relevant information.
3. We will acknowledge your email within 3 business days and work with you to understand
the issue and address it promptly.専用のメールアドレスを用意し、パブリックな Issue を作成しないよう注意喚起しています。3 営業日以内の初回応答を約束することで、報告者に安心感を与えています。
### case2: Report via GitHub Private vulnerability reporting
To report a security issue, please use the GitHub Security Advisory
["Report a Vulnerability"](https://github.com/giselles-ai/giselle/security/advisories/new) tab.
**Do not open up a GitHub issue.**GitHub の Private vulnerability reporting 機能を活用する方法も提供しています。この機能を使うと、非公開で脆弱性を報告でき、修正が完了するまで情報が公開されません。
## Handling Security Issues
We follow a responsible disclosure process:
1. We will investigate the reported vulnerability and work on a fix.
2. A fix will be developed, tested, and incorporated into the project.
3. Once the fix is ready, we will release a new version of the project with a detailed release note.
4. We will notify the reporter about the fix and acknowledge their contribution in the release notes,
if they wish to be credited.報告から修正、リリースまでの流れを明確にしています。報告者への通知と謝辞についても言及しています。
## Out of Scope
The following items are generally considered out of scope:
- Missing or misconfigured DMARC/SPF/DKIM records
- Missing security headers (unless directly exploitable)
- Disclosure of software versions
- Reports from automated tools without demonstrated impact
- Social engineering attacks
- Denial of service attacks何がセキュリティ報告の対象外かを明記することで、無関係な報告を減らすことができます。自動化ツールによるスキャン結果をそのまま報告されるケースは多いため、「影響を実証していない自動ツールからの報告」を対象外としています。
## Responsible Disclosure Guidelines
We kindly ask reporters to:
- Allow reasonable time for us to investigate and address the issue before public disclosure
- Avoid ultimatum-style deadlines or threats of public disclosure as a negotiation tactic
- Provide sufficient technical details (reproduction steps, PoC, headers, etc.) to validate the issue報告者に対して、修正に必要な時間を確保するよう依頼しています。また、最後通牒のような期限設定や公開をちらつかせる交渉を避けるよう求めています。
SECURITY.md に加えて、security.txt を導入することも推奨されます。security.txt は RFC 9116 で標準化されたファイルで、Web サイトのセキュリティ連絡先を機械可読な形式で提供します。
Giselle では PR #2649 で security.txt を更新しています。
Contact: mailto:security@giselles.ai
Expires: 2027-01-15T23:59:59Z
Preferred-Languages: en, ja
Policy: https://github.com/giselles-ai/giselle/security/policy
Canonical: https://studio.giselles.ai/.well-known/security.txt各フィールドの意味は以下のとおりです。
| フィールド | 説明 |
|---|---|
Contact | セキュリティ問題の報告先（メールアドレスまたは URL） |
Expires | このファイルの有効期限（RFC 9116 では必須） |
Preferred-Languages | 対応可能な言語 |
Policy | セキュリティポリシーへのリンク |
Canonical | このファイルの正規 URL |
security.txt は .well-known/security.txt または /security.txt に配置します。Expires フィールドは必須で、定期的な更新が必要です。
RFC 9116 では、Expires フィールドの値は 1 年以内に設定することが推奨されています。そのため、定期的な更新が必要になりますが、忘れがちな作業です。
Giselle では PR #117 で security.txt を導入した際に、GitHub Actions による自動リマインダーも設定しています。
name: Create an issue to remind updating of security.txt
on:
workflow_dispatch:
schedule:
- cron: "0 0 1 6,12 *" # Every year on 6/1 and 12/1 at 9:00am JST
jobs:
create_issue:
runs-on: ubuntu-latest
steps:
- name: Create reminder issue
# Issue 作成のステップこのワークフローは毎年 6 月 1 日と 12 月 1 日に自動で Issue を作成し、security.txt の更新を促します。Issue のテンプレートには以下の内容が含まれています。
Expires フィールドを 1 年以内の日付に更新するタスクこのような自動化により、security.txt の更新漏れを防ぐことができます。
SECURITY.md ファイルを作成小規模なプロジェクトでも、以下の内容は含めることをお勧めします。
# Security Policy
## Reporting a Vulnerability
If you discover a security vulnerability, please report it to [your-email@example.com].
Please do not create a public GitHub issue.
We will respond within [X] business days.これにより、報告者は GitHub 上で非公開の脆弱性レポートを作成できるようになります。
SECURITY.md と security.txt は、オープンソースプロジェクトのセキュリティ対応を明文化する重要なドキュメントです。Giselle では以下の PR でセキュリティポリシーを段階的に整備しています。
ポイントをまとめると以下のとおりです。
セキュリティポリシーは一度作成して終わりではなく、プロジェクトの成長に合わせて継続的に更新することが重要です。セキュリティポリシーがないプロジェクトを運営している場合は、ぜひ SECURITY.md と security.txt の導入を検討してみてください。
以上、SECURITY.md の書き方を Giselle の事例から学んだ、現場からお送りしました。