ドッカーコン

Docker Scout: ソフトウェアサプライチェーン全体の保護

Docker Scout が、リアルタイムの脆弱性の特定、修復の推奨事項、継続的なポリシー評価により、ソフトウェアサプライチェーンに関する実用的な洞察を提供する方法をご覧ください。

本日はお忙しい中、ご参加いただきありがとうございます。今回は、ソフトウェアサプライチェーンの保護に関するトピックを取り上げ、Docker Scout GAとそれに付随するすべてのことについて、今聞いたことについて直接掘り下げます。

念のため、 Docker Scout は現在一般提供されています。皆さんが立ち上げて実行されるのを見るのを本当に楽しみにしています。また、Docker Scout GAで使用できる本当にコアな機能のいくつかを示すデモを紹介します。ここではもう少し広い枠組みを設定し、Docker Scoutが最初に構築された方法と、それらの問題を解決するために構築された理由の中核となる、これらの非常に痛烈で非常にトリッキーな課題に対処するために、Docker Scoutが実際に役立つ方法のいくつかについて説明します。

概要
信号とノイズの分離
分析、修復、評価
クイックデモ
セキュリティの状態
画像を更新
脆弱性検索
質疑応答
結論
さらに詳しく

概要

大まかな概要として、Docker Scoutはソフトウェアサプライチェーン全体でこれらのシグナルを生成することに重点を置いています。基調講演で説明したすべての統合は、開発ワークフローに情報を提供するのに非常に役立ちました。そして、これらの開発ワークフローのいくつかを順を追って説明します。

開発者は、作業している場所でこれらのコンテキストレコメンデーションを使用する機会を利用して、これらの多くの統合のすべてを通じて収集されたデータを活用し、その結果として一連の修復ワークフローにステップスルーできるようにする方法を真剣に考えています。さまざまなお客様から繰り返しお話を伺い続けていること、これらの課題にどのように対処する必要があるか、Docker Scoutがそれらに正面から取り組むのにどのように役立つかについて、もう少し詳しく説明します。

信号とノイズの分離

結局のところ、開発ワークフローの終盤で問題に気づくことが原因です。おそらく、本番環境の直前に、セキュリティチームが介入し、特定のセキュリティ上の課題を解決する必要があることを開発者に伝えますが、その間、何かが本番環境に迅速にプッシュされる必要があるプロセスです。そして、さらに、洞察力が不足しています。

多くのインサイトが入ってくるかもしれません。しかし、実際には、そこから信号を抽出することは難しく、ノイズ部分に足を踏み入れます。そして、これらのインサイトは、必要なコンテキストを持たない傾向があり、幅広い統合全体で得られるエンドツーエンドの可視性が本当に欠けています。だから、次の作品に足を踏み入れると、それに付随するノイズに帰着する。

これは、非常に一般的な課題です。優先順位を付けるべき問題が多すぎて、効果的にトリアージして適切な解決策に踏み込むための情報が足りません。そして、本来本当に解決しようとしている真のリスクエクスポージャーから切り離されているのです。

そして、結局のところ、開発者のエクスペリエンスの低さと、このソフトウェアサプライチェーンをよりうまく保護する方法を解決しようとするためのすべてのコンテキストシフトについて考えると、これらの非常に反復的なタスクが発生し、多くの異なるポイントソリューションの間を行き来することになります。プロセスにおける開発チームとセキュリティチーム間のコラボレーションは困難であり、これらすべてのプロセスを通じてすべてをエンドツーエンドで追跡する効果的なメカニズムを持つための十分なトレーサビリティがないことがわかっています。

分析、修復、評価

したがって、これらの主要な課題の解決を支援することになると、この分析、修正、評価の種類のワークフローとして、いくつかの方法ですばやく要約できるものを段階的に説明します。 Docker Scoutは、分析の部分から始めて、コンポーネント、ライブラリ、ツール、プロセスを分析してコンテキストを追加し、ソフトウェアサプライチェーン全体の透明性を高め、それを修正できるようにする方法を考えるのに本当に役立ちます。 Docker Scout は、コンテキストや推奨事項を通じて、よりスマートな開発上の決定を導くのに役立ちます。

プロセス全体を通して、これらの関連する変更に基づいてこれらの修正を検出、強調表示、および提案するのに役立つポリシー評価があります。そのため、設定したポリシーに基づいてわずかな逸脱が見られ、すぐに使用できるポリシーをより多く表示できる場合は、そのコンテキストからより多くのものを表示することが非常に役立ちます。

結局のところ、最初から信頼性とセキュリティを組み込んで構築できるかどうかにかかっています。だからエイミー(・ベース)は、ここで出てくる本当に核心的な曲をたくさん踏むことができたんだ。まず、信頼できるコンテンツ、つまりDockerの公式イメージ、Dockerの検証済みパブリッシャー、Dockerがスポンサーとなっているオープンソースコンテンツも同様です。これにより、ソフトウェアアーティファクトのライフサイクル全体を追跡し、信頼できるコンテンツを最初から構築できるため、将来発生する可能性のある課題の一部を防ぐことができます。

さらに、一元化されたビューは、一元化されたインサイトの 1 つのビューから操作でき、全体的な可視性を制御し、見ているデータソースのセットに最も関連性の高いさまざまなポリシーをすべて確認することができます。そして、推奨ワークフロー — Christian Dupuis (CD) が以前にも示したデモを通じて、より速く、より確実に構築することができ、その結果、コンテキストを意識した推奨事項を開発者のワークフローに組み込むことができました。

クイックデモ

それでは、実際にCDから簡単なデモに足を踏み入れます。その前に、もう一つだけお見せしますので、ここで少しだけお見せします。ですから、ここでは簡単な概要を 1 つだけ示し、推奨される修復パス、ポリシー評価、信頼できるコンテンツが実際にどのように組み合わされ、一元化されたビュー内でさまざまな方法がすべて表示されるかをよりよく理解したいと思います。たとえば、ポリシーの時間ベースの傾向、脆弱性の数を確認し、それらの傾向線を監視して、これらの一連の決定を下す際に、より多くのコンテキストを得ることができます。それで、今度はCDに渡して、画面を切り替えます。

みなさんおはようございます。ありがとうございます。ですから、基調講演で私が許されなかったのは、事実上ライブデモをやることでした。お気づきかもしれませんが、私が始めた頃はインターネットがダウンしていたので、すでにすべてがロードされており、本当にストレスがたまっていました。そこで、製品をライブで紹介してみます。物事が壊れるかもしれません。インターネットのせいで物事がうまくいかないかもしれませんが、デモの神々は誰にもわかりません。それが私がやろうとしていることです。そして、scout.docker.com から始めたいと思います。

Jason が言ったように、Amy が先ほど言ったように、Scout は GA であり、Docker Hub アカウントでサインアップできます。最大 3 つのリポジトリを無料で試すことができます。ぜひ試してみてください。フィードバックをお寄せください。さて、ここにいます: scout.docker.com。まず最初に、ここには一種のポリシー階層が表示されます。申し訳ありませんが、最初の 4 つは、有効にするとすぐに使えるポリシーです。下の2つは、開発を終了するようなもので、非常に具体的で、現在は私の名前空間にのみ存在しています。しかし、繰り返しになりますが、最初の4つは、今日はなんとなく理解してほしいです。そして、私が間違っていなければ、それらは実際には誰でも利用できます。そうなんですか。そう思います、はい。

そのため、ログインすると、すべてのユーザーがこれらのポリシーを表示できます。私がやりたいのは、提示された情報をどのように活用し、これを自分の内なるループに取り込み、情報を使い始め、これらの違反や逸脱のいくつかを修正し始め、その流れを最後までやり遂げる方法を説明することです。

まず、ハイライトのようなこのポリシーをここで見てみましょう。これを少し大きくさせてください。そのため、Docker Hub、ECR、またはその他のオンプレミス(J4 アーティファクトツリーなど、統合可能なアーティファクトツリー)でこれらのリポジトリに最後にプッシュされたすべてのイメージが一覧表示されます。ちなみに、ここには、先ほど示したECRの統合を開始するために使用できる統合セクションがあることを述べておきます。 Sysdigはそこにあり、基調講演で強調したすべての統合があります。選択から始めましょう、私はどの画像が再び本番環境で実行されているかだけを気にしますよね? ここで、ランタイムのインサイトを取り入れます。そして、その情報を私たちに届ける方法はさまざまです。基調講演でSysdigについて言及しました。

また、CLIをデプロイパイプラインに埋め込んで、これらのイベントを送信する方法もあります。また、私たちが取り組んでいるKubernetesアドミッションコントローラーもあり、すぐに手に入れることができるかもしれません。そして、私たちがこれを使って行っていることはすべて、画像を効果的にリリースストリームにマークすることです。それらは今や環境の一部になっています。また、これらの環境をグループ化し、好きな名前を付けることができます。それらはあなたにとって本当に意味のあるものであり、私たちにとっては意味をなさないはずです。監視する環境が何であるかについては、規範的ではありません。

そのため、このイメージを Kubernetes クラスターの 1 つにデプロイしています。そして、私はここで詳細を見ることができます。これは現在、 30 日以上前の修正を含む、すべての重要で重大な脆弱性です。ただ、とても重要で、私たちが持っているアイデアです。チームは、これを構成できるようにするために懸命に取り組んでいます。それで、それは一週間でなければなりませんか? 2ヶ月にすべきでしょうか? ハイエンドにすべきか、クリティカルにすべきか? これらのポリシーを希望どおりに取得できるかどうかは、お客様次第です。ですから、私が課せられている重要で重要なものがたくさんあるのです。私はPMから、それを追いかけて修正する任務を負っています。

繰り返しになりますが、まだやっていないのは、SaaS製品をソースコードリポジトリに結び付けること、つまり、これを自動修復に結び付けることです。これもまた、私たちにとっての次のステップです。それは起こるでしょう。しかし、今はそうではありません。

ですから、私は今、この情報を受け取り、自分の内側のループに入ります。えっと。これは、私たちが使用している小さな小さなデモです。非常に単純なDockerファイルが表示されます。わざと古いダイジェストに固定して、何かに対して脆弱であることをシミュレートできるようにしています。これにこだわらないでください。そして、ノードを使用しており、たくさんのパッケージをインストールしています。かなりランダムなアプリで、フロントエンドスペースではかなり一般的だと思います。かまいません。 Scoutは、すべてのプラットフォーム、すべてのイメージタイプ、すべてのオペレーティングシステム、すべてのスタック、Java、Go、Pythonで動作します。何を使用しているかは関係ありません。そして、これが私たちのパッケージJSONです。

セキュリティの状態

まず、そのイメージでCLIを実行し、このセキュリティステータスの感覚をつかむことから始めましょう。 CVEです。大丈夫です。あっという間でしたね。そして、まず第一に、インターネットは明らかに機能しているので、それは速いです。そして第二に、この画像には多くの証明があるからです。実際、2つは、来歴とSBOM認証があることです。これらはbuildkitから出てくるので、画像にインデックスを付ける必要はありません。ですから、すべてをダウンロードするのではなく、画像を調べて、そこに何があるのかを調べます。これは、イメージの構成証明から既に取得できます。それは私たちにそれを教えてくれます。

ここには何が見えますか? もう少し詳しく。これらはすべてリンクです。そして、これは私が基調講演で示さなかったものです。そのため、クリックするとGitHubに移動します。 GitHubでバナーを見ましたが、気に入らなかったです。私はそれを本当に速くクリックします。これは興味深いリンクです。 CLIからDockerファイルの行に直接戻りますが、これらはすべて、さまざまな統合から得られる情報を関連付けることによって行われます。この場合、buildkit からの来歴は、レジストリのどこかにあります。

さて、これで何ができますか? まず第一に、私は先に進んで、パッケージタイプ:NPMだけと言うことができます。なぜなら、そこにはベースイメージからのCVEがいくつかあるからです。それでは、私が実際に気にしているもの、つまりNPMのものを最初に見てみましょう。そして、どうやらそれらは実際に使用されているようです — つまり、このイメージは現在、運用クラスターの 1 つで実行されています。 Sysdigのランタイムインサイトに接続されています。繰り返しになりますが、Docker Scoutを使用しているすべての人が利用できる無料トライアルがあると思います。そのため、Sysdigを使い始めることで、このレベルの洞察を得ることができます。

なんだかワクワクしますね。 Sysdigは、申し訳ありませんが、イメージ内のどのパッケージが実行時に使用されているかを教えてくれます。つまり、ビルドツールやシェルなど、誤ってイメージに追加したものをすべて削除します。通常、実行時には使用しないもの。 NPM ExpressパッケージとQSパッケージのこれら2つの脆弱性が修正可能であることがわかります。修正されたバージョンがあります。そして、それが私がやりたいことなのかもしれません。

すぐにポリシー画面に戻ると、両方がここに表示されます。したがって、これはポリシー違反であり、修正を求められました。私が今できることは、効果的にパッケージJSONを開き、簡単なローカルビルドを行うことです。私が今これをローカルで行っているのは、Scoutの別の機能、つまりDocker Desktopへの事実上の統合を紹介したいからです。これが実際にどれくらい速いか見てみましょう。それまでの間、私はすでにここでDockerDesktopを呼び出すことができます。さあ行こう。私は始めました。そして、ここに私の画像がリストの最初であると考えています。今すぐクリックすると、何よりもまず SBOM の視覚的表現が表示されます。画像の階層は、ここのセクションです。

そのため、ベースイメージとは何か、ベースイメージの基本イメージは何かについて、ローカルな洞察を得ることができます。現在のバージョンはもうあるのか、どうですか? この場合、私はAlpineを使用しており、新しいバージョンが利用可能です。そして、これらのレイヤーを選択し始めると、何がどこに属しているかが強調表示され始めます。ベース画像を選択すると、その画像のレイヤーが表示されます。レイヤーを選択すると、この特定のレイヤーによって導入されるパッケージが表示されます。ですから、このレイヤーは、Expressパッケージと他のすべてのNPMパッケージを追加していますが、このすべての情報に脆弱性がないことがわかります。実際、ポリシーで修正を依頼されたもののうち、すでに2つを修正しました。

画像を更新

さて、デモで強調されていると思うもう1つの本当にエキサイティングな機能は、ここでポリシー画面にすばやく戻った場合です。次に、他のポリシーを選択します。基本イメージ更新ポリシーで、これらのイメージのいずれかを選択します。ここではAMD64 バージョンに固執します。それは、あなたが知っているように、あなたの基本イメージの新しいバージョンがあることを私に教えてくれます。私は 314を使用していたので、2つのことを行います。何よりもまず、 314 画像の新しいダイジェストがあることを教えてくれます。タグを使用しています。 314タグに対して画像を作成しましたが、その間にそのタグは移動しました。

そのため、Docker Hubには更新が必要な新しいバージョンがあります。これは、from行のピンを削除した場合の単純な再構築です。しかし、このシステムは、PowerPointの最新バージョン 318 ような、実際にはより良い代替手段があることを私に教えてくれます。 Docker Desktop でも同じ情報を取得できます。したがって、同じ画面が表示されます。ご覧のとおり、 318になり、Dockerファイルでこれを行うことができます。それでは、これを簡単に実行しましょう。そして、もう一度ビルドしましょう。速かったです。そして、すべてが緑です。

そのため、いくつかの簡単な手順で、まだ自動化されていませんが、非常に有益です。これはすべてローカルで行うことができます。私たちは、開発者にレベルの洞察を提供し、それをインナーループで行えるようにすることで、大きな成功を収めています。

それでは、このイメージをプッシュしてGitリポジトリに接続するとどうなるかを簡単に見てみましょう。だから、私はおそらくこれをブランチにチェックアウトする必要があります。私はこの画像を入れて、表現してgit pushします。私はすでにその枝を持っているかもしれないと思います。よし、GitHubリポジトリに行きましょう。

私はこれを何に押し付けましたか? 私はCLIを使うべきではありません — 私は本当に愚かなツールに固執すべきです。これは現在プッシュされています。うまくいけば、GitHubのアクションが今始まっています。さあ行こう。ビルドが実行中です。これは、GitHub Actions で実行されているドキュメント送信と Docker ビルドです。これをリポジトリにプッシュし、数秒または数分以内に、scout.com に新しいイメージが表示されます。うまくいけば、更新されたポリシー結果が得られるでしょう。これが起こるのを待ちましょう。

その間、私たちが持っている別の統合を簡単に見てみませんか? 私が示したかったのは、GitHub が実行される PR やその他の接続設定で、アクションを実行し、CLI ですぐにフィードバックを効果的に取得できる GitHub アクション統合があることです。

この場合、プル要求では、PR イメージと、この場合は現在運用環境で実行されているイメージの比較に関して、CLI で見たものと同様の優れたレベルの分析情報がここに表示されます。これは、ストリームと呼ばれるもの、または現在本番環境で実行されている環境で現在実行されているバージョンです。これは、開発者がピアレビューなどを行うときにPRでこれについて推論できる場所で見ることができます。

ざっと見てみましょう。このビルドが終了した場合は、確かに完了しています。ここに行ってみましょう。そして、私たちのイメージは今そこにあります。思ったのと全然違います。まあ、幸いなことに、私はこれを前に準備しました。だからここに画像があります。

PR番号6は、同じようなものです。同じ変更でプルリクエストを発行します。そのリポジトリに戻ると、ここにプルリクエストがあることがわかります。これは、昨日準備のために提起したPR番号6です。ですから、私がローカルで行ったもの以外の変更はありません。適当な場所に何かを押し込んだに違いない。これは、私が構築しようとしたのと同じイメージです。 Scoutは、その特定のイメージで、これらの脆弱性をすべて実際に修正したと言っています。

私が修正していないポリシーの1つは、検証および添付されたSSEメタデータの一種です。このポリシーでは、SBOM と来歴証明が必要です。この特定の画像では、SBOMをプッシュしていません。

デモで強調した比較をもう一度見てみましょう。だから私はスカウト比較をすることができます。また、PR 6 のイメージを、現在運用環境で実行されているイメージに対して使用できます。これは、そのイメージをレジストリにプッシュする前に行うことができます。ローカルのDockerデーモンに存在していた可能性があり、同じように機能していたでしょう。そして、あなたは今、画像を引き下げているいくつかのものを見ています。比較したい画像の詳細をプルダウンしています。ポリシーの結果を照会し、出力を準備します。ですから、ここで上にスクロールすると、すべての詳細が表示されます。

繰り返しになりますが、これはPR番号6の画像で、変更時に準備したものです。そして、ARが私のベース画像を更新したという事実をScoutが拾ったことが分かります。今は 318 で、もう 314 ではありません。ご参考までに、どうやってこれを知ることができますか? これは、来歴構成証明の一部です。 buildkit でビルドを実行すると埋め込まれます。ビルドに入るすべてのソース、すべての材料は、いわゆる、来歴構成証明に記録されています。

では、Git コミットは何を示しているのでしょうか? 来歴構成証明に入る Git リポジトリ、そこに基本イメージ、その他さまざまなマルチステージの基本イメージはすべて、その来歴構成証明に記録されます。そしてまた、他にもいくつかの興味深い断片があり、ラベルは変更されます。そしてもちろん、この特定のケースでは、コミット表示を変更しています。そして、ここで、非常に興味深いことに、ポリシーの変更。作業中に、ここのCLIでフィードバックをすぐに確認できます。そして、ここで少し下がったのは、私は本当にオタクで、何が起こっているのかに本当に興味があるからです。

たとえば、Docker Scout が何であるかを知りたい場合です。さて、台本から外れたので、どうなるか見てみましょう。アルパイン 314 アルパイン 318。小さな画像を選ぶだけで、インターネットに情報を提供しています。今日の基調講演で Amy が言及したことの 1 つは、SBOM と来歴の証明を出荷するということです。 Dockerの公式イメージのすべてのコンテンツに署名する予定です。そうすれば、画像はSBOMが添付されているので、もうプルダウンする必要さえありません。しかし、これは、これら 2 つのバージョンの間で実際にどのパッケージが変更されたかの概要を非常に簡単に示しています。

今、私は314318と比較しています。そうすれば、私は実際にダウングレードしました、私はそれを逆にすべきでした。私はこれらすべてのパッケージを変更しました。ですから、ランダムな画像がどのように変化するかをすばやく調べる非常に興味深い方法です。それらには何が含まれていますか? それらで何ができますか? それはあなた自身の画像だけで機能するだけではありません。興味深いことに、ここには政策の成果がない。それはどうしてですか。これは、これが Docker Hub 組織にないイメージであるためです。ですから、それはあなたのイメージの1つではありません。そのためのオンラインポリシーの結果は計算していません。しかし、ここにはちょっとしたコツがあります。あなたはそれらを引き下げることができます。

これらをプルしてポリシー評価を実行すると、ポリシー評価はローカルで行われます。これは事実上、あなたの悪魔の中で、事実上私たちのポリシーであるコンテナがたくさん実行されていることを意味し、そうすればあなたは結果を得るでしょう。これは、Docker Scoutと統合したレジストリにあるリモートイメージの場合と同様に、CLIでこれらの結果を取得できます。所有していないイメージについては、引き続きプルダウンしてローカルポリシー評価を使用できます。大丈夫です。ざっと見てみましょう。

脆弱性検索

他に話せることはありますか? 以前に取り上げなかったことの 1 つは、脆弱性検索です。ですから、来週、多くの皆さんがやることの1つは、10月 11日に発表される予定のcurlというパッケージの新しい脆弱性を探すことです。ですから、理論的にどこが影響を受けるかを知ることはすでに良いことです。 [パッケージ]タブに移動して、curlの検索を開始できます。これにより、curl を使用している組織全体のすべてのイメージが得られます。そして、来週に起こることに備えることができます。そして、彼らのツイッターの発表で。彼らはシートベルトを締めろと言いました。ですから、何か深刻なことのようです。カールはカールですが、おそらく多くの人が本番環境で使用するツールではありません。しかし、誰にもわかりませんよね? レビューする価値があります。だから準備をしてください。

これを検索する方法があります。 Scoutでリポジトリを有効にしている場合は、すべての画像にインデックスが付けられています。 SBOMから出てくるすべての情報をキャプチャしたはずです。そして、私たちはあなたのためにそれを検索可能にしたでしょう。ですから、ここのポリシーページに戻ると、これを本番環境に絞り込むと言うだけで、私が気にすべきことが大幅に削減されます。そして今、私はドリルインすることができます。もちろん、CVEの詳細をすべて読んでください。さらに興味深いのは、「マイ画像」画面です。そのため、すべての画像をクリックして、本番クラスター内のすべての画像に対して分析を実行する代わりに、ここで 1 回クリックするだけで済みます。これは本番画像のみです。関心のある CVE を見つけます。影響を受ける画像を確認します。そして、あなたは行きます。

手作業で情報を検索する場合が多くあります。 Docker Scoutを有効にし、これらの統合を取り込むと、これらのものの多くはなくなります。また、今日か明日に、新たに発表されるcurl CVEのために、新しい種類の代用CVEを追加し、このページの情報を見て、影響を受ける可能性のあるすべての画像を表示できるようにします。

質疑応答

最後に質疑応答の残り 15 分くらいと言われました。あと 14 分です。それで、ジェイソン、あなたは戻ってきて、いくつかの質問のためにフロアを開きますか? 質問があれば幸いです。もちろんです。コメント。ありがとうございます。それこそが、私たちが聞きたかったことです。素晴らしい。ありがとうございました。コメントは何でしたか? すごいなぁと思います。ありがとうございました。

GitLabの統合

ここで質問します。 GitLab統合があることに気付きました。ええ、それは良い質問です。オンラインの視聴者に向けて、この質問を繰り返させてください。 GitLab統合がありますが、問題はこれがマージリクエストとうまく統合されるかどうかです。 GitHubでもそう呼ばれていると思います。それほどうまく統合されていませんが、仕事に取り掛かることができます。そのため、これらのさまざまなプラットフォームで使用できるすべてのCLIコマンドは、すべての出力がマークされています。また、マークオンを使用してコメントに入れることができます。

GitHubでは、これを行う専用のアクションを作成しました。しかし、それはGitLabやサークルや他のCLI環境のように行うことができます。はい。それはあなたの質問の答えですか? はい。それは答えですか? これは、マージ要求を表示するランタイム中だけです。しかし、Docker ScoutのWebサイトには表示されません。そうではありません。いいえ。そのため、Docker Scoutにイメージを表示する方法はさまざまです。レジストリ統合があります。そのため、現在はJFrogのオンプレミスとクラウドと統合することができます。これは、Docker Hubと、AmazonのコンテナレジストリであるECRです。また、画像を送信せずに画像のメタデータをScoutにプッシュする方法もあります。これはCLIの一部です。また、まだネイティブにサポートされていない別のレジストリを使用している場合は、その機能を使用してScoutに画像を送信できます。また、今日示したのと同じ機能を、厳密なレジストリ統合なしで使用できます。

ソナーキューブ

基調講演では、SonarQubeについて言及されました。 SonarQubeとの統合についてもう少しお話しいただけますか?

ええ、ええ、まったく。 SonarQubeで行ったことは、通常、SonarQubeにはコンテナイメージの品質メトリクスがないため、非常に興味深いことです。 SonarQube は Git ソースコードで動作します。したがって、そこで行ったことは、事実上、すべてのイメージが、イメージメタデータの一種である Git コミットから構築されるということです。

そのため、コードのプラットフォーム機能を使用して、データベースに入れたすべてのデータから接続されたグラフをバックグラウンドで効果的に構築します。つまり、イメージから Git コミットを介して、これらのコミットにアタッチされている他のものに移動できます。ビルドと同様に、SonarQube 品質ゲートなどです。つまり、ここで何が起こっているかというと、GitHubインテグレーションが設定されていれば、Gitコミットをプッシュした瞬間に、そのGitコミットを受け取るということです。

その情報があれば、SonarQube から SonarQube 品質ゲートをコミットに呼び出すイベントが送信されるのを待つことができます。次に、画像がデータベースに入ってきて、メタデータが含まれているため、コミットと関連付けられます。理想的には、それは来歴の証明であり、将来署名されることを願っています。ですから、これらすべてを結びつけることができ、それがこの特定のポリシーの仕組みです。そして、SonarQubeの品質ゲートを組織内でどのように定義するかは、本当にあなた次第です。私は標準的なものを使用し、デモの目的でいくつかの違反を追加しましたが、これらのシステムに必要なポリシーとルールを完全に自由に選択できます。

Scoutの一般的な考え方は、統合を導入し、データを取り込み、データに基づいて推論し、アクティビティを取得し、これを内側のループに取り込むことで、開発者が何らかのアクションを起こせるようにするようなものです。

VEXステートメント

スキップしたい脆弱性の例外がある場合など、例外をどのように考慮しますか? ええ、それはとても良い質問です。したがって、ここでさらに上にスクロールすると、ここに表示されるのは、この「影響を受ける」セクションです。これは本当にVEXステートメントです。

VEXステートメントは、脆弱性排除交換です。申し訳ありませんが、それは除外ではありません。搾取交換。ありがとうございます。これは除外を表すものではありません。これは、米国でSBOMを標準化しているのと同じ組織であるCISAグループから出てきた新しい仕様です。その目的は、コンテナイメージやソフトウェアアーティファクトのプロバイダーとして、特定のコンテキスト内で特定のCVEの影響を受けている、調査中、または影響を受けていないと言えるようにすることです。ここにはさまざまなレベルの粒度があり、これは製品であり、その製品内には特定のパッケージがあり、影響を受ける、影響を受けない、まだ調査中であると言えます。そして、それは将来、人々がレジストリから消費できる証明に変わることを願っています。

つまり、これはすでに、VEXサポートの脆弱性という、次に来るものの小さなプレビューです。 CLIでは、すでにこれを行っています。そこで、Sysdigの統合により、VEXステートメントを作成し、データベースに入れます。つまり、このケースでは2つの方向性があります — この画像がランタイムに使用されていることがわかったので、影響を受けるというVEXステートメントがあります。また、その逆もあり、このイメージは実行時に使用されないため、影響を受けません。そして、これらはすべてVEXステートメントで表現されており、イメージに添付したり、Gitリポジトリに入れたり、ローカルファイルシステムに置いて、CVEコマンドを実行する際に評価時にCLIにフィードすることができます。

私たちがまだ持っていないのは、その情報を scout.com に浮かび上がらせる方法ではありません。しかし、私を信じてください、それは来ています。しかし、VEXはすべてのパブリッシャーを信頼する必要はないと想定しているため、かなり複雑で複雑なプロセスです。誰かがコンテナイメージにVEXステートメントを添付したからといって、それを信頼しなければならないわけではありません。

それで、あなたは誰を信頼しますか? どの出版社を信頼していますか? それらに署名する必要がありますか? そして、私たちは現在、お客様と協力して、お客様が収集したいワークフローが何であるかを把握しており、お客様は喜んで受け入れてくれます。署名は必要ですか? 署名 ID などを指定する必要がありますか? 他にご質問はございますか?

結論

これ以上質問がない場合は、画面を切り替えて Docker クイックスタートドキュメントを表示します。ここでは、docker scout を起動して実行する方法を順を追って説明します。CDからの5分間のデモを含む簡単な概要を提供します。Docker Scoutで分析できるようにするリポジトリを有効にするために必要なさまざまな手順を示し、ドキュメント内でそれを超える多くの手順を実行します。

クイックスタートドキュメントのこのリンクを残しておきますので、すぐに立ち上げて実行するのに役立ちます。どうもありがとうございます。