パブリックリポジトリのセキュリティの脆弱性に対処するPRを処理するためのベストプラクティスは何ですか？
公開リポジトリを備えたオープンソースプロジェクトは、安全に報告されているがまだ公開されていないセキュリティの脆弱性に対処するプルリクエスト（PR）を最も効果的に処理するにはどうすればよいですか？
私は数百人の貢献者によるオープンソースプロジェクトに参加しています。定期的にスケジュールされた毎月のリリースの一環として、セキュリティ通知と脆弱性を年に数回発行しています。パッチが適用されたバージョンが利用可能になるまで、脆弱性に関する情報を公開しません。プロジェクト管理システム（JIRA）でセキュリティの問題を安全に管理できます。ただし、GitHubに送信されたセキュリティの脆弱性を修正するPRを隠すための適切なプロセスがありません。これらの修正がリリースされる前に発見され、ゼロデイエクスプロイトが作成される可能性があることを懸念しています。
メインリポジトリをフォークするプライベートリポジトリの使用を検討しましたが、現在のレビューとQAワークフローの多くはPRで行われます。ワークフローをセキュリティチームのみのプライベートリポジトリに移動した場合、修正が公開されたときにウィンドウが縮小され、tarballを生成してsourceforgeで公開するのにかかる時間が短縮されます。これは大きな改善です。また、PRを公開ベータ版にマージすることを避ける必要もあるでしょう。
その方向に進む前に、オープンリポジトリを使用するオープンソースプロジェクトでプレリリースのセキュリティバグ修正パッチを処理するためのベストプラクティスは何ですか？ GitHubとは異なるプラットフォームを使用することで問題に適切に対処できる場合は、GitLabへの移行を評価していることを述べておきます。
このプロトコルは、脆弱性を公開する際のリスク要因を決定することです。セキュリティ関連の場合、それらのPRは、セキュリティチームだけが見ることができるプライベートリポジトリにある必要があります。これは、プルリクエストの作成とアクションに使用するプラットフォームに関係なく機能します。