オープンソースを安全に活用するために（SBOMの動向）

　こんにちは、吉田行男です。2020年12月13日、IT管理ソフトやリモート監視ツールの開発を行うSolarWindsは同社が開発するOrion Platformにバックドアが含まれていたことを公表しました。同社の製品は米国の多数の政府機関、企業で導入されていたため影響範囲が広く、またFireEyeが12月8日に発表した不正アクセス事案との関連があったことから米国を中心に大きな注目を浴びる事案となりました。また、2021年5月7日、ランサムウェアと恐喝を使用して被害者から身代金を奪うハッカー集団である犯罪者グループDarkSideからのランサムウェア攻撃を受け、アメリカ東海岸の燃料供給の約半分となる45%を担う民間企業コロニアル・パイプライン社は、1週間にわたって操業停止に追い込まれました。

　このようなサーバー攻撃やランサムウェアによる攻撃を受け、社会インフラに重大な影響を与える事案が発生しています。このような状況を踏まえ、2021年5月に米国バイデン大統領は、国家のサイバーセキュリティの改善に関する広範な大統領令（E.O.）(*1)に署名しました。この大統領令に記述されている項目は下記の6項目になります。

脅威情報の共有を阻む障害を取り除く
連邦政府のサイバーセキュリティの近代化
ソフトウェアのサプライチェーンセキュリティの強化
政府が運営するサイバー安全審査委員会の設立
サイバーセキュリティの脆弱性やインシデントに対する政府の対応の標準化
政府のネットワークにおける脆弱性と問題の検出の強化
調査および修復能力の向上

　この中で注目するべき項目は、「ソフトウェアのサプライチェーンセキュリティの強化」です。もう少し詳しく紹介すると『各製品のソフトウェア部品表(SBOM(Software Bill of Materials))を購入者に直接または公開ウェブサイトで提供すること』を要求しており、『製品の一部に使用されているオープンソースソフトウェアの完全性と出所を、実行可能な範囲で確保し、証明すること。』が必要という記述があります。これによると、少なくとも米国連邦政府や連携する民間業者は、必ずSBOMを作成し、提供する必要があるということになります。

　では、SBOMというのは、どのようなものなのでしょうか？

　SBOMは、ソフトウェアの構築に使用される様々なコンポーネントの詳細およびサプライチェーンの関係を含む正式な記録のことです。ソフトウェア開発者およびベンダーは、オープンソースや商用ソフトウェアコンポーネントを組み合わせて製品を作成することが一般的で、 SBOMは製品に含まれるこれらのコンポーネントを列挙したものになります。これは、食品のパッケージに記載されている成分表に似ています。

　SBOMは、ソフトウェアのサプライチェーンに関わるさまざまな立場の人にとって有用なものになります。システムを構築する人は、使用するコンポーネントが最新であることを確認することで、新たな脆弱性に迅速に対応することができます。また、ソフトウェアの購入者は、SBOMを使用して脆弱性分析やライセンス分析を行うことができます。これらはいずれも製品のリスクを評価するために使用することができます。また、ソフトウェアを運用する人は、SBOMを使って、新たに発見された脆弱性の潜在的なリスクにさらされているかどうかを迅速かつ容易に判断することができます。

　SBOMは、他のアプリケーションやシステムから簡単に照会できるリポジトリにまとめて保存することで、より大きな価値を得ることができます。ソフトウェアのサプライチェーンを理解し、SBOMを取得し、既知の脆弱性を分析するためにSBOMを使用することは、リスク管理において非常に重要なことだと言えます。

昨年4月に米国NTIA（National Telecommunications and Information Administration）が公開したSBOMに最低限必要な要件(*2)を発表しましたが、この要件を満たすSBOMとして、代表的なものは下記の3つになります。

データ形式	仕様	ツール
SPDX	https://spdx.github.io/spdx-spec/	https://tiny.cc/SPDX
CycloneDX	https://cyclonedx.org	https://tiny.cc/CycloneDX
SWID	ISO/IEC 19770-2:2015	https://tiny.cc/SWID

この中から、SPDXについて、少しご紹介したいと思います。

SPDX (Software Package Data Exchange)

SPDXは、オープンソースソフトウェアコンポーネント、ライセンス、既知のセキュリティ脆弱性など、SBOM情報を伝えるためのファイル形式の仕様で、Linux Foundationの後援のもと、主要なSoftware Composition Analysis (SCA) ベンダーを含む数百の企業と協力することにより、過去10年間有機的に進化し、市場で最も堅牢で成熟したSBOM標準として採用されています。2021年9月にISO/IEC 5962:2021(*3)として認定され、国際標準となりました。

　2022年5月にLinux Foundationが調査レポート「The State of Software Bill of Materials and Cybersecurity Readiness」の日本語版「SBOM（ソフトウェア部品表）とサイバーセキュリティへの対応状況」(*3)を公開しましたので、ご紹介したいと思います。なお、このレポートでは、SBOMの準備状況に応じて、回答者は「SBOM慎重派」「SMONアーリーアダプター」「SBOMイノベーター」の3つに自己選択した結果で分類して報告しています。

SBOM調査結果

　今回の調査では、90% の組織が何らかの形でSBOMとの関りを持っていることがわかりました。10%の組織はSBOMのための計画を開始しておらず，14%は計画または開発段階にあり，52%は事業のいくつかのまたは多くの領域でSBOMに取り組んでおり，23%は事業のほぼすべての領域でSBOMに取り組んでいるか，SBOMの使用を含む標準的なプロセスを制定しています。つまり、全体として75%の組織がSBOMへの具体的な準備態勢を整えていることになります。

　SBOMの作成は、商用ソフトウェアを開発する組織で行われることが最も多いですが、今回の調査では、SBOMがはるかに広く採用されていることがわかりました。今回の調査に協力したすべての組織で、SBOMを作成する計画がないのはたった7%だけで、40%は半年から2年以内にSBOMを作成する計画があり、27%はいくつか、いくつか、または多くの事業分野でSBOMを作成しており、21%はほぼすべての事業分野でSBOMを作成しているか、SBOMの使用を含む標準的な習慣を持っています。全体として、およそ半数の組織が今日ある程度のSBOMを作成しているということになります。

　では、メリットについてどのように考えているのでしょうか？
SBOMを作成することのメリットとして51% の組織が、SBOM によって開発者がより広範で複雑なプロジェクト間の依存関係を容易に理解できるようになると回答しています。また、マイクロサービスアプリケーションに多くのコンポーネントがある現在では、各コンポーネントはある程度の数の依存関係を持っています。SBOMは、その依存関係を明示的に特定することができるため、アプリケーションの複雑さとコンポーネントの数が増えるにつれて、その有用性が増していくと考えられます。他にも、コンポーネントの脆弱性を監視しやすくなる (49%)、ライセンスのコンプライアンスを管理しやすくなる (44%)というようなメリットも挙げられています。さまざまなメリットが考えられます。

　とはいえ、SBOMの将来は、必ずしも明るくはないようです。
そもそもSBOMを業界として義務付けることになっているのかという声もあり、また、SBOMに何を含めるべきかについて業界のコンセンサスがあるかどうかということも課題として挙げられています。NTIAは、ガイダンスを提供していますが、この文書はSBOMに何を含めるべきかを定義するのに有用ですが、データフォーマット、実装、プロセスに関する議論は、ベンダーや業界団体の手に委ねられています。SBOMドメイン全体での進展は加速していますが、主要なITベンダーや組織による明確な可視性とメッセージングの欠如が、これらすべての懸念事項の根底にあります。また、ベンダーがSBOMを顧客に提供することについての価値が不明確であるという声もあります。また、SBOMを自動で作成するツールの可能性についても懸念があり、これは開発プロセスとして検討する必要もあります。

　SBOM活動を改善するための最も差し迫った課題は、SBOMの作成と使用をソフトウェア開発に統合するためのベストプラクティスに関する業界のコンセンサスの必要性です。SBOMの作成と使用はDevOpsプロセスの中で行われます。そこでの課題は、すべての組織が独自のDevOpsツールチェーン、プロセス、アクティビティを持っていることです。また、SBOMの作成や使用がDevOpsのどのプロセスで行われるべきなのかについても、まだまだコンセンサスが得られていません。SBOMの作成は明らかに開発指向のアクティビティですが、SBOMの使用はDevまたはOpsのいずれかで発生します。SBOMをどこで作成または使用すべきかというこの混乱に加えて、SBOMをいつ作成または使用すべきかという問題もあります。SBOMの作成と使用のもう1つの側面は、既知の依存関係と脆弱性が常に変化しており、SBOMが作成され使用された場所と時期に影響を与えるということです。

　次の課題はSBOMの作成と使用をGRC（ガバナンス、リスク、コンプライアンス）プロセスに統合するためのベストプラクティスに関するコンセンサスが必要になります。OSPO（オープンソースプログラムオフィス）および/またはCISO（最高情報セキュリティ責任者）を持つ組織は、このニーズに対処するのに十分な立場にあります。しかし、この2021年のSBOM準備調査では、全体として約20%の組織がOSPOまたはCISOを持っていないことが示されました。これらの数字は、SBOMイノベーターとアーリーアダプターでは約10%にまで減少しましたが、SBOM慎重派では35%から40%に増加します。

　SBOM作成／使用にたいして非常に伸びが期待されているわけですが、これを実現するのツールを整備も今後の大きな課題となるでしょう。有償/無償に関わらずこのようなツールが整備されていくことで、さまざまな課題が克服されていくことを期待したいと思います。

※本文中記載の会社名、商品名、ロゴは各社の商標、または登録商標です。

(*1) Executive Order on Improving the Nation’s Cybersecurity
https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
(*2) https://www.ntia.gov/files/ntia/publications/sbom_at_a_glance_apr2021.pdf
(*3) https://www.linuxfoundation.jp/wp-content/uploads/2022/05/LFResearch_SBOM_Report-ja.pdf

著者：
吉田行男
2000年ごろからメーカー系SIerにて、Linux／OSSのビジネス推進、技術検証、OSS全般の活用を目指したビジネスの立ち上げに従事。社内外でOSS活用に関する講演、執筆活動を行ってきた。2019年から独立し、さまざまな会社や団体の顧問として活動。OSSの活用やコンプライアンス管理などを支援している。