2025年11月19日、Golangプロジェクトは広く使われている golang.org/x/crypto/ssh に影響を与える2つの共通脆弱性および曝露(CVE)を公開しましたパッケージ。どちらの脆弱性も重要なCVSSスコアは得られませんでしたが、GoベースのコンテナでSSH機能を使用するアプリケーションにとっては現実的なリスクをもたらしました。

CVE-2025-58181 GSSAPI認証要求を解析するSSHサーバーに影響を及ぼします。この脆弱性により、攻撃者は認証要求で指定されたメカニズムの数をサーバーが検証できなかったことを悪用し、無限のメモリ消費を引き起こすことが可能になります。 CVE-2025-47914 は、IDリクエスト処理時にメッセージサイズの検証に失敗したSSHエージェントサーバーに影響を及ぼし、誤ったメッセージが届いた際にシステムパニックを引き起こす可能性があります。(これら2つの脆弱性は、同じGolangコンポーネントに影響を及ぼす高重大度のCVE-2025-47913の直後に発生しました。Dockerも迅速にパッチを当てました)

コンテナにSSH機能を持つGoアプリケーションを実行するチームにとって、これらの脆弱性を放置するとサービス拒否攻撃やシステムの不安定さにさらされます。

Dockerが驚くほど高速な脆弱性対応を実現する方法

これらのCVEがGolangプロジェクトのセキュリティフィードに届いたとき、 Docker Hardened Images の顧客は 24 時間以内にパッチ適用済みのバージョンが利用可能になりました。この迅速な対応は、Docker Scoutの継続的な監視アーキテクチャとDHIの自動修復パイプラインに起因しています。

仕組みは次のとおりです。

継続的なCVEインジェスティング:バッチスケジュールで実行される脆弱性スキャンとは異なり、 Docker Scout はGitHubのセキュリティアドバイザリー、国家脆弱性データベース、プロジェクト固有のフィードなどの上流ソースからCVE情報を継続的に取り込みます。CVEデータが利用可能になった瞬間、Scoutは分析を開始します。

即時の影響評価:CVEの取り込みから数秒以内に、Scoutは包括的なSBOMデータベースに基づき、影響を受けるDocker Hardened Imageを特定します。この即時通知により、遅延なく修復作業が開始されます。

自動パッチ適用ワークフロー:脆弱性やパッケージによって、Dockerは自動的にパッチを当てるか、複雑な変更に対して手動レビュープロセスをトリガーします。これらのGolang SSH脆弱性については、上流パッチが利用可能になった直後にビルドを開始しました。

カスケードビルド:パッチを当てたGolangパッケージが正常にビルドされると、システムは自動的にすべての依存パッケージとイメージの再構築をトリガーします。影響を受けた golang.org/x/crypto/ssh を含むすべてのDocker Hardened Image(Docker硬化型イメージ)を含んでいますパッケージはセキュリティ修正で再構築されます。

CVEの開示から顧客にパッチ適用されたイメージを提供するまでの全プロセスは、 24 4時間以内に完了しました。Docker Scoutを利用する顧客は、脆弱性やパッチ適用されたバージョンの入手可能性について即時通知を受け取りました。

なぜDockerのセキュリティ対応が異なるのか

Dockerの主な差別化点の一つは、定期的なバッチスキャンではなく、継続的なリアルタイム監視です。従来の脆弱性管理は日次または週次スキャンに依存しており、コンテナは既知の脆弱性に数時間から数日間にさらされます。

Docker ScoutのリアルタイムCVEインジェス機能により、脆弱性が公開された瞬間から検出が開始され、数秒以内に修復が可能となり、露出を最小限に抑えます。

この基盤はDocker Hardened Images(DHI)を支えており、パッケージや依存関係が継続的に追跡され、問題が発生した際に自動的に更新されます。例えば、脆弱性が発見された場合 golang.org/x/crypto影響を受けたすべての画像は1日以内に再構築され、公開されました。顧客は最新のタグを取り外して安全を確保し、手動のパッチ作業や緊急メンテナンス、衝撃トリアージは不要です。

しかし、継続的なモニタリングはあくまで基盤に過ぎません。Dockerを真に際立たせているのは、そのリアルタイムインテリジェンスが自動化され、透明性があり、信頼できる修復パイプラインに流れ込む点です。これは、10年以上にわたるDocker公式イメージプログラムの安全と保守の経験に基づいています。これらは世界中の何百万もの開発者や組織に信頼され、利用されている画像であり、数え切れないほどの本番環境の基盤を形成しています。グローバルスケールでの継続的なセキュリティイメージの維持、再構築、配布における長年の運用経験により、Dockerは信頼性、一貫性、信頼を提供する実績を他社には及ばない実績を誇っています。

自動化を超えて、 DockerのAIガードレールは さらに保護の層を加えます。Hardened Imagesパイプライン向けに特別に設計されたこれらのAIシステムは、上流のコード変更を継続的に分析し、リスクの高いパターンを指摘し、欠陥のある依存関係がサプライチェーンに侵入するのを防ぎます。標準的なコーディングアシスタントとは異なり、DockerのAIガードレールは手動でプロジェクトごとのレビューによって調整されており、人間の専門知識と適応型知能を融合させています。システムが誤りチェックの逆さ、失敗の無視、リソース管理の不備など高い信頼度の問題を検出すると、Dockerエンジニアが修正を検証し適用するまでリリースを停止します。この人間インザループモデルは、脆弱性が顧客に届く前に発見され、AIを人間の判断の代替ではなく安全のための力倍増器に変えています。

もう一つの重要な差別化は完全な透明性です。パッチを当てたイメージを取得した後でもセキュリティスキャナーが脆弱性を検出し続ける場合を考えてみてください。DHIでは、すべての画像に包括的かつ正確なソフトウェア材料表(SBOM)が含まれており、コンテナ内の内容を明確に把握できます。スキャナーが修復済みとされる画像を脆弱性として報告した場合、チームはスキャナーのヒューリスティックに頼らず、SBOMから正確なパッケージバージョンやパッチの状態を直接確認できます。

この透明性は、Docker ScoutがCVEデータを扱う方法にも及びます。Dockerは脆弱性の決定や優先順位付けにおいて、National Vulnerability Database(NVD)、GitHubセキュリティアドバイザリー、上流のプロジェクトメンテナなど、独立した第三者ソースに完全に依存しています。この方法は、従来のスキャナーがパターンマッチングやヒューリスティックに依存しているため、誤検知が生じる可能性があるため不可欠です。ベンダー固有のパッチを見逃したり、バックポートされた修正を見落としたり、データベースの遅延のために既に修正された脆弱性を指摘したりすることがあります。場合によっては、ベンダー推奨のスキャナーでさえ未修正の脆弱性を検出できず、誤ったセキュリティ意識を生み出します。

正確なSBOMや客観的なCVEデータがなければ、チームは幻の脆弱性を追いかけたり、コンプライアンス監査人と誤検知を議論したりして貴重な時間を無駄にしてしまいます。Dockerのアプローチはその不確実性を排除します。SBOMはビルドプロセスから直接生成されるため、後から推測されるものではないため、各イメージの内部内容や特定の CVE が適用される理由を明確に示します。これにより、脆弱性管理は推測や議論から、透明性の高い第三者データに裏付けられた客観的で検証可能なセキュリティ保証へと変わる。

CVEはあなたの一週間を妨げる必要はありません

脆弱性の管理には多大なエンジニアリング時間がかかります。重要なCVEが削除されると、チームは影響を評価し、パッチをテストし、展開を調整します。Docker Hardened Imagesは、基本画像の内容を完全に透明にし、迅速なターンアラウンドで露出ウィンドウを短縮することで、このオーバーヘッドを排除します。

もし脆弱性のモグラ叩きがチームのロードマップを妨げることに疲れているなら、Docker Hardened Imagesはより良い道を提供します。Docker ScoutやHardened Imagesが脆弱性管理の負担をどのように軽減できるか、ご相談いただけるか、当社の チームにご連絡 いただき、具体的なセキュリティ要件についてご相談ください。