GitHub上の私のプロジェクトの1つが、この場合は中程度の重大度の脆弱性アラートを受け取りました。
この脆弱性は、古いバージョンのコードの依存関係で検出されました。現在のバージョンでは、この依存関係は使用されなくなりました。それでもなお、古いコミットがチェックアウトされて実行される可能性があり、アプリケーションを開いて脆弱性を悪用する可能性があります。
ソフトウェアエンジニアリングの観点から、以前のコミットに戻って変更することをお勧めします。つまり、現在使用されていない依存関係を脆弱性の修正を含む新しいバージョンに更新しますか？または、コミット履歴をそのままにしておく方が良いですか？
回答:
ここには2つの実行可能なオプションがあります。
まず、問題のあるバージョンのパッチバージョンをリリースします。たとえば、問題のあるバージョンがバージョン3.3で、バージョン5.1を使用している場合、脆弱性に対処する3.3.1をリリースできます。これにより、（さまざまな理由で）メジャーバージョンにアップグレードできないユーザーが脆弱性の修正を入手できます。
次に、何もしません。これはソフトウェアの古いバージョンであり、脆弱性のない新しいバージョンが維持されています。セキュリティを気にするユーザーは、より新しいバージョンを実行している必要があります。
どのオプションが最適ですか？場合によります。ただし、戻って古いコミット（履歴の書き換え）を改訂することはあまり意味がありません。一部のユーザー（特に規制された環境）には、これに関する多くの問題があります。ソフトウェアを広く使用するには、履歴の書き換えを避けてください。
考慮してください：
通常、バージョン管理システムが履歴の記録に使用されます。特定の時点でのコードの状態を正確に表示します。古いバージョンをチェックアウトしてビルドした結果は、そのバージョン、バグなどすべてになるはずです。一部のシステムは再現可能なビルドを提供します。古いビルドと完全に同一のバイナリを生成できるはずです。
ほとんどのバージョン管理システムでは、チェックインすると責任が発生する可能性のある情報の消去などの極端な状況を除いて、履歴の書き換えが許可されません。gitがこれを行うことができるのは珍しく、少し「異端」です。
ドキュメントは、履歴を書き換えるリスクがあることを認めています。
さらに、これは分散バージョン管理システムです。書き直しても、すでに複製されているリポジトリには影響しません。
個人データ、暗号化キーなど、機密にしておくべき最近コミットされたものを削除する場合を除いて、これを実行しないことをお勧めします。
現在受け入れられている回答でさえも、誰かが誤って古いコミットにアクセスして、新しいブランチでその古い状態のコードベースを使用することを回避する方法の質問の一部に実際には対応していないようであり、古い脆弱性を再び持ち込みます。
私見これに対処する正しい方法は次のとおりです。
システムの「リリースノート」（または「変更ログ」）ドキュメントに、バグ修正と脆弱性修正を厳密に文書化する
古いバージョンのコードにアクセスするすべての開発者がリリースノートを読んだことを確認し、使用しようとしているコードの後にあるコードのバージョンで解決された問題を確認します。
古いバージョンを再利用する場合、または古いバージョンのコードベースから分岐する場合、これを盲目的に行わないことは開発者の責任であることは明らかです。それらが再び導入されないようにするために、彼らはすでに修正されたバグと脆弱性をクロスチェックする必要があることは明らかです。ただし、VCSログは、この種の情報を見つけるのに実際に適した場所ではありません。通常、抽象化のレベルが低すぎるため、言及されているすべての種類の変更があるためです。
ただし、リリースノートには、「新機能」セクションと「解決された問題」セクションが含まれている必要があります。また、古いバージョンから分岐する前に、後者を最初に確認する必要があります。
たとえば、3.5は脆弱ですが、3.6はそうではありません。脆弱性なしで3.5.1を作成できます。しかし、それは仕事であり、あまり有用ではありません。なぜなら、人々は自分のバージョンを更新するか更新しないかのどちらかなので、誰も3.5.1を使用する可能性は低いからです。