SBoM 支持の CISA／OpenSSF／OWASP：ソフトウェア・サプライチェーンのリスクを軽減

Gathering Momentum: 3 Steps Forward to Expand SBoM Use

2022/06/06 DarkReading — IT 環境における Software Bills of Materials (SBoM) の普及を求める声は大きくなっているが、アプリケーション・ポートフォリオで使用されている、ソフトウェア・コンポーネントの追跡のために SBoM を一貫して導入している組織は、相対的に少ないという現実がある。

Dimensional Research が実施した、最新の ReversingLabs 調査によると、現時点で SBoM を使用している企業は 3分の1未満であり、そのうち半数は、SBoM の作成とレビューのプロセスが手作業であり、何千ものコードが混在している可能性がある場合には、負担の大きなプロセスになると回答している。

しかし、セキュリティの専門家は、ソフトウェア・サプライチェーンのリスクを理解し管理するためには、SBoM が基本的なステップになると考えるようだ。現代の開発手法では、ほとんどのソフトウェア・エンジニアリング・チームが、ソフトウェアに共通機能を組み込む際に [車輪の再発明] を避け、その代わりにコミュニティにより開発されている、オープンソースのライブラリ／パッケージを使用するようになってきている。しかし、どのコンポーネントを使用するかについて、ガバナンスや可視性がなければ、脆弱性に起因するリスクが高まり、すぐに管理不能に陥る。

SBoM は開発チームに対して、アプリケーション内部で動作するコードを理解させ、基盤となるコンポーネントが脆弱だと判明した場合に、ピンポイントで対応できるよう支援する。

ReversingLabs の調査参加者が報告した SBoM 普及率の低さを考えると、その半数近くが、サプライチェーンの攻撃からソフトウェアを保護する準備ができていないと認めていることになるが、驚くには値しないだろう。

業界団体／政府機関／オープンソースコミュニティで、アプリケーションセキュリティを促進しようとする者たちは、いずれも SBoM の普及を拡大させ、ソフトウェア・サプライチェーン・セキュリティを改善するための取り組みに参加している。この数週間において、それらのグループは、SBoM の生成率を高めるだけではなく、組織がソフトウェアを保護するための SBoM 使用方法の有効性を高めることを目的とし、３つの異なるイニシアチブを立ち上げている。

CISA リスニング・グループ

先週に Cybersecurity and Infrastructure Security Agency (CISA) は、ソフトウェアとセキュリティのコミュニティのメンバーを集め、SBoMs のベストプラクティスと標準を改善する方法を議論することを目的とした、一連の公聴会を７月に予定していると発表した。

CISA は連邦政府の官報で「SBOM の概念と、その実装をさらに洗練させる必要があると、CISA は考えている。SBOM の実装を拡大し、運用するための作業は、特定の団体に左右されるのではなく、幅広いコミュニティの努力により継続されるべきだ」と述べている。CISA が進めるリスニング・セッションのトピックは、クラウドとオンライン・アプリ／SBoM の共有と交換／ツールと実装／導入と採用などである。

OpenSSF アクション・プラン

先月にワシントン DC で開催された Open Source Software Security Summit で、Linux Foundation と Open Source Security Foundation (OpenSSF) は、世界中のオープンソース／プロプライエタリ・ソフトウェアの状態を改善するための、10 項目にわたるセキュリティ動員計画を発表した。

推奨される優先事項の中には、SBoM の作成／消費を正常化するために、SBoM ツールの改善／トレーニング／業界全体での支持に焦点を当て、あらゆる場所に SBoM を配置することが含まれていた。

OpenSSF は、「SBOM が遍在すればするほど、この業界にとって価値のあるものになる。一般的に、我々は、ソフトウェアが構築／配布されるたびに、十分に検証されたツールを介して、SBOM が自動的に作成されるべきだと考えている。SBOM がソフトウェア配布においてユビキタスな存在となるには、採用のためのあらゆる摩擦を取り除く必要がある。Linux Foundation と OpenSSF は、この SBoM イニシアチブに取り組む最初の年度に、$3.2 million を投資するとおい目標を持っている。

OWASP CycloneDX の API ロールアウト

簡単に運用できる SBoM を作成するために、ソフトウェアとセキュリティのチームは、ライセンスや著作権情報からバージョン管理などのセキュリティ関連メタデータにいたるまで、すべてを含む部品表情報を通信するための、一貫した標準的な方法を必要としている。

この面では、SPDX (Linux Foundation プロジェクト) と、OWASP によるライトウェイト SBoM 標準化プロジェクト CycloneDX が、標準化の２大選択肢となっている。OpenSSF の行動計画では、SPDX 標準の改良／前進が継続される予定となる。その間に、OWASP も前進させ続けていく。最も注目すべきは、先月に OWASP が、新しいBOM Exchange API のドラフトを発表したことだ。これは、ソフトウェア・エコシステムから独立して、部品表の公開と取得の方法を標準化するために設計されたものだ。

CycloneDX 標準の共同リーダーである Patrick Dwyer は、「標準データ・フォーマットで SBOM の作成／消費をサポートする製品やツールが多数リリースされているが、システム間で SBOM を転送する標準方法は存在しなかった。この API 仕様のリリースにより、標準的な方法で各種のプロダクト／ツールは、この種のデータを転送できるようになり、SBOM プロダクト／ツールのエコシステム全体において、統合が可能になる」と述べている。

CISA／OpenSSF／OWASP が揃い踏みで SBoM オシという、とても興味深い展開です。それを無くして、ソフトウェア・サプライチェーンのリスクは軽減できないという、まっとうな考え方の基盤が SBoM にあると言っているわけです。2021年5月の米大統領令に SBoM が含まれていましたが、その伏線として SolarWinds や Kaseya の問題がありました。また、Log4j はセキュリティの問題と言うよりは、インベントリの問題という、新たな課題が突きつけられたわけです。つまり、パッチを当てようにも、その Log4 がシステム内の何処にあるのかが分からない、という問題であったわけです。