Docker SBOM: Docker イメージの可視化へ向けての一歩

Docker はコンテナ イメージの中身をより可視化し、ソフトウェア サプライチェーンをより安全にするための第一歩を踏み出しました。Docker Desktop 4.7.0 に含まれる新しい実験的な docker sbom CLI コマンドは、あらゆる Docker イメージの SBOM (Software Bill Of Materials) を表示することができます。また、今後のリリースでは、Linuxパッケージにも含まれる予定です。この機能は、Anchore 社 Syft プロジェクトを利用して、オープンソースのコラボレーションとして開発されました。

Dockerでは、パフォーマンス、信頼、素晴らしい体験が優先事項です。この作業は、イメージの中身を簡単に確認できるようにし、ソフトウェアの消費者に SBOM を提供することによってサプライチェーンの信頼を向上させ、コンテナイメージをより透明にして、その中身を簡単に確認できるようにして開発者の体験を向上させることに重点を置いています。このコマンドは、Docker がコンテナ イメージをより自己記述的にするために行っている最初のステップに過ぎません。Dockerは、コンテナイメージの中身を判断し記録するのに最適なタイミングは、docker build でイメージを組み立てるときだと考えています。これを可能にするために、パートナーやコミュニティが BuildKit の拡張性を利用して、SBOM 機能を docker build に簡単に追加できるように取り組んでいます。

この情報はビルド時に生成されるため、イメージ アーティファクトの一部として含まれるべきだと考えています。つまり、レジストリ間で (あるいはエアギャップ環境で) イメージを移動しても、イメージから SBOM や他の画像のビルド メタデータを読み取ることができるはずです。

SBOMとは?

ソフトウェア部品表 (Software Bill Of Materials: SBOM) は、出荷時のパッキング リストに似ています。コンテナ イメージの場合、インストールされるオペレーティング システム パッケージ (例:ca-certificates) と、ソフトウェアが依存する言語固有のパッケージ (例:log4j) が含まれます。SBOM は、これらの情報の一部だけを含むこともでき、またコンポーネントのバージョンやその出所など、さらに詳細な情報を含むこともできます。

SBOM は、政府またはサプライチェーンのセキュリティを向上させようとしている他のソフトウェア消費者から要求されることがあります。これは、ソフトウェアの中身を知ることで、安全に使えるという確信が得られるとともに、脆弱性が公開されたときの影響を把握するのに役立つことが理由となっています。

コンテナ イメージの SBOM を使って脆弱性を確認

log4shell のような脆弱性が公開されたときに、docker sbom コマンドで何ができるのか、簡単に見てみましょう。このような脆弱性が現れたとき、自分のソフトウェアが影響を受けているかどうかを素早く判断できることは非常に重要です。今回は、neo4j:4.4.5 Docker Official Image を使用します。docker sbom neo4j:4.4.5  を実行するだけで、SBOM の表形式が出力されます。

$ docker sbom neo4j:4.4.5

Syft v0.42.2

 ✔ Loaded image            

 ✔ Parsed image            

 ✔ Cataloged packages      [385 packages]

 

NAME                      VERSION                        TYPE

… 

bsdutils                  1:2.36.1-8+deb11u1             deb

ca-certificates           20210119                       deb

log4j-api                 2.17.1                         java-archive  

log4j-core                2.17.1                         java-archive  

この出力には、イメージ内にインストールされた  Debian  パッケージだけでなく、 アプリケーションで使用されている  Java  ライブラリも含まれていることに注意してください。この情報を確実かつ最小限の労力で得ることで、迅速に対応することができ、侵入される可能性を減らすことができます。上記の例では、Neo4j  がバージョン  2.17.1  の  log4j-core  ライブラリを使用しているため、log4shell  の影響を受けないことがわかります。

docker sbom やその他の SBOM スキャンツールがない場合、アプリケーションのソースコードを確認して、使用している log4j-core のバージョンを確認する必要があります。複数のアプリケーションやサービスをデプロイし、複数のバージョンを使用している場合、これは困難なことです。

SBOM を表形式で出力するだけでなく、docker sbom コマンドには、標準の SPDX と CycloneDX 形式、および GitHub とネイティブの Syft 形式で SBOM を出力するオプションが用意されています。

次のステップ

Dockereは、パートナーやコミュニティと協力して、BuildKit を通じてすべてのコンテナ イメージに SBOM を導入したいと考えています。また、実験的な docker sbom コマンドを試してみて、ご意見をお聞かせください。Anchore 社との docker sbom の共同作業については、こちらのブログで詳しく説明されています。

 

 

Docker Business の詳細は、弊社 Web サイトをご確認ください。

 

記事参照:
© 2022 Docker
2022 年 4 月 7 日

Announcing Docker SBOM: A step towards more visibility into Docker images

タイトルとURLをコピーしました