パブリックリポジトリのセキュリティの脆弱性に対処するPRを処理するためのベストプラクティスは何ですか？

パブリックリポジトリを備えたオープンソースプロジェクトは、安全に報告されているがまだ公開されていないセキュリティ脆弱性に対処するプルリクエスト（PR）を最適に処理する必要がありますか？

私は数百人の貢献者によるオープンソースプロジェクトに関与しています。定期的に予定されている月次リリースの一環として、セキュリティ通知と脆弱性を年に数回公開しています。パッチを適用したバージョンを公開するまで、脆弱性に関する情報は公開しません。プロジェクト管理システム（JIRA）でセキュリティの問題を安全に管理できます。しかし、セキュリティの脆弱性がGitHubに提出されるときに修正するPRを隠すための良いプロセスがありません。私たちは、人々がリリースされる前にこれらの修正を見つけて、ゼロデイエクスプロイトを作成できることを心配しています。

メインリポジトリをフォークするプライベートリポジトリの使用を検討しましたが、現在のレビューとQAワークフローの多くはPRで行われます。ワークフローをセキュリティチームのみのプライベートリポジトリに移動した場合、修正が公開されている場合、tarballを生成してsourceforgeで公開するのにかかる時間までウィンドウが短くなり、大幅に改善されます。また、PRを公開ベータ版にマージすることを避ける必要があるかもしれません。

その方向に進む前に、オープンリポジトリを使用したオープンソースプロジェクトでリリース前のセキュリティバグ修正パッチを処理するためのベストプラクティスを教えてください。GitHubとは異なるプラットフォームを使用することで問題に対処できる場合は、GitLabへの移行を評価していることに言及する必要があります。

— ジョー・マレー
ソース

ベストプラクティスが設定されているかどうかはわかりません。GitLabは基本的にプライベートGitHubです。オープンソースとセキュリティ修正の懸念のバランスを取ることは簡単ではありません。セキュリティの修正のうち、セキュリティチーム以外の人からの修正がいくつありますか？

— ベリンロリチュ

ほとんどの問題は他の人から報告されていますが、おそらく修正の5分の1未満はセキュリティチーム以外の人によるものです。

— ジョーマレー

私の意見では、プロセスの一部をプライベートにする必要がある場合は、GitHubの外部で行う必要があります（GHはパブリックであるため）。この特定の部分が完了し、全員がコードを確認した後。公式のプロセスに「戻る」ために、できるだけ早くマージされるGHでPRを作成できます。別のツールを使用して、プロセスのこれらの例外を管理できます。

— エマーソンカルドーソ

完全な即時開示（つまり、遅延なく公開すること）は、完全に合法的なことです。

— マイルルーティング

この質問は、セキュリティ問題がチームによって開示されていない限り、世界に知られていないと仮定しているようです。それは単に真実ではありません。発見されたセキュリティの問題は、どこかで悪意のある人に知られていると想定する必要があります。現在、他の誰かがすでに問題を知っており、それを悪用していると思われる場合、通常の月次リリースまで修正のリリースを延期することはできません。できるだけ早くリリースする必要があります。つまり、通常のPRフローに従うことに問題はありません。最新のリリースブランチ、マージ、タグ、リリースに対してPRするだけです。

— ジョリージャーツ

このためのプロトコルは、脆弱性を公開する際のリスク要因を決定することです。セキュリティに関連するものについては、それらのPRは、セキュリティチームだけが見ることができるプライベートリポジトリにある必要があります。これは、プルリクエストの生成とアクションに使用するプラットフォームに関係なく有効です。

— ロイドムーア
ソース