CloudNative Security Conference 2022から、OWASPのコントリビュータが解説するSBoM（Software Bill of Materials）に関するセッションを紹介する。タイトルは「SBOMを利用したソフトウェアサプライチェーンの保護」で、プレゼンテーションを行ったのはOWASPのコントリビュータである藤田匡弘氏だ。
プレゼンテーションを行う藤田氏
ちなみにOWASPとはOpen Web Application Security Projectの略で、Webをはじめとするソフトウェアに関わるセキュリティの啓蒙などを行っているコミュニティで、活動のベースとなっているThe OWASP Foundationはアメリカの非営利団体であり、藤田氏もボランティアとして関わっていると言う。
OWASP日本語ページ：OWASP Japan
セッションは前半がSBoMの概要、途中でデモを挟んでSBoMの生成と利用を解説した後に、現在の問題点、そして未来に向けた展望を解説するという内容となっている。
サプライチェーンセキュリティとは？
アメリカが主導する形でソフトウェアにおけるサプライチェーンに対するセキュリティに関心が高まっており、日本でも徐々に注目が集まっていると語った。その中で特に2つの文脈でサプライチェーンセキュリティが語られていると説明。ここでは後半のソフトウェアが依存するモジュールなどに対する攻撃への対策という観点について解説を行うと語った。
ソフトウェアサプライチェーンには多くのポイントがあると指摘
ソフトウェアが開発され実装されるまでの流れの中で、このセッションではデベロッパーが書いたソースコードがビルドされる際に組み込まれるオープンソースライブラリーが脆弱性などを含んでしまう可能性があるという部分に関して詳しく解説を行った。
開発するソフトウェアに何が含まれるのかを100％理解するのは難しい
「OSSに対する攻撃」と題されたスライドでは、自社で開発を進めるソフトウェアに多数のオープンソースソフトウェアが含まれる場合があることは理解した上で、100％その中身を認識することは難しいと説明。特にライブラリーが直接依存関係にある場合はまだしも、推移的依存と称する親子関係の末端にあるライブラリーに脆弱性が発見された場合は、それを自社のソフトウェアの中に発見するのは困難であると説明した。
SBoMでオープンソースソフトウェアの構成成分を確認することができる
そしてSBoMがその成分表として利用できると語り、現在では、CycloneDX、SPDXなどが存在していると紹介した。GitHub SBoMも紹介されているが、CycloneDXとSPDXがほぼデファクトスタンダードであると説明。これまで個々のパッケージマネージャーや言語別のパッケージ仕様が存在していたが、共通のフォーマットとしての成分表がなかったとして、それを担うのがSBoMであると説明。
SBoMを使う理由とは
またSBoMを使う理由としてソフトウェアの構成内容を確認するだけではなく、SBoMからその中に脆弱性がないかどうかを確認するための入力フォーマットとしても使えることを紹介。またアプリケーションなどに含まれるライブラリーなどのライセンス管理としても使えると説明した。
Microsoft Teamsのサードパーティソフトウェアライセンスの一部
上のスクリーンショットは筆者が使っているWindows 11 PCで稼働するMicrosoft Teamsの設定から、表示可能なサードパーティソフトウェアに関するライセンスの一部だ。ここでは絵文字に関するソフトウェアのライセンスが書かれているが、実際にはFacebookが作ったライブラリーなど膨大なライブラリーに関する情報が詰め込まれている。各ライブラリーが持つライセンスについて個々のライセンス表記をすべてテキストで格納しており、人間が眼で確認するには無理があるほどのサイズとなっている。これが機械可読性の高いJSONの形でフォーマットされたSBoMなら、データベース化による検索などの機能が実装できる可能性が高くなるのは容易に想像できる。
ここからはデモとして、Trivyを使ってコンテナイメージのSBoM生成、SBoMを用いて脆弱性が含まれるかどうかのチェックなどを行った。
デモはコンテナイメージの脆弱性スキャン
CycloneDXのコントリビュータという立場からリアルな感想として語られたのが、「SBoMとして利用されているComponentの種類が多くどう使い分けて良いのかわからない」というコメントだった。この辺りは、ソフトウェア開発の中でも用語の厳密な定義に当たる部分となり、コミュニティの中でもまだ十分に浸透しているわけではないことがわかる。
CycloneDXの「Componentの定義がよくわからない」とコメント
そしてこれからはSBoMが共通フォーマットとして利用が拡がって欲しいと解説。
エコシステムの中で共通フォーマットとして拡大？
しかし現実問題としてまだまだ問題点も多いとして、ここから問題点を4つ挙げて説明を行った。40分のセッションのうち、藤田氏が本当に語りたかったのはここからの10分だったのだろうと思わせる内容となっている。
問題1、すべての依存関係を可視化できない
最初の問題は、makeなどでビルドされたイメージについては中身を確認することができないという問題だ。このためコンテナの中にそのようなイメージが入っていた場合、正確なSBoMを作ることができないと説明。
問題2、標準フォーマットだが互換性がない部分もある
次の問題は、標準フォーマットでありながらも、互換性が保証されているわけではないという問題だ。
問題3、依存関係の種類が多過ぎる問題
3つ目の問題は依存関係を表現するSBoMであっても、依存関係の種類が多く複雑で、すべてを表現できないという問題だ。
問題4、脆弱性を検知するためには仕様が十分ではない
また脆弱性検知という目的についても、パッケージの持つ情報を表現するためにツール独自のプロパティを拡張しながら実施しているとして、ここでも互換性が損なわれている問題を提起した。
ただ今後も仕様が拡張され、エコシステムとしても拡大していくと予想されるので、ツールを作ろうとしているエンジニアにはチャンスが拡がっていると説明し、SBoMに関わるソフトウェア開発を促した。
ここまでのまとめ
そして最後の5分を使って、今後の展開として、Software Attestationについて簡単に説明した。
SBoMの未来の話を最後に
ここでは単にどういうライブラリーから構成されているのか？ を明らかにするSBoMではなく「誰が、何を、どのように作成」したのかを明らかにするSoftware Attestationについて解説。
Digital Identityの一部としてのSoftware Attestationを説明
その上でSBoMだけではなくSoftware Attestationのメタデータが一元管理される仕組みが開発されつつあるとして、コンテナレジストリに実装される動きがあると説明。これがあるべき姿ということだろう。
SBoMについてはアメリカの大統領令として発令されるなど、米国政府機関においては必須の情報として認識されつつあり、日本も追従していくだろう。ソフトウェアを開発するデベロッパーも、システムを運用維持するオペレーターも、どちらの立場でも無視することができない流れであり、退屈だが重要な仕事になる。しかしまだ道は険しいことが垣間見られるセッションとなった。