コンテキストデータで脆弱性をより早く解決

OpenSSL 3.0.7 と「Text4Shell」は、開発チームを悩ませる最新の重大な脆弱性かもしれませんが、これが最後ではありません。 2021年には、重大な脆弱性が 過去最高に達しました。 攻撃者は自分の仕事を再利用しており、今年のゼロデイ攻撃の50%以上は、 以前にパッチが適用された脆弱性の亜種です。 

新しいセキュリティの脆弱性が発生するたびに、現在のシステムとプロセスを再検討する必要があります。 OpenSSLまたはText4Shell(別名 CVE-2022-42889)の影響を受けている場合は、おそらく「Apache Commons Textを使用しているのか(どこで)?」または「脆弱なバージョンですか?」などの質問を自問したことがあるでしょう。 また、アプリケーションをコンテナイメージにパッケージ化し、クラウドインフラストラクチャで実行する場合は、イメージ、デプロイ環境、影響を受ける Commons-Text バージョンごとの内訳が非常に役立ちます。 

開発者は、ノイズをカットしてこれらの質問に答えるためにコンテキストデータを必要としていますが、情報の収集には時間がかかり、生産性に大きな影響を与えます。 開発者がコンテキストを切り替え、これらの問題の調査、トリアージ、修正に数え切れないほどの時間を費やす必要がある場合、丸一日が脱線します。 では、これらの混乱を食い止め、開発者にとってよりアクセスしやすい方法で重要なデータを明らかにするにはどうすればよいでしょうか。

画像を継続的に調べることから始める

バグ、構成ミス、脆弱性は、イメージが本番環境にプッシュされると止まらず、開発も停止するべきではありません。 画像の改善は継続的な取り組みであり、開発前、開発中、開発後に一定の情報の流れが必要です。

画像が使用される前に、チームは画像の精査と選択にかなりの時間を費やします。 同じ画像を継続的に検査するために、同じ労力を費やす必要があります。 そうしないと、不必要なやり直し、時間の浪費、開発者全体のフラストレーションの反応的なサイクルに陥ることになります。

そこで役立つのがコンテキストデータです。 コンテキストデータは、周囲の状況に直接結びついているため、開発者はより幅広い理解を得ることができます。 たとえば、脆弱性のコンテキスト データは、脆弱性が何であるか、その緊急度、および開発者とアプリケーション アーキテクチャ (ローカル、ステージング、運用) に対する具体的な影響を理解するための明確で正確な洞察を提供します。

コンテキストデータはノイズを減らし、開発者が何をどこで知るのに役立つため、最も効率的な方法で正しい変更を行うことを優先できます。 コンテキストデータはどのようなものですか? それは...

  • PR ブランチから構築されたイメージと、運用環境で現在実行されているイメージ バージョンの間で検出された脆弱性の比較
  • 同じカスタム基本イメージを使用するイメージ間の比較
  • 現在本番環境で実行されているイメージで新しい重大または高 CVE が検出されたときに、GitHub リポジトリに接続されている Slack チャネルに送信されるアラート
  • 特定の CVE を修復するために基本イメージの新しいバージョンに更新するためのアラートまたはプル要求

コンテキスト データを使用すると、開発者はアプリケーションの脆弱性をすばやく見つけて修復できます。

Docker を使用してコンテキスト データを表示する

コンテキスト データとは、開発者が日常業務を行う際に、より多くの情報を提供することです。 それはどのように機能しますか?

Docker は、レジストリ内のパブリック イメージとプライベート イメージのインデックスを作成して分析し、イメージの品質に関する分析情報を提供できます。 たとえば、オープンソースのパッケージの更新を取得したり、セキュリティ研究者が新しい脆弱性を発見したときにそれらに関するアラートを受信したり、更新を送信して古い基本イメージを更新したり、アクセストークンなどの誤って埋め込まれたシークレットについて通知を受けたりすることができます。 

以下のスクリーンショットは、選択したDockerイメージの脆弱性の非常に一般的なリストのように見えるものを示しています。 しかし、このページには、画像に関連するデータがさらにたくさんあります。

  • このページでは、脆弱性がレイヤーとベースイメージごとに分割されるため、検出された脆弱性の修正を適用する場所を簡単に評価できます。
  • 右側の列のイメージ参照は、このバージョンのイメージが現在運用環境で実行されていることを強調表示します。
  • また、このイメージは、対応する Git リポジトリ内の現在のヘッドコミットを表しており、どのイメージからビルドされたか Dockerfile を確認できます。
  • 現在および潜在的な他の基本イメージは、比較のために一覧表示されます。
画像 cve レポート 1
Text4Shell を含む一般的な CVE のリストを含む画像レポート

Slack を使用すると、チームがすでに使用しているチャンネルに通知が送信されます。 以下は、選択した Git リポジトリのセットのアクティビティを表示するように構成された Slack チャネルに送信されるアラートを示しています。 コミット、CI ビルド、デプロイなどのアクティビティに加えて、Text4Shell アラートは、このチャネルで共同作業している開発者に非常に簡潔で実用的な情報を提供します。

スラックテキスト4シェルアップデート2
重大な Text4Shell の脆弱性に関する Slack の更新

また、次のスクリーンショットのような脆弱なパッケージを更新するために、特定のカテゴリの脆弱性を修正し、プルリクエストを生成するための提案を取得することもできます。

Text4シェル修復PR 1
PRを介してText4ShellCVEを修正し、メインブランチと比較する

Docker 公式イメージや Docker 検証済みパブリッシャー イメージなどのパブリック イメージに関するこの種の情報の詳細については、 イメージ脆弱性データベースを参照してください。

脆弱性の修復は始まりに過ぎません

コンテキストデータは、脆弱性を迅速に解決するために不可欠ですが、それだけではありません。 適切なデータを適切なタイミングで提供することで、開発者はセキュリティチケットに溺れることなく、より迅速に作業し、イノベーションに時間を費やすことができます。

今日の本番イメージを評価して、潜在的に脆弱になる場所を見つけることができると想像してみてください。 チームは、 2022年11月1日火曜日に新しい重大なCVEに関するOpenSSLの今後の通知など、次の重大な脆弱性を修正する準備に数日または数週間かかる可能性があります。

Docker dso debian search 1
dso.docker.com で Debian OpenSSL を検索する

このような種類のインサイトを得て、より幸せで生産性の高い開発者にコンテキストデータを提供することに関心がありますか? 早期アクセスプログラムにサインアップ して、これらのツールを活用し、製品の改善に役立つ貴重なフィードバックを提供してください。

フィードバック

「コンテキストデータで脆弱性をより早く解決する」に関する0の考え