リポジトリのオープンソース化
リポジトリを公開リリースに備えて準備し、事前知識のない部外者がビルド、使用、貢献できるようにすると同時に、機密情報が含まれないようにします。手順は順番に従って進めてください。最初にシークレット監査を行う理由は、その結果（リポジトリを維持するか再作成するか）が後続のすべての手順に影響するためです。
使用するタイミング
- プライベートリポジトリを公開するとき
- 既存の公開リポジトリをリリース品質に監査するとき（「正式版にする」）
- プロジェクトのライセンスを選択するとき
- 公開リリースに先立って、パッケージング、バージョニング、リリース自動化を設定するとき
使用してはいけないタイミング
- すでにリリース済みのプロジェクトでの日常的な開発（リリースイベントがない場合）
- サードパーティコードの脆弱性監査（セキュリティレビュースキルを使用してください）
- プライベートのままにするリポジトリからパッケージを公開する場合 — リリース管理の手順のみが該当し、残りはスキップします
ワークフロー
ステップ 1：組織プロファイルの検出
bash {baseDir}/scripts/detect_org.sh
このスクリプトはgitリモートと最近のコミッターのメールアドレスを検査し、プロファイル名を出力します。trailofbits と出力された場合は、references/trailofbits.md を今すぐ読み、そのライセンスポリシー、公開アカウント、プロセスに関する注意事項を残りの手順全体に適用してください。generic と出力された場合は、汎用的なガイダンスのみに従って進めてください。ユーザーが検出結果が間違っていると言った場合は、ユーザーを信頼してください。
ステップ 2：シークレットの監査 — 他のすべてに先立って
一度でもシークレット（APIキー、認証情報、クライアントデータ）を含んだことのあるリポジトリは、公開すべきではありません。履歴の書き換えはエラーが発生しやすく、フォーク、キャッシュ、CIアーティファクトには反映されません。信頼できる修正方法は、新しいリポジトリを作成することです。現在のツリーをコピーしてコミットし、古いリポジトリはプライベートなままアーカイブします。
- プロジェクトがこれまでにシークレットやクライアントの機密情報を扱ったことがあるかどうかを尋ねてください。セキュリティコンサルティング会社のツールの場合は、テストフィクスチャやサンプルデータがクライアント案件に由来するかどうかも尋ねてください。
- 専用ツール（
gitleaks git .やtrufflehog git file://.など）を使って全履歴をスキャンしてください。目視確認は避けてください。 - gitツリー以外も確認してください：GitHub Actionsのログとアーティファクト、古いリリース、IssueとPRの履歴、リポジトリWikiはすべて、リポジトリとともに公開されます。
- 公開後は、リポジトリ設定でGitHubのシークレットスキャニングとプッシュ保護を有効にしてください。
以下のような正当化は却下してください — これは公開後に修正できない唯一のステップです。
- 「キーは失効済みだから、履歴は問題ない」 — 失効済みの認証情報でも、インフラ名、内部URL、攻撃者が標的にするパターンが漏洩します。
- 「git-filter-repoで履歴を書き換える」 — 書き換えではフォーク、クローン、キャッシュ、CIアーティファクトに影響が及びません。新しいリポジトリを作成する方法ではそのような問題はありません。
- 「テストデータにすぎない」 — クライアント案件や本番システムに由来するフィクスチャは、どのようにラベル付けされていようと機密情報です。
ステップ 3： readiness チェックの実行
bash {baseDir}/scripts/check_readiness.sh
このスクリプトは、存在を示すチェックリスト（README、LICENSE、CONTRIBUTING、SECURITY.md、CI、テスト、semverタグなど）を出力し、一般的にシークレットを含む追跡ファイルについて警告します。チェックされていない項目は、議論のきっかけとして扱い、絶対的な失敗条件とはしないでください。研究プロトタイプに主要ライブラリと同レベルのすべてが必要なわけではありません。ユーザーとギャップについて話し合い、このプロジェクトにとって重要なものを修正してください。
ステップ 4：ドキュメント
READMEはプロジェクトの玄関口です。以下が説明されていることを確認してください。
- プロジェクトが何であるか、そしてどのような問題を解決するか（最初の段落）
- インストール方法 — パッケージマネージャー、コンテナイメージ、またはソースからのビルド。新規クローンからのビルドが、リポジトリ内のものだけで動作する必要があります。
- 使用方法 — 具体的でコピー＆ペースト可能な例が少なくとも1つ
- 貢献方法 — インラインまたは
CONTRIBUTING.md経由 - ライセンス — ライセンス名を記載した短いセクション
さらに以下も追加してください。
SECURITY.md— 脆弱性報告手順（連絡先またはGitHubのプライベート脆弱性報告）。セキュリティツールにとっては必須項目です。- APIドキュメント — ビルドしてホストし（通常はCI経由のGitHub Pages）、READMEとリポジトリのウェブサイトフィールドからリンクします。エコシステムごとのドキュメンテーションツールについては、以下の言語別リファレンスを参照してください。
- 行動規範 — プロジェクトが外部からの貢献者を期待する場合。
ステップ 5：ライセンス
ライセンスがないことは、可視性に関わらずオープンソースではないことを意味します。選択基準と仕組みについては、references/licensing.md を読んでください。簡略版は以下の通りです。
- ステップ1で組織のポリシーが検出された場合は、それを適用してください。
- そうでない場合：寛容型のデフォルトとしてApache 2.0、競合他社によるプライベートな改変が実際に懸念される場合はAGPLv3、コード以外の成果物にはCreative Commons。
LICENSEファイルを追加し、パッケージメタデータにSPDX識別子を設定し、READMEにライセンスを記載し、これら3つがすべて一致することを確認してください。
ステップ 6：テストとCI
- テストスイートが存在し、パスすることを確認してください。デフォルトブランチが失敗している公開リポジトリは、放棄されたことを示します。
- CIがすべてのPR、およびサポート対象の言語バージョンとプラットフォームのマトリックス全体でテストを実行していることを確認してください。
- CIでフォーマットとリンティングを強制し（以下のリファレンスに言語別ツールあり）、スタイルの議論がレビューに届かないようにしてください。
- 既存のツールを尊重してください。 オープンソース化の一環として、動作しているフォーマッター、リンター、型チェッカーを置き換えないでください。現在の世代に遅れをとっている場合（言語リファレンスに現在のツールが記載されています）、メンテナーに警告し、判断を委ねてください。カテゴリが完全に欠落している場合（型チェッカーがない、フォーマッターがない）にのみ、現在のデフォルトを追加してください。
- カバレッジ低下時にCIを失敗させるカバレッジゲートを検討してください。
- ワークフロー自体を公開された攻撃対象領域になる前に強化してください。
- サードパーティアクションを完全なコミットSHAに固定し、
github-actionsに対してDependabotを有効にして、固定が最新に保たれるようにしてください。 - 最小権限の
permissions:ブロックを設定してください（permissions: {}から始めてください）。 zizmor .github/workflows/で監査し、actionlintでリントしてください。
- サードパーティアクションを完全なコミットSHAに固定し、
ステップ 7：リポジトリ設定
- デフォルトブランチのブランチ保護：フォースプッシュ禁止、PR必須。新しいリポジトリではルールセットを推奨します。クラシックなブランチ保護も引き続きサポートされます。
- マージ保護：必須ステータスチェックにより、テストが失敗しているPRはマージできないようにします。
- Dependabot または Renovate：依存関係とActionsの更新用。更新をグループ化してPRノイズを削減し、クールダウン期間（例：7日）を設定して、公開されたばかりの（そして時にはハイジャックされた）バージョンが採用前に熟成されるようにします。
.editorconfig：コントリビューターのエディターが空白の基本設定で一致するようにします。- ラベル：複数のIssueやPRにラベルが必要になり次第、作成してください。プレフィックスによるファセットのスケーリングが効果的です（
C:コンポーネント、P:プラットフォーム）。具体例として blightのラベル を参照してください。
ステップ 8：リリースとバージョニング
- すべてのリリースに
vX.Y.Zのタグを付け、セマンティックバージョニング に従ってください。リリース候補とプレリリースには-rc.N/-pre.Nサフィックスを使用してください。 - リリースはCI駆動にしてください：タグのプッシュ（またはGitHub Releaseの発行）により、手動ステップなしでビルド、パッケージング、アップロードがトリガーされます。リリースは
git tag vX.Y.Z && git push origin vX.Y.Zで行えるようにしてください。 - 個人アカウントではなく、組織が所有するアカウントでパッケージを公開し、インデックスがサポートしている場合は、長期トークンの代わりにtrusted publishing（OIDC） を使用してください。
ステップ 9：言語固有のプラクティス
プロジェクトのマーカーファイルから言語を特定し、パッケージング、公開、品質ツールについて対応するリファレンスを読んでください。
| マーカーファイル | リファレンス |
|---|---|
pyproject.toml, setup.py | references/python.md — ツールについてはmodern-pythonスキルに委ねます |
CMakeLists.txt, Makefile (C/C++) | references/c-cpp.md |
Cargo.toml | references/rust.md |
go.mod | references/go.md |
package.json | references/javascript.md |
Gemfile, *.gemspec | references/ruby.md |
その他のエコシステムについては、分野横断的な原則を適用してください：新規クローンからの再現可能なビルド、CI駆動のリリース、trusted publishingまたは組織所有アカウント、パッケージマニフェスト内のライセンスメタデータ。
最終レビュー
公開スイッチを入れる前に、部外者の視点から以下を確認してください。
- クリーンなディレクトリにクローンし、READMEのビルド手順をそのまま実行してください — 暗黙の知識なしで動作しますか？
{baseDir}/scripts/check_readiness.shを再実行し、残っているギャップが意図的な選択であり、ユーザーに説明済みであることを確認してください。- シークレット監査（ステップ2）が実際に行われたことを確認してください。これは公開後に修正できない唯一のステップです。
リポジトリの公開は、リポジトリ設定の変更です。組織に公開時のプロセスがある場合は、リリースとアナウンスを組み合わせてください。
追加リソース
リファレンスファイル
- references/licensing.md — ライセンス選択基準、SPDXメタデータ、フォークと再ライセンス
- references/trailofbits.md — Trail of Bits ポリシーオーバーレイ（ステップ1で検出された場合のみ読み込み）
- references/python.md、references/c-cpp.md、references/rust.md、references/go.md、references/javascript.md、references/ruby.md — 言語別のパッケージング、公開、品質ツール
スクリプト
scripts/detect_org.sh— gitリモートとコミッターのメールアドレスから組織プロファイル（trailofbitsまたはgeneric）を出力しますscripts/check_readiness.sh— リリース準備完了ファイルの存在を示すインジケーターを出力し、一般的にシークレットを含む追跡ファイルにフラグを立てます