安全なサプライチェーンのメタデータをわかりやすく説明する

今日は、サプライチェーンのメタデータ、それが実際に何を意味するのか、それが何であるか、そして今日どのように使用できるのかについてお話しするためにここにいます。私は基調講演や以前のプレゼンテーションを通じて、証明について非常に頻繁に言及してきました。そして、この機会を利用して、これらのものが何であるか、どのように作成できるか、 そしてDocker Scoutでそれらを使い始める方法をもう少し深く説明したいと思います。

私は話を3つのセクションに分けました。 まず、これがどこから来ているのか、サプライチェーンとは何なのかについて少しお話しします。 2 番目のセクションでは、いくつかの例を紹介します。 構成証明とは何か、どのように見えるか。 そして、最後の最後にデモをします。

サプライチェーンの例

まず、少し例を挙げましょう。 私はエンジニアです。私はコーヒーが大好きです、あなたもおそらくそうでしょう。 ここにはサプライチェーン全体が関係しており、この例えを使って、ソフトウェアについて話すときのサプライチェーンの意味を理解したいと思います。 コーヒーを本当に美味しくするために、コーヒーに入れる必要のある成分はたくさんあります。 そして、ここにはこれらのコーヒー豆があり、誰かがそれらにフェアトレードの茎を入れていますよね? コーヒーと水、豆、コーヒーマシンがカップに収まると考える方法は、サプライチェーンのようなものです。 そして、誰かが豆のように茎をつけました。

コーヒーが実際に公正に取引されていることを確認するために、コーヒーが栽培されている場所はどこでもそこに行くつもりはありません。 あなたは、誰かがあなたのためにこの主張をしてくれたと信じています。 つまり、生産者が関与していて、そのサプライチェーンは、実際に公正に取引されていることを確認するために、喜んで他の誰かに委任するものですよね? それはあなたがこれをやっているのではありません。

ある意味、これは大きな信頼です。 そして、同じ原則をソフトウェア構築にも適用できますよね? 水が水源になり、コーヒーメーカーが真ん中のビルドになり、パッケージになります。 だから、これはあなたのプロセスです。 そして、そこには、サプライチェーンに行き着く依存関係があります。 すべての依存関係とその推移的な依存関係を追いかけるわけではありません。 繰り返しになりますが、あなたは誰かがあなたのためにその仕事をし、彼らのセキュリティを主張してくれたと信じています。

しかし、ここからリスクはどこから来るのでしょうか? サプライチェーンには、うまくいかない場所がたくさんあります。 たとえば、この依存関係は、本当にあなたが考えている発行元から来ているのか、それとも誰かがGitHubリポジトリを乗っ取って、アーティファクトを偽装したのかなどです。 プロデューサーは誰ですか? ビルド環境が危険にさらされていませんか? ソースが改ざんされていませんか? 考えてみれば、これらはすべてサプライチェーン全体で攻撃される可能性があります。

これがすべて一貫しており、期待どおりであることを確認するにはどうすればよいでしょうか。 その問題を解決するにはどうすればよいでしょうか。 さて、ここでできることがいくつかあります。 まず、成果物に何が含まれているか、または理想的に消費する成果物に何が含まれているかを文書化できます。 そこで、SBOMやソフトウェアビルドの出番です。 シリアルの箱の材料に少し似ていますよね? それは、あなたが消費している、あるいはおそらくあなたが自分で構築しているそのアーティファクトに何があるべきかを理解させます。 次に、来歴とは、特定のアーティファクトがどこから来ているかに関するものです。 誰が、どのような環境で、いつ、どのようにビルドしたのか、どうすればそのビルドを再現できるのか。

来歴とポリシー

これらはすべて、来歴で捉えられています。 ビルドに使用されたすべてのマテリアル、基本イメージ、ビルド環境自体が、できればその来歴構成証明内にキャプチャされています。 そして最後に、信頼関係を築くことが大切ですよね? 誰かがこれらの成果物、これらの成果物でこれらの証明を公開するだけでは十分ではありません。 また、これらのことが信頼できる機関からのものであることを確認できる状況にある必要があります。 そこで署名の出番です。 それについても少しお話ししたいと思います。 構成証明への署名は、ソフトウェア供給のセキュリティにとって非常に重要です。 それらに署名して検証することは、本当に重要な側面です。

このデータを入手し、SBOM、出所、そして理想的にはそれらに署名してもらうと、大量のデータが得られます。 しかし、問題は、そのデータで実際に何ができるかということです。 そこで政策の出番です。 繰り返しになりますが、基調講演で述べたことは、この特定のケースでは、成果物に期待するものの企業標準を作成できるようにすることです。 署名されていますか? 誰によって署名されていますか? それらはどこに構築されていますか (GitHub 上にある可能性がありますか? 誰が署名したか、などなど。 そこでポリシーの出番となり、ポリシーの実施と評価を開始できるのです。 ある意味、私はサイクリストであり、ロードサイクリストです。 私はドイツに住んでいますが、それはここの小さな地図のようなものです。

別の例えに続いて、ポリシーとは、私にとって、GPSを自転車で走らせるとき、本当に何であるかということですよね? 野外でナビゲートする必要があるデータは非常に多くあります。 そして、執筆中に携帯電話でそれを行うことができましたが、同時に、あらゆる種類の通知を受け取ることができました。 いろんな音がするし、本当に集中したいのはサイクリングです。 そして、私はナビゲートしたいだけです。 つまり、ポリシーに関しては、まさに私たちがやろうとしていることですよね?

信頼できるコンテンツ

データに基づいて、お客様にとって本当に重要なことに集中できるように支援したいと考えています。 これらの満足感はインプットになります。 その上でポリシーを評価し、うまくいけば、将来的には修復を推進します。 つまり、Docker Scoutやサプライチェーンにデータを取り込み、その上でポリシーの評価を開始するということです。 これは、スカウトをスカウトにする3つのものの小さなサンドイッチ図です。 そのため、下部に信頼できるコンテンツがあります。 また、Dockerユーザーであれば、Dockerの公式イメージを使用したことがあるでしょう。 そして、それは私たちが信頼できるコンテンツと呼ぶものの一部です。

Dockerには、Docker公式イメージ、Docker検証済みパブリッシャー、Dockerスポンサー付きオープンソースの3つの信頼できるコンテンツプログラムがあります。 安全な基盤がなければ、安全なソフトウェアサプライチェーンを構築することはできません。 そこで、私たち (Scout チームと Docker) は、信頼できるコンテンツ画像に署名付き証明を追加することで、サンドイッチ図の下部に多額の投資を行っています。 たとえば、NodeやAlpineを例にとると、近い将来、これらのもののアテステーションが必要になると予想されますか? これが本当にDockerから来ていることがわかるように、特定のパッケージがそのイメージにあることをアサートします。 このイメージは、この権限によって、このGitコミットチャートに対するこのワークフローによってGitHub上に構築されたことをアサートします。 そのため、これらの画像がどこから来ているのかについて強力な主張を行うことができます。 そして、その背景には、私たちが記録システムと呼んでいるものがあります。

したがって、入ってくるすべてのデータは、この特定のケースでは、ここで関連するこの講演では、SBOMパッケージデータと来歴データと署名です。 そのデータはすべて保存され、Scoutのユーザーはそのデータに基づいてポリシーを評価できます。 たとえば、画像には署名されていますか? それとも、必要なすべての構成証明が画像に添付されていますか? これらは、Scoutが観察し、将来的に修正して改善するのに役立ちます。

構成証明

構成証明を使用したイメージの構築に飛び込みましょう。 誰がbuildkitでこれを調べたのかはわかりません。 しかし、来歴とSBOMとSBOM構成証明の構築を開始するために必要なのは、実質的にそれだけです。 SBOM は 1 つのパラメーターに等しく、来歴は 1 に等しく、これらはより長いパラメーターの省略形です。 なぜ必要なのかは聞かないでください。 これは、Docker CLIのレガシーです。 彼らはフラグだけを行うのではありません。 常に価値も持たなければなりません。 本当に不思議です。 しかし、繰り返しになりますが、これはSBOMと来歴を提供します。 その時点では署名されていませんが、始めるのは非常に簡単です。

これは、どの CI システムでも実行できます。 これは、ビルドとプッシュのアクションを使用した GitHub アクションを使用して、すぐに実行できます。 そこには小さな旗が掲げられています。 それを有効にするだけで、準備完了です。 そうするとどうなるでしょうか? まあ、いくつかあります。 これは例であり、BuildX イメージ ツールの "inspect" コマンドを使用してイメージ マニフェストを確認しています。

ここには多くのJSONがありますが、ここで取り上げていただきたいのは、以前にイメージを構築してそれをレジストリにプッシュしたとき、ここで最初にイメージを参照するOCIインデックスを構築しているということです。 これは、標準のDockerイメージまたはコンテナイメージです。

ここには、ダイジェストによってここにある元のイメージを効果的に参照している未知のアーキテクチャを持つ新しいイメージがあります。 そして、それが証明です。 それで、それはあなたの画像に添付されています。 これはOCIインデックスの一部です。 そのため、すべてのOCIレジストリと下位互換性があります。 今後、参照型が使用可能になったときに、参照型のサポートを検討する予定です。 そのため、OCI仕様の新しい部分には参照型があり、外部アーティファクトを他のものにアタッチできます。 普及していないことを考えると、まだ最終バージョンとしてリリースされておらず、すべてのレジストリで利用できるわけではありません。 Buildkit は、この時点ですべてのレジストリで機能するこれらの OCI インデックスを生成しています。

もう少し深く掘り下げてみましょう。 この構成証明の画像を見てみましょう。 これは、これらの構成証明イメージの 1 つを見ているときに得られるものです。 2つのレイヤーがあります。 通常、Dockerイメージを見ると、Dockerレイヤーごとにレイヤーが取得され、それがバイナリコンテンツになります。 これはファイルシステムのテーブルですよね? オーバーレイファイルシステム。 この特定のケースでは、画像ではありません。 構成証明ごとに 1 つのレイヤーです。 そして、これがどの構成証明であるかは、この述語型によって専用されます。 これは、SBOM の標準形式の 1 つである SPDX ドキュメントであることがわかります。 したがって、この場合、そのレイヤーは SBOM を表し、このレイヤー (SLSA の来歴) は来歴構成証明です。

これらの構成証明レイヤーの 1 つを掘り下げてみましょう。 だから、今、私はこれが本当にintotoステートメントであることがわかります。 そして、in-totoステートメントは、サブジェクトをバインドする方法です。 たとえば、特定の述語に対して何をアドレス指定しますか? この場合、2つのタグに効果的に対処しており、これはここで確認できます。 これは最新のもので、ここには別のタグ、コミットチャートがあります。 したがって、これらは私がいくつかのコンテンツを証明したい主題であり、ここではすべてを削除しました。

これがSBOMが目指すところです。 たとえば、標準のSPDXドキュメントはここに配置されます。 これにより、来歴とSBOM構成証明を含む構成証明イメージを含むOCI索引が提供されます。 もちろん、マルチアーキテクチャのイメージを構築している場合、これは増える一方です。 そのため、AMD64などのイメージが 1 つあり、構成証明イメージがあり、Arm64 と構成証明イメージがあります。 だから、彼らはいつもペアで行きます。 そして、あなたはそれらをコピーすることができますよね? これらの画像を引っ張ると、下に引っ張られるように動きます。 それらを独自のオンプレミスレジストリにコピーすると、そこでも使用できます。

オープンパブキー

さて、今日の基調講演では、本当に興味深いことがかなり静かに発表されました。しかし、Dockerはついにこれらの構成証明に署名し始めました。そして、 OpenPubkey と呼ばれるテクノロジーを使用します。そして、そのテクノロジーは、私たちが提携している BastionZero という会社によって開拓されました。そして、開発者にとって、そしてうまくいけばこの聴衆にとって本当に興味深いのは、これがゼロ構成の署名ソリューションであるということです。

したがって、この演習の目標は、結局のところ、GitHub アクションを使用して Docker イメージを構築している場合、または別の OIDC プロバイダーが利用可能な環境 (Amazon 上) を構築している場合、Google でそれを取得できるようにすることです。何もする必要はありません。そして、これらの認証は、たとえば GitHub で実行しているという事実、たとえば Google のクラウド ビルドで実行しているという事実によって署名され始めます。そこで本日、Bastion Zeroとの パートナーシップを発表 しました。

また、Linux Foundationのイニシアチブも発表しました。 そこで、ソースコード全体をLinux Foundationに寄贈しました。 だからこれを調べ始めてください。 これは、このすべてのコードが存在する GitHub リポジトリと GitHub 組織です。 そして、私たちが発表したものは最終製品ではありません。 これは旅の始まりであり、信頼を確立するには多くの作業が必要になるため、コミュニティを巻き込みたいと考えています。 提案を検証するためのセキュリティ研究者などが必要です。

しかし、この機会に、たとえば buildkit で OpenPubkey を使い始めると何が変わるのかをお見せしたいと思います。 以前に、主語と述語を持つ in-toto ステートメントがあったことを思い出してください。 今、私たちはそのステートメントを封筒に置き換えています、in-toto仕様の一部です。 そして、それにはペイロードがあり、これもin-totoステートメントであり、ベース64 エンコードされています。 そして、signatures配列には、OIDC OpenPubkey署名があります。

そして、その署名、そして私はすぐにあなたにこれを見せます。 多くのアサーションを行うことができます。 これは、ある物が特定のIDによって署名されていることを確認するだけではありません。 これはGitHub Actionsから出てくるものです。 そこにはもっとたくさんあります。

したがって、たとえば、タグを検証できます。 生成されたGitHub Actionワークフローの名前を確認できます。 それはこれを生み出しました—それはあなたが期待していたものですか? 確認でき、これはここでリポジトリ自体の ID です。 GitHub は、すべての組織ごとに一意の ID を保持します。 そのため、組織を削除しても、他のユーザはその組織に名前をしゃがむことはできません。 ですから、これはDocker組織だと言っても過言ではありません。 この時点で、これがDockerから来ていることを正確に知っています。 そして、GitHubはここに立って、これが信頼できるものであることを確認しています。

前述したように、来歴構成証明には Git 共有が含まれています。 また、署名された OIDC にも同じ情報が含まれています。 したがって、これら2つが実際に一致していることを比較できます。 つまり、私のイメージにあるものは、実際にはGitHubが私たちのためにクローンしたものだったのですよね? ここにしっかりと接続があり、物が汚れていないことを確認してください。 これは本当に重要なことです。 これにより、これについて多くの強力なアサーションを行うことができます。

ここで強調したいのは、現在コンテナ署名に関する多くの署名ソリューションでは、検証がオプトインのようなものになっているということです。 そのため、いつでもバイパスできます。 そのため、署名されたイメージ、署名された構成証明ができあがります。 でも、あなたは本当に親切ではありません、私は強制とは言いません。 しかし、オプトインはそれほど強力なセキュリティ体制ではありませんよね? 開発者が Docker のプルや Docker の実行を行うたびに、あなたとあなたの組織が「よし、これらのイメージは Docker で署名する必要がある」と判断するようにする必要があります。 一致する来歴の破片が必要です。 これが、これらが出てくるはずのワークフローであることを知る必要があります。

Docker CLI

これらのDockerCLI操作の一部にします。 そして、CLIで出荷ポリシーを開始します。 もちろん、上書きすることもできます。 そうすれば、少なくともこれらのDOIイメージ、Dockerの公式イメージが検証され、本物のDockerではないものができあがることはありません。 これは、「Docker run」と入力した場合も同じです。 そしてもちろん、Docker pull についても触れました。 他にも検討中のランタイム統合があり、署名も可能なメタデータです。

しかし、もしあなたがソフトウェアのプロデューサーで、脆弱性スキャナーがやってきて、消費者に「コンテナは何かに対して脆弱である」とか「あなたのイメージは何かに対して脆弱である」と伝えるのであれば、その概念全体について言及する価値があると思います。 あなたは、X、私はコンテナに緩和策を持っているので、実際には影響を受けていないと言いたいかもしれません。 これは実行時には実行されません。 あるいは、そうだ、私は影響を受けている、と言いたくなる。 そして、それはあなたがする必要があることです。 これを修正するイメージの次のバージョンにアップグレードする必要があります。

VEX(ベックス)

そこで登場するのが、Vulnerability Exploitation eXchangeの仕様です。 これは、CISAが標準化しているものの1つであり、政府機関が出荷することを期待するものなどです。 つまり、SBOMで行っていることと似ています。 新しい仕様。 Vexは脆弱性の除外を意味していないことを知っておくことが本当に重要だと思います。 また、あるソフトウェアのプロデューサーが、私が影響を受けていることをあなたに伝えたいということも意味します。 つまり、これは、特定の製品に対する特定のCVE、特定の脆弱性のステータスを伝える方法です。

そして、ここでもう一つ覚えておいていただきたいのは、その発言を信用する必要はないということですよね? 繰り返しになりますが、署名は可能であり、署名されるべきであり、最終的には消費者が、まあ、Dockerを信頼しています、Dockerの公式イメージには、これは悪用できないというVEXステートメントがあるはずです。 私は、Microsoftが、これがWindowsコンテナなどに悪用できないと信じています。 しかし、私はDocker Hubのランダムな人を信用しておらず、それは悪用できないと言っています。 右。 ですから、ここでも署名にはある程度の信頼があります。 これらの事柄が署名されている。私たちはそれを強制し始めることができます。

そして、これは非常に基本的なVEXドキュメントです。 ここに少しメタデータがあることがわかりますが、作成者は誰ですか? そして、ステートメントに取り掛かります。 そこには複数のステートメントを含めることができます。 緑があまり読みにくいことは承知しています。 しかし、うまくいけば、私はこれをもう少し詳しく説明することができます。 ここでCVE IDを取得し、特定のDockerイメージ内で、特定のNPMパッケージを脆弱にしないようにします。 影響を受けないと言いたいのですが、影響を受けていないと言うときは、正当化を明示しなければなりません。 それを回避する方法はありませんし、そうでなければ有効なVEXステートメントにはなりません。 そして、この場合、または私は単にインライン緩和策がすでに存在すると言います。 したがって、これはすでにコンテナで修正されています。 大丈夫です。 試してみて、うまくいくかどうか見てみましょう。

デモ

それでは、デモを見ていきましょう。 ここでソースコードを手短に紹介しましょう。 これは非常に単純なアプリケーション、つまりNodeアプリケーションです。 アルパインを使用しています。 PINダイジェストを使用して脆弱性を作成し、Dockerビルドを実行するときに時間をさかのぼり、脆弱性のあるイメージをキャッチします。 それでは、これをすばやく実行して、ここでDockerビルドを実行しましょう。 このイメージを来歴とSBOMで構築し、これをDocker Hubにプッシュしたいと思います。 そして、これを行うと、このbuildkitスキャナーが入ってくることがわかります。 これは、SBOMを作成するためにビルドキットに追加されています。

また、ここでわかるもう 1 つのことは、1 つのアーキテクチャ イメージに対して 1 つのマニフェストをプッシュするだけでなく、実際には構成証明マニフェストとマニフェスト リストをプッシュしているということです。 したがって、前述のように、これらすべてのアーティファクト。 さて、ここでこのタグをつかんで、もう少し視覚的にしましょう。 これは非常にシンプルなアプリケーションです—オンラインサービス。 Dockerイメージに関するメタデータをイントロスペクトしたい場合、これはそれを行うのに最適な方法です。

これを見ると、先ほどもこんな感じで。 これで、OCIインデックスが作成されました。 これは、先ほど作成したイメージです。 そして、ここに構成証明画像があります。 これで、ここをクリックしてドリルインを開始できますよね? だからこそ、これは本当に便利です。 2 つの構成証明が表示されます。 SBOM を構築し、来歴構成証明を構築しました。

ここで出所を少し掘り下げると、非常に多くの情報が表示されます。 しかし、まず、主題を見ます。 そこで、特定のプラットフォーム用のタグ cd を作成しました。 それはまた、特定のダイジェストのためでもありました。 ですから、これもテストしています。 そして、そのbuildkitが私たちのためにキャプチャしたすべての情報は次のとおりです。 タグとダイジェストでベースイメージが追加されているのがわかるので、推測はもうありません。 基本イメージの正しいバージョンを使用していますか? これは時代遅れですか? すべてがその場でキャプチャされています。 ソースマップのようになります。 そのため、個々のビルド ステップがすべて取得されます。 これらは入力と環境です。 buildkit の初期バージョンでは、ここにも秘密が見えていました。 しかし、彼らはその間にそれを修正しました。

そして、私たちが最後まで行くならば、これらはすべてビルドステップです。 そして、ラベルが表示されます。 材料が入ってくるのが見えます。 これにより、どの buildkit スキャナーが使用されていたか、どのバージョンの buildkit が使用されたかがわかります。 ビルドに含まれるすべてのものがどのように文書化されているかがわかり始めます。 ビルドがどのように関与していたか、そしてどのレイヤーがずっと下まで生成されていたかを確認できます。

このエリアは本当に面白いです。 どこかで見つけたイメージからDockerファイルを再構築しようとしたことがありますか? 私は初期の頃にこれを非常に多く行ってきました。 これは、ここでベース64 文字列データとして使用およびコード化されていたDockerファイルです。 そして、これは、すべてのソースマップのようなものがあるために行われます。 そのため、イメージの各レイヤーをDockerファイル内の特定の命令に関連付けることができます。 そして、それはすべて来歴証明にカプセル化されています。 ここには、Git メタデータのようなものがあります。 何が作られていたのか? 私はGitリポジトリからビルドしました。 これは、Git リモート URL とコミット SHA です。

一歩戻って、SBOMについて簡単に見てみましょう。 ここでも主語と述語です。 この場合は、SPDX ドキュメントです。 SPDX ドキュメントは、3 つの最上位要素で構成されています。 それは、ファイル、パッケージ、そしてこれら 2 つの間の関係です。 したがって、最初に、識別されているすべてのファイルを確認します。 非常に長い時間スクロールすると、パッケージが表示されます。 ここでは、どのパッケージがどのファイルを参照しているかなどの参照が表示されます。 私はあなたのためのパッケージを本当に速く見つけさせてください。 大量のデータ。 さあ行こう。

これは、パッケージが表現される方法です。 それらには、名前、メタデータ、外部参照があります。 ここには「purl」がありますが、これはDockerで使用し、CVEと照合するために非常に重要です。 繰り返しになりますが、より多くのメタデータです。 その後、ファイルとの関係を確立すると、このパッケージがコンテナーのどこに追加されたかをすぐに知ることができます。 「docker scout」と入力して、これをすばやく実行しましょう。 このイメージを本当に早く取り入れたいです。 そして、今ここでわかるのは、実際には画像をプルダウンする必要がなかったということです。 これら 2 つの構成証明からすべての情報を取得したので、ベース イメージが何であったかを正確に伝えることができます。

ここでも、あなたはそれが来歴で捕捉されているのを見ました。 この画像がどこから来ているのか、どのgitリポジトリなのか、正確な場所を教えてくれます。 ここには、うまくいけばGitHubに連れて行ってくれるリンクもあります。 そして、非常に重要なことに、ここにはこれらの行があります。 したがって、この「libSSL」(OpenSSLパッケージの一部)は、この特定のケースではベースイメージから出ています。 つまり、それはレイヤーゼロから出てきており、これはまさにこの作品がここで私たちに伝えていることです。 ここでも、来歴構成証明を使用して、ファイル関係による特定のパッケージが Docker ファイルの特定のレイヤーによって追加されたという情報を照合することができました。 そして、あなたは実際にここでテキストを読むことができ、もちろん、これをクリックするとGitHubの行に直接移動します。 ここには、改行など、このような他の例があります。 これはまさに、Dockerファイルでどのように見えるかです。

次に、簡単なVEXステートメントを作成しましたが、これを適用し始めるとどうなるかをお見せします。 これを画像に添付する方法はいくつかあります。 これはScoutに保存できます。 この特定のケースでは、VEX、locationを言って、ディレクトリまたはファイルパスを渡します。 そしてすぐに、Expressの脆弱性を効果的に解決したことがわかります。

そして、この場合、私はこれを信頼します。 「私はクリスチャンを信頼していない」と言うことができる他のさまざまなCLIオプションがあります。 私はこの男だけを信頼しています。 ですから、消費者として「よし、これを信頼する」と言うのは、本当にあなた次第です。 しかし、これは追加情報を提示するための優れた方法です。 以前の基調講演にご参加いただいた方もいらっしゃると思いますが、私たちは、Sysdigや将来的には他の統合機能などを使用して、イメージを本番環境にデプロイする際に、実行時にどのパッケージが使用されているかを伝えるために同じ技術を使用していました。 したがって、これらはロードされたパッケージを確認する必要があります。 右。

OpenPubkey 組織にはサンプルリポジトリがあり、変更点を簡単に紹介したいと思います。 これらの構成証明画像の 1 つを見ると、ここではまったく同じように見えます。 何が変わるかというと、掘り下げ始めるときです...来歴をクリックすると、ここでは、主語と述語を含む in-toto ステートメントを表示する代わりに、ペイロードを取得します。 これもまたステートメントであり、ここに署名があります。 あとは、OpenPubkey組織にリリースしたばかりの新しいプラグインを実行するだけで、今日から使い始めて可能性を探ることができます。

2 つの構成証明を想定していることがわかります。 これらの構成証明は両方とも、特定の条件で検証されます。 たとえば、正しいタグを参照しているため、誰も改ざんしていないのでしょうか? そして、正しいタグ、トークンは正しい機関によって署名されていますか? それは正しいGitHub Actionの実行のようなものですか、そしてリポジトリの所有者は実際に一致していますか? この場合、Docker ではなく OpenPubkey です。 また、来歴の構成証明についても同じで、git commitの周りのアサーションが追加されています。

最後にもう1つお見せしたいことがあります。 ここにはデモリポジトリがあるので、GitHubでイメージを構築している場合。 ここでは、そのテクノロジを使用してこれらのイメージの署名を開始するようにビルドを設定する方法の簡単なデモを示します。 「docker build and push」アクションに精通している場合、これは実際にはまったく変更されていません。 この特定の部分に必要な構成はありません。 今のところ、手動で行うのは、反対側の3つのドライバーを追加する必要があることだけです。 将来的にはこれをビルドアクトに組み込むことで変更する予定ですが、実際にこれをツールに組み込み始めています。 別の buildkit イメージを効果的に使用し、GitHub が既に提供しているいくつかの環境変数を渡す必要があります。 これを使用して、イメージの署名を開始し、新しい署名テクノロジの調査を開始できます。

質疑応答

残り約 10 分です。 今日は何か質問はありますか? 大丈夫です。

私が理解していることを確認するための簡単なシナリオです。 つまり、Django上に構築されたWebサイトがあり、ローカルにコンテナがあり、そのコンテナのビルドを行うか、そのイメージのビルドを実行してArtifactoryにプッシュします。 それをSBOM内でプッシュして、同僚がArtifactoryから追加し、すべてがうまくいっていることを知ってもらうには、どうすればよいでしょうか?

右。 このコマンドは、これをArtifactoryにプッシュした場合とまったく同じように機能します。 それは全く変わりません。 ここのタグをArtifactoryへの参照に置き換えると、事実上、来歴とSBOMを使用してイメージを作成し、Artifactoryに送信し始めることになります。 はい。 文字通り、それだけで十分です。 ありがとうございます。

他に質問はありますか? サインインを合計すると、たとえば、この基本64エンコードされた来歴になります。 そこからどうやって出所を回復させるのですか? なぜなら、それは来歴全体を網羅するのに十分な長さではないように見えたからです。 右。 これは実際には完全なペイロードです。 魔法は起こっていません。 中に入って見てみましょう。 実際にはかなり長いです。

大丈夫です。 それだけだと思います。 ありがとうございます。 素晴らしい一日をお過ごしください。

詳しく見る

• Docker Scout GAの発表:ソフトウェアサプライチェーンのための実用的な洞察
• Docker Scout 製品ページ
• Docker Scout デザイン パートナー プログラム
• Docker Scout をお試しください
• 立ち上げて実行したいですか?クイックスタートガイドを使用する
• DockerCon 2023 のハイライト (新しい Docker Local、Cloud、AI/ML のイノベーション)