本組織では、本番環境にデプロイする前に、すべての High/Critical の脆弱性を Docker イメージにパッチ適用することを義務付けています。現在、discourse/base:2.0.20251008-0017-web-only をベースにした Discourse のビルドには、いくつかパッチ適用を試みている脆弱性があります。以下に、パッチ適用が必要な脆弱性のリストを示します。
vuln-report-opencves.txt (2.3 KB)
これらの脆弱性を修正したバージョンに何も考えずに更新した場合、問題が発生する可能性があるかどうか、ガイダンスをいただけますでしょうか？もし問題が発生する場合、どのようにすれば問題が発生していることを特定できますでしょうか？
また、golang に関連する脆弱性が多数見られます。Discourse は実行時に何らかの形で golang を使用していますか、それとも最終的なイメージから完全に削除できますか？python についても同様です。
試してみて、どうなるか見てみればいいと思います。セキュリティやライブラリのバージョン管理を専業としている人がたくさんいます。
しかし、待ってください。ベースのDockerイメージ（ああ、あなたがビルドしたイメージのことかもしれませんね。よくわかりません）を見ているのであれば、それは不可能だと思います。なぜなら、その多くはDiscourseのソースで管理されているからです。例えば、このコミットではRackが2.2.20にアップグレードされています。ベースのDockerイメージのバージョンは関係ありません。おそらく、launcherでイメージをビルドしてから、どのバージョンのものがあるかを確認したいでしょう。その後、例えばGoとPythonを削除するyamlを追加することもできます。
また、他のユーザーがシステムにいる場合にのみ問題となるセキュリティ上の問題がたくさんありますが、それらがDockerコンテナにあることは実際には問題にならないため、Discourseチームにとって優先事項となる可能性は低いでしょう。
申し訳ありません、不明瞭でした。
現在のビルドプロセスは、前のメッセージで言及されたディスコースのベースイメージから始まり、スクリプトを実行します。これは、サポートされているインストールのプロセス（ランチャースクリプト）のブートストラップステップにすぎませんが、アクティブなRedis/DB接続を必要とするステップは実行しません。
したがって、ブートストラップステップは、ディスコースのすべてのRuby依存関係とnpm依存関係をインストールすると想定されます。脆弱性リストに表示されているバージョンは、主にディスコースアプリケーション自体の依存関係です。
また、調査したところ、タグ付けされているgolangの依存関係は、golangを使用してビルドされたesbuildというnpm依存関係からのものであることがわかりました。使用されているGoのバージョンには標準ライブラリの脆弱性があり、それがタグ付けされています。そのため、これを解決するには、そのライブラリの再コンパイルが必要になるため、労力に見合うかどうかはわかりません。
しかし、その他の脆弱性は、直接のRuby/npm依存関係またはディスコースの推移的な依存関係です。私の質問は、主にそれらをインストールする直前にそれらのバージョンを更新することについてでした。ディスコースの開発者がそれらを修正するために取り組むのは難しいと理解しています。一部の依存関係は特定のコードパスでのみ問題を引き起こす可能性があると推測したため、問題を引き起こすかどうかを確認する方法があるかどうかを理解しようとしていただけです。