講演者：Oscar Valenzuela氏, Amazon, Principal Open Source Engineer

最初はこの世で一番OSSを使い倒して利益を得てる団体のひとつであろうAmazonのOscar氏より、SBOMを扱ううえでの「落とし穴」についての発表です。今存在する実際のSBOMは品質の高さや情報の正確性にも欠けていて、その結果はほとんどの場合使われているSCAツールの仕様によって制約されてしまうため、理想だけ求めず"Verify"、検証することが必要だと述べられていました。ほかにも“It's unrealistic”、”The List of ingredients is not a recipe”のように「それは幻想」といった趣旨のフレーズが多く、以前書いた記事と近いことは自分に限らず皆考えてるんだろう思いながら聞いてしまいました。

内容にはおおむね同意できたのですが、一点気になったのはこの検証を誰が行うかです。昨今シフトレフトやら何やらで開発者が関与する工程や役割は広がる一方ですが、この作業も開発者の役割になったら開発にかけられる時間がまた更に減ってしまうことになります。そうなるとほかに誰がという話になりますが、どんな人にせよ開発者以外が担当するにはこの検証に必要な素養をどこまで少なく押さえられるかという問題も浮上してきます。

こういった運用面も含め、SBOMはまだまだ模索が必要な領域であると感じます。

講演者：Armijn Hemel氏, Tjaldur Software Governance Solutions

ソースコードからよりもソフトウェアをビルドする際、ビルドトレーシングから得られる情報でより正確なSBOMを作成できる、という内容です。開発者にとってソースコードから構成情報を読み取るのは当たり前なのですが、ソースコードに含まれない"どのソフトウェアがどのバイナリに含まれているか"というのは割と見落としがちな情報です。昨今SBOMは脆弱性対策の視点で語られることが多いのですが、ライセンスコンプライアンスの視点からもこの情報はかなり大事な情報ですので、ツールを使ってSBOMを自動作成しようとされる方はこのビルド時の情報をSBOMに含められるかという観点も気にされるとよいかと思います。

また、発表で言及されていた“Possible view”、ソフトウェアを"Source code"、"Build Time"、"Run time"の3つの視点で捉える見方はこれまで意識してこなかったので、SBOMを扱う開発者として色んな気付きを貰うことができて非常に有意義な時間となりました。

講演者：見次正樹氏 経済産業省 商務情報政策局 参事官

経産省がその中でSBOMをどこに位置付けているかそしてその取り組みについての紹介でした。SBOMの義務化、要件化の波は世界的な潮流になっているので、そういった状況も踏まえつつなされているとのことです（直近ではソフトウェア管理に向けたSBOMの導入に関する手引ver2.0が出ています）。

経産省の活動や成果は日本全体に影響を及ぼす以上「政府の見解」みたいなものをどうしても聞きたくなってしまうのですが、今回も例にもれずその質問が出ていました。

回答としてはおおよそ「セキュリティ向上のためにSBOM作成を義務化することになった場合、義務化するにあたってその対象範囲を厳密に規定することになるがその範囲は狭めざるを得ないが、規定することでそれ以上はかけようとしなくなるというセキュリティ向上という目的に対しマイナスの効果が出てしまう懸念がある。それを踏まえて、今はあえて義務にせず啓蒙する状態を維持している」とのことでした。

法や規制の整備が大変だから省エネルギーで済ますための言い訳だろうと感じる方もいらっしゃるかもしれませんが、個人的には十分納得のいく回答です。ソフトウェア脆弱性の情報収集だったり対応のプラクティスが模索中なのは事実ですし、そんな中での義務化は早すぎる最適化だった...と後になって皆が後悔する可能性はまだまだ十分に残されています。

講演者：渡邊歩氏 日立ソリューションズ シニアOSSスペシャリスト

社内では昇進し、社外ではLinux Foundationのエバンジェリストとしての活動も開始した元上司の渡邊さんからの発表です。ここ数年SBOMの流れを踏まえつつ、自身が所属するコミュニティであるOpenChainプロジェクトの概要と活動内容を紹介しています。

今年インドや韓国、中国でもSBOMガイドラインが出たそうで、世界は着々とSBOMを使う方向に進んでいるようです。

講演者：小保田規生氏 ソニーグループ シニアOSSストラテジスト

SPDX Specificationの翻訳、SPDX Liteの策定を行っているOpenChain Project JWGのSBOMサブグループの活動についての舞台裏、といった趣の内容です。Lite profileの定義にあたってLiteの価値観を再確認し、それを踏まえて3.0のオブジェクトモデルに基づき抽出。また、策定や翻訳を行うにあたっては認識合わせや要望の共有のために本家SPDX Projectのメンバーと対面して協同するなど、円滑に進める努力をしているそうです。数カ月前この記事を書くにあたってSPDX 3.0とLite Profileについての公開資料を色々拝見させて頂いたばかりだったので、大変興味深い内容でした。

余談ですが、SPDX 3.0については会場で「3.0はエクセルで書ける？」「エクセルはもう無理だろう...」みたいなやり取りも聞こえていました（ここのセッションではなかったかもしれませんが）。自分も完全に同意見です。jsonを解読するために特定のツールが必要になる訳ではありませんし、エクセル万能論から卒業するときだと捉えて割り切る方が今後のためになるでしょう（特定の層に届くことを祈りつつ）。

講演者：岡田良太郎氏 OWASP Japan

SPDXの話題が出てきたら何かと引き合いに出されるCycloneDXの策定団体、OWASPからの参戦？です。発表中に言及して散々ネタにしつつも「こうやって言いたいことをお互い言い合えるのがオープンのいいところ」とおっしゃっていましたが、これは自分含め会場の参加者全員が同意できたのではないかと思います。

自分含め多くの方が身につまされる内容だったと思うのですが、現実的な問題である物量への対応コストと問題解決に必要な知見を得るためのハードルは少数の情熱だけではどうにもならないだろうという諦観も同時にあり...この問題が緩和されるまでの道のりの長さを感じてしまいます。

最後に出てきた「"使う"力ばかり先行するのではなく"作る"側に立つべき」というフレーズには自分も色々思うところがあり、非常に考えさせられる発表でした。

（一応言及しておくと本イベントにはLF側から招待したそうなので、両者の関係は良好です）

講演者：池田宗広氏 サイバートラスト リードアーキテクト

OpenSSFにおけるサプライチェーンセキュリティの捉え方、関連する取り組みの解説です。特に理想的なサプライチェーンセキュリティの中でSBOMが果たす役割については午前中のArmijn氏が言及していた"Possible view"と異なる視点で触れられており、合わせてみることでSBOMをより多角的に捉えられる内容でした。

最後にOpenSSFの立場からOSSは公共財であり、そこで「共有地の悲劇」が起こらないよう活動とその意義について言及していました。ただ、マクロで見たら「悲劇」が起こるのはそのとおりなのですが、ミクロというか個人あるいは企業視点で見ると共有物を使うだけに徹することがコスト的な最適解になってしまうのもまた事実です。これについては貢献することが個人や企業視点でも最適解になり得る何かが必要だろうと個人的に思っています。

講演者：桑田昌行氏 ソニーグループ 統括課長

直前登壇された池田氏の意見とは異なり、OSSはビジネスとして必要とされていると考える立場からオープンソースの活動であるOSPOは実際にビジネスとしての価値を生んでいるという内容です。 所属されているソニーグループは昔から組み込み機器にOSSを活用するとともにコミュニティに貢献してきたという実績も含め、説得力があったのではないかと思います。 オープンソースコミュニティにおいて、OSS活動をするために理解を得るハードルが高いというトピックはいつも大きな関心を寄せられています。こういった話が広まってくると状況も変わっていくのではないでしょうか。

「共有地の悲劇」もそうですが搾取を前提とする構造がどこかにあるとその対象が枯渇した時点で破綻しますから、それをどうやって実現・維持するのかオープンソースという文化、形態が残るかどうかの分かれ目なのだろうと思う次第です。

講演者：

• 遠藤雅人氏 トヨタ自動車 グループ長

• 日下部 雄一氏 ホンダ技研工業 リードアーキテクト

• 伊藤義行氏 ルネサスエレクトロニクス プリンシパルスペシャリスト

OpenChainコミュニティの中でも存在感の強いAutomotive WGからの合同発表です。遠藤氏は自動車業界におけるOSPOの取り組みについて、日下部氏は自動車業界で使われるAOSP（Android Open Source Project）とAGL（Automotive Grade Linux）のSBOMについて、伊藤氏は業界の現状について言及していました。

特に最後、伊藤氏がSBOMに対する要求が顧客ごとにバラバラで個別対応が必要になってしまう現状を踏まえつつも、脆弱性への対応を含めSBOMという領域は今まさに議論中でありその正解や在り様は誰もわからないフェーズにあって、表層的な成果物である仕様を見たりツールを使うだけでなく自らコミュニティに参画し問題を提起することの重要性を述べられていたときは色んな光景を思い浮かべてしまいました。"正しさ"ばかり聞いてくる人にこそ、聞いてほしいものです...

すべてのセッション終わった後はそのまま閉会宣言となり、イベントが終了しました。

総括、と言えるかはわかりませんが、一通り発表を聞いたうえで振り返るとSBOMは開発者のようにソフトウェアそのものに近い人ではなく、遠い人のためにあるべきなのではないかという思い付きがありました。Oscar氏も言及していましたが、結局の所ソフトウェアについてより多くの情報を得たいと思ったらソースコードや実行環境をあたった方が確実なわけで、SBOMはその一側面しか保持することができません。つまり、SBOMがあろうとなかろうと、構成情報の真贋や脆弱性への対応要否といった最終的な判断を下すのはソースコードや実行環境を理解できる開発者の役割であることは今後も変わらない可能性が高いです。この前提で考えると、SBOMの内容が開発者にしか理解できないのであればSBOMは開発者向けの情報・ツールの一つという位置づけにしかならず、今コミュニティで試行錯誤されているようなサプライチェーン上で交換する情報フォーマットとして普及するのは想像しづらいように思えます。したがって、SBOMという存在が広範囲に何かの役割を果たすためには"開発者以外でも"理解できる範囲の情報を持ち、そこから何かが判断できるというのが必要条件の1つかもしれません。 ただし、開発者以外でもとは言いつつソフトウェアのことをまったく知らないままその構成情報を評価なんてできませんから、ある程度は知っておく必要はあります。この"ある程度"に共通見解ができて、SBOMはようやくその存在を確立できる気がします。

そんなことを考えながら帰路についた筆者でした。