Docker’s BuildKit adds SBOM attestation capabilities: How they work — and key limitations
2023/04/04 SecurityBoulevard — 今年の初めに Docker は、BuildKit ツールにおいて、ビルド時の証明書と SBOM (Software Bills of Materials) のサポートを追加し、それぞれのイメージ内のソフトウェア・コンポーネントのビルド・プロセスを、開発チームが完全に記録する方法を提供するようになった。BuildKit とは、コンテナ・イメージを構築するための Docker のビルド・エンジンであり、従来からのスクリプト・ベースの Dockerfile ビルド・エンジンを改良したものである。Docker は、このツールにより、ビルドのパフォーマンスが向上し、Dockerfile の再利用性が高まったと主張している。
これらの機能は、ソフトウェア・サプライチェーンのセキュリティにとって不可欠なものとなる。ただし、あなたの組織が、どれだけ恩恵を受けられるかは、SBOM のデータ品質、SBOM インベントリを管理する能力、そして、SBOMに対する可視性により異なってくる。
ここでは、BuildKit について知っておくべきこと、SBOM 機能を活用する方法、ソフトウェア・サプライチェーンのセキュリティを包括的に把握する際の限界について説明していく。
ビルド時の証明書 (attestation) を重要な一歩とする
2023年1月にリリースされた BuildKit v0.11 に、新たに導入された SBOM 機能を活用する開発者は、パッケージ名／バージョン番号／ライセンスタイプ／作成者などの関連メタデータを含む、イメージ内の全コンポーネントのリストを生成できる。
ビルド時の証明書は、SLSA (Supply Chain Levels for Software Artifacts) の証明に関連する質問に対して、開発者に回答方法を提供する。そこに含まれるのは、イメージのビルド・プロセスで使用された、ファイル／URL／パラメータに関するデータや、イメージを作成した Dockerfile にマッピングするためのソースマップなどである。
セキュリティの専門家たちは、ソフトウェア・サプライチェーン・セキュリティの観点から、この種の機能が極めて重要であると考えている。SBOM は、食品のパッケージに記載される成分表のように、ソフトウェア製品に含まれる、すべてのコンポーネントを列挙したものとなる。SBOM を活用する開発者は、特定の CVE に対して脆弱なイメージについて、アップデートの必要性の有無を容易に特定できる。
Apache Log4j ロギング・フレームワークで発生した、脆弱性 Log4Shell のような問題が大きな波紋を生じたことで、脅威を迅速に特定／緩和するための SBOM の有用性が理解されてきた。SLSA の履歴により、イメージが構築された方法や、構築プロセスで使用されたソースの正当性などの分析が促進される。開発者は、証明書のビルド・パラメータを使用してイメージを再構築し、それが証明書と一致するかどうかを検証できる。
SBOM と SLSA の重要性は高まり続けている
SBOM と SLSA が保持する履歴が、ここ 2 年間で重要度を増してきている。2021年5月の大統領令により、すべての連邦民間行政機関は、外部のソフトウェア・プロバイダーに詳細な SBOM を要求し、維持することが義務づけられた。この大統領令は、SolarWinds や Colonial Pipeline などへの攻撃をきっかけに、ソフトウェア・サプライチェーンへの脅威に対して、危機感が高まったことに起因している。
IT-Harvest の Chief Research Analyst である Richard Stiennon は、Docker の Buildkit アップデートにより、コンテナ内のコンポーネントの追跡／証明を、開発者は可能にすると述べている。
Richard Stiennon は、「コンテナの特性として、たとえば納品されたソフトウェア・パッケージよりも儚いものという傾向があるため、記録を残すことが極めて重要となる。それぞれのビルドに添付される SBOM は、記録を保持するだけでなく、コンテナに問題があると確認された場合に、その状態を理解する上で貴重なものとなるだろう」と述べている。
SBOM は、サプライチェーン・セキュリティを向上させるための重要な要素であり、新しい CVE (Common Vulnerabilities and Exposures) アラートが発行されたときに、ソフトウェアの利用者に導入されたコンポーネントの脆弱度を、迅速に特定できるようになる。Stiennon が、「新たに Docker に加わった機能により、特定における粒度が微細になる」と発言している。
課題：SBOM から真の価値を引き出す方法について
この新しい機能から、組織が得ることが可能な本当の価値は、その使い方次第だと、Vulcan Cyber の Technical Marketing Engineer である Mike Parkin は言う。
Mike Parkin は、「この新しい機能が意図したとおりに動作し、正確で完全な SBOM を作成できるなら、少なくとも概念的にはかなり有用となる。原材料のラベルのようなものであり、アレルギーのあるものが入っていないかどうかを知らせてくれる」と述べている。
しかし、SBOM が、本来の目的で使用されるのか、それとも、単に部品リストを維持するために使用されるのかにより、多くのことが変化してくる。その点では、ログ・ファイルに似ている。ログ。ファイルを収集して、それを見直すのであれば、素晴らしいことだ。しかし、「最後にログを見たのはいつか」という問に対して、「2019年6月」が答えなら、あまり意味がないだろう。
2023年2月に、オーストラリアの大学の研究者たち実証研究では、SBOM の利用に関連する他の課題として、組織が SBOM の価値を十分に引き出したいのであれば、克服しなければならないものが挙げられている。この研究は、15カ国の 65人の回答者から集めたデータに基づくものであり、SBOM はトレーサビリティ／アカウンタビリティ／セキュリティを向上させることが可能だと判明した。しかし、標準的でないフォーマットや、相互運用性の欠如により、追跡／利用／管理が困難になることが多い。
また、SBOM を利用するためのツールも、いま以上に成熟し、使い易くなる必要がある。その他の制限的な要因としては、SBOM が含むべき最小のデータ・フィールドに関するコンセンサスの欠如や、ソフトウェア製品の進化に伴い、SBOM 情報を再生成／強化する際の標準的な方式の欠如などがある。
オーストラリアの研究では、SBOM を検証した際の別の課題も挙げている。現時点において、SBOM に対する改ざんの有無の判断や、SBOM 生成したツールの検証などについて、なんのフレームワークも存在しないと指摘されている。
研究者たちは、「SBOM データの改ざんは、組織の外部と内部から起こりうる。SBOM の改ざんは容易であり、信頼できる検証方法がなければ簡単に偽造される、外部からの改ざんも簡単である」と述べている。
Center for Security and Emerging Technology の non-resident fellow であり、Deploy Securely の著者でもある Walter H. Haydock と、Aquia の共同設立者兼 CISO である Chris Hughes は、SaaS (software as a service) ような、ベンダーがデプロイメントを管理する環境での開発において、ある時点と、別のある時点の SBOM に、何があるのかという曖昧さが、リスク管理ツールとしての SBOM の有効利用へのハードルになっている」と、CSO Online の記事で述べている。
彼らは、「利用者が SBOM を受け取った後に、どうするかという答えがないことに加えて、SaaS (software as a service) ような、ベンダーがデプロイメントを管理するモデルにおいて、どのように作成すべきかという点は、さらに不明確である」と指摘している。
SBOM の自動化／標準化／集中化を求める声
ReversingLabs の Field CISO である Matt Rose は、「SBOM における重要な問題の大半は、静的なものであるという点であり、それは時間のスナップショットに過ぎない。DevOps パイプラインのスピードは、静的な SBOM とは正反対である。他のセキュリティ・ソリューションと同様に、SBOM にはリアルタイムでリスクを表す必要性があり、そうでなければ単なるノイズに過ぎない」と指摘している。
Matt Rose は、「アプリケーションやソフトウェアのアップデートを、１日に10回のペースでリリースするのなら、新しい SBOM を１日に10回のペースで自動生成する必要がある」と述べている。
彼は、「静的な SBOM が、誤った安心感につながることを懸念している。さらに、SBOM の中には、パッケージの一部だけに注目するものもある。たとえば、SCA (Software Composition Analysis) ツールは、オープンソースのパッケージしか見ていない。SBOM は話題になっているが、まだ重要な部分が欠落している。SBOM は、どのようなフォーマットで、どのように共有されているのか？ 現時点において、SBOM に関する全体の議論少し曖昧であり、また、Cyclone DX のような標準フォーマットが必要だ」と指摘している。
アナリスト企業 KuppingerCole の Director of IAM Research である Richard Hill は、「包括的なセキュリティ・アプローチは、ソフトウェア開発／エンジニアリング／リリースといった、ライフサイクル全体に End-to-End でフォーカスすることが必要だ。ソフトウェア・サプライチェーンを保護する場合には、ソフトウェア・システム・アーキテクチャの作成し、デザインに応じたコーディングを開始する段階で、セキュリティとプライバシーを考慮し、ソフトウェアのデプロイメントとライフサイクルを通して、それらを継続していく。つまり、長い旅となる」と、最近の分析記事に記している。
Docker の BuildKit ツールで SBOM がサポートされたという記事ですが、さまざまなセキュリティ専門家たちによるコメントが興味深いですね。それぞれに対して、ナルホドと頷いてしまいます。米国では、本来であれば、そろそろ SBOM の正式運用が始まる時期のはずですが、以下の記事をみると、遅れるのかと思えてきます。そう簡単ではなく、準備に時間がかかるものなのでしょう。
2023/01/19：SBOM：最小限要素を満たすものは１％
2022/12/02：SBOM：要件の延期を米議会に提出
2022/11/30：米国の国防産業：87％ がセキュリティ要件に不適合
IoT OT Security News 
You must be logged in to post a comment.