1
パブリックリポジトリのセキュリティの脆弱性に対処するPRを処理するためのベストプラクティスは何ですか？
パブリックリポジトリを備えたオープンソースプロジェクトは、安全に報告されているがまだ公開されていないセキュリティ脆弱性に対処するプルリクエスト（PR）を最適に処理する必要がありますか？ 私は数百人の貢献者によるオープンソースプロジェクトに関与しています。定期的に予定されている月次リリースの一環として、セキュリティ通知と脆弱性を年に数回公開しています。パッチを適用したバージョンを公開するまで、脆弱性に関する情報は公開しません。プロジェクト管理システム（JIRA）でセキュリティの問題を安全に管理できます。しかし、セキュリティの脆弱性がGitHubに提出されるときに修正するPRを隠すための良いプロセスがありません。私たちは、人々がリリースされる前にこれらの修正を見つけて、ゼロデイエクスプロイトを作成できることを心配しています。 メインリポジトリをフォークするプライベートリポジトリの使用を検討しましたが、現在のレビューとQAワークフローの多くはPRで行われます。ワークフローをセキュリティチームのみのプライベートリポジトリに移動した場合、修正が公開されている場合、tarballを生成してsourceforgeで公開するのにかかる時間までウィンドウが短くなり、大幅に改善されます。また、PRを公開ベータ版にマージすることを避ける必要があるかもしれません。 その方向に進む前に、オープンリポジトリを使用したオープンソースプロジェクトでリリース前のセキュリティバグ修正パッチを処理するためのベストプラクティスを教えてください。GitHubとは異なるプラットフォームを使用することで問題に対処できる場合は、GitLabへの移行を評価していることに言及する必要があります。