CodeNote.net

オープンソースプロジェクトに SECURITY.md と security.txt を導入する - Giselle の事例から学ぶ

#security #oss #github #giselle
重岡 正 ·  Sun, January 18, 2026

オープンソースプロジェクトを運営する際、セキュリティポリシーを明文化することは非常に重要です。本記事では、Giselle プロジェクトの PR を参考に、SECURITY.md と security.txt の効果的な書き方を解説します。

SECURITY.md とは

SECURITY.md は、プロジェクトのセキュリティポリシーを記載するファイルです。GitHub では、リポジトリのルートディレクトリに SECURITY.md を配置すると、「Security」タブから自動的にリンクされます。

このファイルには主に以下の内容を記載します。

  • サポート対象バージョン
  • 脆弱性の報告方法
  • セキュリティ問題への対応プロセス
  • バグバウンティプログラムの有無

なぜ SECURITY.md が重要なのか

セキュリティポリシーを明文化することで、以下のメリットがあります。

  1. 脆弱性報告者への明確なガイダンス: 報告先や報告方法が明確になることで、適切な報告を受けやすくなります
  2. 責任ある開示の促進: パブリックな Issue ではなく、非公開チャネルでの報告を促すことで、悪用リスクを低減できます
  3. プロジェクトの信頼性向上: セキュリティに真摯に取り組む姿勢を示すことで、ユーザーや貢献者からの信頼を得られます

Giselle の SECURITY.md を読み解く

Giselle は AI アプリビルダーのオープンソースプロジェクトです。このプロジェクトに導入された SECURITY.md の構成を見ていきましょう。

サポートバージョン（Supported Versions）

## 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）

## 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.

バグバウンティプログラムを実施していないことを明確にしています。これは重要なポイントです。報告者が金銭的な報酬を期待している場合、事前に認識のずれを防ぐことができます。

代わりに、リリースノートでの謝辞という形で貢献を認めることを提示しています。

脆弱性の報告方法（Reporting Security Issues）

Giselle では 2 つの報告方法を提供しています。

1. メールでの報告

### 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 営業日以内の初回応答を約束することで、報告者に安心感を与えています。

2. GitHub Private vulnerability reporting

### 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）

## 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）

## 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）

## 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.txt の導入

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 フィールドは必須で、定期的な更新が必要です。

GitHub Actions による更新リマインダー

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 のテンプレートには以下の内容が含まれています。

  • RFC 9116 への参照リンク
  • Expires フィールドを 1 年以内の日付に更新するタスク
  • 他のフィールドの見直しタスク

このような自動化により、security.txt の更新漏れを防ぐことができます。

自分のプロジェクトに SECURITY.md を導入する

基本的な手順

  1. リポジトリのルートに SECURITY.md ファイルを作成
  2. プロジェクトの状況に合わせて内容をカスタマイズ
  3. 連絡先メールアドレスを設定
  4. GitHub の Security Advisories を有効化

最低限含めるべき内容

小規模なプロジェクトでも、以下の内容は含めることをお勧めします。

# 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 Private vulnerability reporting の有効化

  1. リポジトリの「Settings」→「Code security」に移動
  2. 「Private vulnerability reporting」を有効化

これにより、報告者は GitHub 上で非公開の脆弱性レポートを作成できるようになります。

まとめ

SECURITY.md と security.txt は、オープンソースプロジェクトのセキュリティ対応を明文化する重要なドキュメントです。Giselle では以下の PR でセキュリティポリシーを段階的に整備しています。

  • PR #3: SECURITY.md の導入
  • PR #117: security.txt の導入と GitHub Actions による更新リマインダー
  • PR #2649: security.txt の更新とポリシーの拡充

ポイントをまとめると以下のとおりです。

  • 報告方法を明確に: メールと GitHub Private vulnerability reporting の両方を提供
  • 対応プロセスを説明: 報告から修正までの流れを明記
  • 対象外を定義: 不要な報告を減らし、本質的な脆弱性に集中
  • バグバウンティの有無を明記: 報告者の期待値を適切に設定
  • security.txt を配置: 機械可読な連絡先情報を提供し、定期的に更新

セキュリティポリシーは一度作成して終わりではなく、プロジェクトの成長に合わせて継続的に更新することが重要です。セキュリティポリシーがないプロジェクトを運営している場合は、ぜひ SECURITY.md と security.txt の導入を検討してみてください。

以上、SECURITY.md の書き方を Giselle の事例から学んだ、現場からお送りしました。

参考情報