CNSC 2022、SBoMの概要と未来を展望するセッションを紹介
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つの文脈でサプライチェーンセキュリティが語られていると説明。ここでは後半のソフトウェアが依存するモジュールなどに対する攻撃への対策という観点について解説を行うと語った。
ソフトウェアが開発され実装されるまでの流れの中で、このセッションではデベロッパーが書いたソースコードがビルドされる際に組み込まれるオープンソースライブラリーが脆弱性などを含んでしまう可能性があるという部分に関して詳しく解説を行った。
「OSSに対する攻撃」と題されたスライドでは、自社で開発を進めるソフトウェアに多数のオープンソースソフトウェアが含まれる場合があることは理解した上で、100%その中身を認識することは難しいと説明。特にライブラリーが直接依存関係にある場合はまだしも、推移的依存と称する親子関係の末端にあるライブラリーに脆弱性が発見された場合は、それを自社のソフトウェアの中に発見するのは困難であると説明した。
そしてSBoMがその成分表として利用できると語り、現在では、CycloneDX、SPDXなどが存在していると紹介した。GitHub SBoMも紹介されているが、CycloneDXとSPDXがほぼデファクトスタンダードであると説明。これまで個々のパッケージマネージャーや言語別のパッケージ仕様が存在していたが、共通のフォーマットとしての成分表がなかったとして、それを担うのがSBoMであると説明。
またSBoMを使う理由としてソフトウェアの構成内容を確認するだけではなく、SBoMからその中に脆弱性がないかどうかを確認するための入力フォーマットとしても使えることを紹介。またアプリケーションなどに含まれるライブラリーなどのライセンス管理としても使えると説明した。
上のスクリーンショットは筆者が使っているWindows 11 PCで稼働するMicrosoft Teamsの設定から、表示可能なサードパーティソフトウェアに関するライセンスの一部だ。ここでは絵文字に関するソフトウェアのライセンスが書かれているが、実際にはFacebookが作ったライブラリーなど膨大なライブラリーに関する情報が詰め込まれている。各ライブラリーが持つライセンスについて個々のライセンス表記をすべてテキストで格納しており、人間が眼で確認するには無理があるほどのサイズとなっている。これが機械可読性の高いJSONの形でフォーマットされたSBoMなら、データベース化による検索などの機能が実装できる可能性が高くなるのは容易に想像できる。
ここからはデモとして、Trivyを使ってコンテナイメージのSBoM生成、SBoMを用いて脆弱性が含まれるかどうかのチェックなどを行った。
CycloneDXのコントリビュータという立場からリアルな感想として語られたのが、「SBoMとして利用されているComponentの種類が多くどう使い分けて良いのかわからない」というコメントだった。この辺りは、ソフトウェア開発の中でも用語の厳密な定義に当たる部分となり、コミュニティの中でもまだ十分に浸透しているわけではないことがわかる。
そしてこれからはSBoMが共通フォーマットとして利用が拡がって欲しいと解説。
しかし現実問題としてまだまだ問題点も多いとして、ここから問題点を4つ挙げて説明を行った。40分のセッションのうち、藤村氏が本当に語りたかったのはここからの10分だったのだろうと思わせる内容となっている。
最初の問題は、makeなどでビルドされたイメージについては中身を確認することができないという問題だ。このためコンテナの中にそのようなイメージが入っていた場合、正確なSBoMを作ることができないと説明。
次の問題は、標準フォーマットでありながらも、互換性が保証されているわけではないという問題だ。
3つ目の問題は依存関係を表現するSBoMであっても、依存関係の種類が多く複雑で、すべてを表現できないという問題だ。
また脆弱性検知という目的についても、パッケージの持つ情報を表現するためにツール独自のプロパティを拡張しながら実施しているとして、ここでも互換性が損なわれている問題を提起した。
ただ今後も仕様が拡張され、エコシステムとしても拡大していくと予想されるので、ツールを作ろうとしているエンジニアにはチャンスが拡がっていると説明し、SBoMに関わるソフトウェア開発を促した。
そして最後の5分を使って、今後の展開として、Software Attestationについて簡単に説明した。
ここでは単にどういうライブラリーから構成されているのか? を明らかにするSBoMではなく「誰が、何を、どのように作成」したのかを明らかにするSoftware Attestationについて解説。
その上でSBoMだけではなくSoftware Attestationのメタデータが一元管理される仕組みが開発されつつあるとして、コンテナレジストリに実装される動きがあると説明。これがあるべき姿ということだろう。
SBoMについてはアメリカの大統領令として発令されるなど、米国政府機関においては必須の情報として認識されつつあり、日本も追従していくだろう。ソフトウェアを開発するデベロッパーも、システムを運用維持するオペレーターも、どちらの立場でも無視することができない流れであり、退屈だが重要な仕事になる。しかしまだ道は険しいことが垣間見られるセッションとなった。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- 米国のバイデン大統領が署名したことで話題となった「国家のサイバーセキュリティ改善に関する大統領令」とは
- OpenSSFを拡大・支援するため1,000万ドルの新規投資を調達、「The 2021 Open Source Jobs Report」を公開、ほか
- KubeCon NA 2021、ソフトウェア開発工程のタンパリングを防ぐSLSAを解説
- Open Source Summit Japan 2023から、組込系システムにおけるサプライチェーンに関するセッションを紹介
- KubeCon Europe 2024にて、グラフを用いてSBOMを可視化するGUACのコントリビューターにインタビュー
- LFとOpenSSF、OSSのセキュリティを向上させる具体的な計画を日本で発表
- KuberCon/CloudNativeCon NA 2021開催、3日間のキーノートを紹介
- KuberCon NA 2021、Kubernetesリリースチームが解説するSBOMのセッションを紹介
- 「Open Source Forum 2019」開催 ― CI/CDの標準化やプロダクションAIのためのエコシステムなど解説
- LFがSBOMの導入によるライセンス順守とソフトウェアセキュリティ強化に関するレポートを発表、ほか