open-sourcing

リポジトリをオープンソース化する

事前知識のない外部の人がビルド、使用、コントリビュートでき、機密情報が一切含まれないように、リポジトリを一般公開に向けて準備します。手順は順番に進めてください。秘密情報の監査を最初に行う必要があります。リポジトリを維持するか作り直すかという監査結果が、その後のすべてに影響するためです。

使用する場合

• プライベートリポジトリを一般公開する場合
• 既存の公開リポジトリがリリースに適した状態か監査する場合（「正式版にする」）
• プロジェクトのライセンスを選ぶ場合
• 一般公開に先立って、パッケージング、バージョン管理、リリースの自動化を設定する場合

使用しない場合

• すでにリリース済みのプロジェクトで日常的な開発を行う場合（リリースイベントがない場合）
• サードパーティーのコードに脆弱性がないか監査する場合（セキュリティレビュー用のスキルを使用してください）
• プライベートのままにするリポジトリからパッケージを公開する場合 — 適用するのはリリース管理の手順だけです。残りは省略してください

ワークフロー

ステップ 1：組織プロファイルを検出する

bash {baseDir}/scripts/detect_org.sh

このスクリプトは git リモートと最近のコミッターのメールアドレスを調べ、プロファイル名を出力します。trailofbits と出力された場合は、すぐにreferences/trailofbits.mdを読み、以降の手順全体でライセンスポリシー、公開に使用するアカウント、プロセスに関する注記を適用してください。generic と出力された場合は、一般的なガイダンスだけに従ってください。検出結果が誤っているとユーザーが伝えた場合は、ユーザーの判断を優先してください。

ステップ 2：秘密情報を監査する — 何よりも先に

API キー、認証情報、クライアントデータなどの秘密情報が過去に一度でも含まれていたリポジトリを、公開に切り替えてはいけません。履歴の書き換えは失敗しやすく、フォーク、キャッシュ、CI アーティファクトには反映されません。確実な対処法は、新しいリポジトリを作成することです。現在のツリーをコピーしてコミットし、古いリポジトリはプライベートのままアーカイブしてください。

1. プロジェクトでこれまでに秘密情報やクライアントの機密情報を扱ったことがあるか確認します。セキュリティコンサルティング会社のツールの場合は、テスト用フィクスチャやサンプルデータがクライアント案件に由来するものかどうかも確認してください。
2. 利用可能であれば、目視で確認するのではなく、専用ツールを使って全履歴をスキャンします — gitleaks git . または trufflehog git file://. を使用してください。
3. git ツリー以外も確認します。GitHub Actions のログとアーティファクト、古いリリース、イシューと PR の履歴、リポジトリの Wiki も、リポジトリとともに公開されます。
4. 一般公開後、リポジトリの設定で GitHub のシークレットスキャンとプッシュ保護を有効にします。

公開後には取り返しがつかない唯一の手順です。次のような正当化は受け入れないでください。

• 「キーは無効化したから、履歴は問題ない。」 無効化された認証情報でも、インフラ名、内部 URL、攻撃者が標的を定める際に使うパターンが漏えいします。
• 「git-filter-repo で履歴を書き換える。」 書き換えてもフォーク、クローン、キャッシュ、CI アーティファクトには反映されません。新しいリポジトリを作成する方法なら、それらの問題を回避できます。
• 「ただのテストデータだ。」 クライアント案件や本番システムに由来するフィクスチャは、どのようなラベルが付いていても機密情報です。

ステップ 3：準備状況を確認する

bash {baseDir}/scripts/check_readiness.sh

このスクリプトは、存在を確認する項目のチェックリスト（README、LICENSE、CONTRIBUTING、SECURITY.md、CI、テスト、semver タグなど）を出力し、一般に秘密情報が含まれることの多い追跡対象ファイルについて警告します。未チェックの項目は、必須の不合格条件ではなく、話し合いのきっかけとして扱ってください。研究用プロトタイプに、主力ライブラリと同じものがすべて必要とは限りません。ユーザーと不足項目を確認し、このプロジェクトに重要なものを修正してください。

ステップ 4: ドキュメント

README はプロジェクトの玄関口です。次のことが説明されているか確認してください。

• プロジェクトが何であるか、そしてどのような問題を解決するのか(最初の段落)
• インストール方法 — パッケージマネージャー、コンテナイメージ、またはソースからのビルド。クローン直後のビルドは、リポジトリ内にあるものだけで動作する必要があります
• 使用方法 — 少なくとも 1 つの具体的でコピー&ペースト可能な例
• コントリビュート方法 — インラインまたは CONTRIBUTING.md 経由
• ライセンス — それを明記した短いセクション

さらに次を追加してください。

• 脆弱性報告の手順(連絡先アドレスまたは GitHub のプライベート脆弱性報告)を記載した SECURITY.md。セキュリティツールにとって、これは最低限必要なものです。
• API ドキュメントをビルドしてホストする(CI 経由の GitHub Pages が通常の方法です)。README とリポジトリのウェブサイトフィールドからリンクします。エコシステムごとのドキュメントツールについては、以下の言語リファレンスを参照してください。
• プロジェクトが外部からのコントリビューターを想定している場合は、行動規範。

ステップ 5: ライセンス

ライセンスがなければ、可視性に関係なくオープンソースではありません。選択基準と手順については references/licensing.md をお読みください。要点は次のとおりです。

1. ステップ 1 で検出された場合は、組織のポリシーを適用します。
2. そうでない場合: 寛容なデフォルトとして Apache 2.0、競合他社による私的な改変が現実の懸念である場合は AGPLv3、コード以外の成果物には Creative Commons。
3. LICENSE ファイルを追加し、パッケージメタデータに SPDX 識別子を設定し、README にライセンスを明記し、この 3 つが一致することを確認します。

ステップ 6: テストと CI

• テストスイートが存在し、合格することを確認します。デフォルトブランチが失敗している公開リポジトリは、放棄のシグナルです。
• CI がすべての PR で、サポート対象の言語バージョンとプラットフォームのマトリックス全体にわたってテストを実行するようにします。
• CI でフォーマットとリンティングを強制し(以下のリファレンスにある言語ごとのツール)、スタイルの議論がレビューに到達しないようにします。
• 既存のツールを尊重してください。 オープンソース化の一環として、動作しているフォーマッタ、リンター、型チェッカーを置き換えないでください。それが現行世代に遅れている場合(言語リファレンスに現行ツールが記載されています)、メンテナーに警告し、判断を委ねます。カテゴリが完全に欠けている場合 — 型チェッカーがない、フォーマッタがない — にのみ、現行のデフォルトを追加します。
• カバレッジが低下したときに CI を失敗させるカバレッジゲートを検討してください。
• ワークフロー自体が公開の攻撃対象になる前に強化します。
  • サードパーティのアクションを完全なコミット SHA に固定し、github-actions に対して Dependabot を有効にして固定が最新に保たれるようにします。
  • 最小権限の permissions: ブロックを設定します(permissions: {} から始めます)。
  • zizmor .github/workflows/ で監査し、actionlint でリントします。

ステップ 7: リポジトリ設定

• デフォルトブランチのブランチ保護: force push の禁止、PR の必須化。新しいリポジトリにはルールセットを推奨します。従来のブランチ保護も引き続きサポートされています。
• マージ保護: テストが失敗している PR をマージできないようにする必須ステータスチェック。
• 依存関係と Actions の更新のための Dependabot または Renovate。更新をグループ化して PR のノイズを減らし、クールダウン期間(例: 7 日間)を設定して、公開されたばかりの — そしてときには乗っ取られた — バージョンが採用前に熟成するようにします。
• コントリビューターのエディタが空白の基本について一致するように .editorconfig。
• ラベル: 複数の issue または PR でラベルが必要になったらすぐに作成します。ファセットのプレフィックスはうまくスケールします(C: コンポーネント、P: プラットフォーム)。実例については blight のラベルを参照してください。

ステップ 8：リリースとバージョニング

• semver に従って、各リリースに vX.Y.Z のタグを付けます。リリース候補およびプレリリースには、-rc.N ／ -pre.N のサフィックスを使用します。
• リリースは CI で実行します。タグのプッシュ（または GitHub Release の公開）をトリガーとして、手動の手順を挟まずにビルド、パッケージ化、アップロードを実行します。リリースは git tag vX.Y.Z && git push origin vX.Y.Z で行えるようにします。
• パッケージは個人アカウントではなく、組織が所有するアカウントで公開し、インデックスが対応している場合は、長期間有効なトークンではなく トラステッドパブリッシング（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 によるリリース、トラステッドパブリッシングまたは組織所有のアカウントの利用、パッケージマニフェストへのライセンスメタデータの記載です。

最終確認

公開範囲を切り替える前に、外部の利用者の視点から確認します。

1. クリーンなディレクトリにクローンし、README のビルド手順に一字一句従ってください。暗黙知がなくても動作しますか？
2. {baseDir}/scripts/check_readiness.sh を再実行し、残っている不足項目が意図的な選択であり、ユーザーに明示されていることを確認します。
3. シークレットの監査（ステップ 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 — リリース準備に必要なファイルの有無を表示し、シークレットが含まれている可能性のある追跡対象ファイルに警告を出します