オープンソース SBOM(Software Bill of Materials)の必要性と活用方法

 

1. 世界中で使われる OSS

NASA が最近火星でヘリコプターを飛ばしたこと1を覚えていますか。
あのヘリコプターは OSS で制御されているんですよ。この文章を読もうとする方で OSS という言葉を知らない人はいないような気がしますが、念のために言っておくと、OSS とは Open Source Software(オープンソースソフトウェア)の略で、おおざっぱに言うと「ソースコードが公開されており、誰でも改善提案ができるソフトウェア」のことです。だから火星のヘリコプターのソースコードも公開されていて、皆さんも改善提案できるのです2。そんな火星の話なんか知らないよ、という皆さん、「東京都新型コロナウイルス感染症対策サイト」3なら聞いたことがあるのではないでしょうか。あれも OSS なのです4。ですから、台湾の有名なオードリー・タンさんから改善提案が来た5ことが話題になりましたよね。
そんな地球外のことなんて知らないし、コロナのサイトも見ないなぁという皆さんでも OSS とは無縁ではありません。皆さん、スマホは持っていますよね。Android スマホは基本的な部分からして OSS でできています6。OSSの固まりと言っても良いですね。「いや、私は iPhone だから」と思ってしまった方、残念でした。iPhone も OSS とは無縁ではありません。iPhone で「法律に基づく情報」というのを表示させることができますが、そこに書いてあるほとんどの情報が iPhone に内蔵されている OSS に関するものなのです。「いやいや、持つならやっぱりガラケーだよね」とか言っちゃった皆さん、頑張ってください。(ただし、今でもまだ動いているような比較的新しいガラケーなら、OSS と無縁というわけにはいかないと思います。)
それに東京証券取引所は超有名な OSS、Linux で動いています7。それどころか、私の記憶が正しければ世界の主要証券取引所はすべて Linux で動いているはずです。株をやっている皆さんは間接的な形ではありますが OSS にお世話になっているんですね。「スマホで株取引」なんてしたら、もう OSS にお世話になりっぱなしです。

 

2. 自分はOSSを使っている︖

そのように身近なところから、はては火星でまで使われている OSS ですが、皆さんは自分が作っているものにOSS が使われているかどうかは把握していますか。今となってはそんなことはないと信じたいですが、一昔前は今聞くとびっくりするような例がちらほらありました。
以下に挙げる例は、残念ながら実際に当時私が見聞きしたものです

 

ダメな例その1

---------------------------------------

「オープン、すなわちインターネットで公開されているんだから、コピペして好き勝手に使っていいんだろ」と何も考えずに自分の製品に組み込んだ。(さすがに私がやってしまった訳ではありませんので、そう推測されるということです。)
ここであえて言う必要もないですが、「使ってよい」と言っても「ライセンスを守って」という条件付きですよね。当時は、OSS のコピペを検出するツールが今ほど普及・充実していなかったはずですが、それでも発覚して(分かる人が見れば分かるんですよ︕)大騒ぎになりました。今は検出ツールも充実してその能力も上がってますから、そんなことをしたら確実にすぐ発覚するでしょうね。まあ、今でも会社でこんなことをやっているとしたら、さすがに論外でしょうか。

ダメな例その2

---------------------------------------

「OSS にはライセンスというものがあるのは知っている。だが、その内容がよく分からないから使わないようにしよう」と
していたのに、、、、
あるところに、会社の方針として「OSS は使わない」という会社がありました。なので、自社内で OSS が勝手に使われるということはなかったのですが、結局、製品に OSS が混入しそうになったという事例が発生しました。勘の良い方はお気づきでしょうが、その当時から製品に組み込むソフトウェアをすべて自社内でまかなえている会社なんてほとんどなかったのです。部分部分に分けて下請けに出していたのですが、その下請けの一つが納品してきたものに OSS が入っていました。
なので、自社内だけきちんと管理していても(もしくは、管理したつもりになっていても)、それだけではダメなのです。(まあ、「OSS は使わない」というのは「管理」と言えば「管理」でしょうが、今でもそんなことを言っていたらソフトウェアが作れなくなっているでしょうね。)

 

3. 管理が必要

ダメな例の 1 から分かるように、ライセンスを守るためにはそもそも自分たちがどんな OSS を使っているのか把握して管理しないといけません。自分たちが自分たちのものを管理するだけであれば、どんな形で管理しても問題はないでしょう。ですが、ダメな例の 2 から分かるように、ここで言う「自分たち」は自社内だけでなく下請けも含めた広い意味での「自分たち」です。ですから、みんなが使える共通の形式があるとみんなが幸せになれそうですよね。そのためのものが、オープンソース SBOM です。が、「オープンソース」は分かるとしても、SBOM といきなり言われても分からない人が多いのではないでしょうか。

ですので、ここで少々説明を

メーカーの方は自社製品の製造を管理するために部品表を使ったり作ったりしているのではないでしょうか。部品表は英語で bill of material と言って BOM と略されます。(すみません、この辺はもしかして皆さんにとっては釈迦に説法でしたでしょうか。)そのソフトウェア版ということでソフトウェア BOM、略して SBOM です。アメリカ大統領が大統領令の中で SBOM に言及している8くらいですので、今ここで覚えておいて損はないでしょう。

SBOM の形式で名前がそれなりに知られているものは以下の 3 つと言ってよいと思います。
• SWID
• SPDX
• CycloneDX

SWID は ISO/IEC 規格9ですし、 SPDX は ISO/IEC 規格のドラフト10(執筆時点では)、CycloneDX はOWASP 由来11とそれぞれ由緒正しかったり国際的なものだったりしますから、海外と取引している会社の皆さんにとっても、この形式に従っていれば安心ですね。
SBOM のうち取り扱うソフトウェアを OSS に限定したものをオープンソース SBOM とここでは呼ぶことにします。
オープンソース SBOM を SPDX の形式で出力する OSS チェックツールも多いですよ。
「うんうん、うちの会社では(オープンソース)SBOM を納品してもらっているし、社内でもツールを使って(オープンソース)SBOM で管理しているよ」という方、そのまま頑張ってください。それがベストプラクティスだと思いますので。
「えっ、SBOM という言葉もオープンソース SBOM という言葉も今日初めて聞いた」という方、安心してください。おそらく皆さんの方が圧倒的多数派です。でも、ソフトウェアの部品表だ、ということをここで知りましたから、もう怖くないですよね。今「よし、それではどのツールを導入しようか」とか「SBOM のどの形式を採用すれば良いだろうか」とか思った皆さん、皆さんの心意気は高く評価しますが、ちょっと落ち着きましょう。ツールの出力する SBOM は何百行にもなる場合があります。また、SBOM の仕様書そのものが百ページを超えていたりします。こんなものをいきなり見たら、いくら頑張り屋の皆さんでもくじけてしまうのではないでしょうか。

 

4. まずはオープンソース SBOM を作ってみよう

利用する OSS の数が多くなっていけば、いずれはツールを使ってオープンソース SBOM 取り扱うことになるでしょう。ただし、オープンソース SBOM を今まで全く意識していなかったということは、おそらく利用している OSS がまだそれほど多くないということなのではないでしょうか。であるなら、今のうちに自分の手でオープンソース SBOM を書いてみるというのはいかがでしょう。(え︖「我が社は利用している OSS は多数あるけど、オープンソース SBOM なんて作ってないんだよね」ですって︖それはオープンソース SBOM という名前ではないけれど、それに相当するものを作っているということだと思います。そうでないと「多数ある」なんて言い切れないですよね。)

「オープンソース SBOM を書いてみると言っても、一体どうやって始めれば良いのか」と思った方、そんな皆さんにぴったりのものがあります。SPDX Lite 形式でオープンソース SBOM を書いてみるというのはいかがでしょうか。SPDX Lite12とは、その名前から推測がつくように SPDX から重要な項目を抜き出して「軽く」したものです。ですので、SPDX Lite 形式であれば文字通り手でも書けます。

「SPDX Lite のような独自な形式で書くとベンダーロックインされるのでは」と不安になった方、安心してください。SPDX Lite は SPDX の仕様の付録で定義されている公式なものです13。また、将来ツールを使うことになって、SPDX Lite ではなく SPDX を使うことになったとしても SPDX Lite を作った経験は必ず活かせます。SPDX Liteから SPDX になって増えた項目だけ新しく勉強すれば良いのですから。もし SPDX ではなく、SWID やCycloneDX を使うことになったとしても、SPDX Lite での経験は活かせると思います。SPDX Lite の項目はSBOM の形式が変わっても必ず含まれるような基本的で重要な項目ですから。

 

5. オープンソース SBOM の活用事例

「SPDX Lite 形式なんてどこで使われているのだろう」と思った方、自社内で管理するために、SPDX Lite と類似した形式を用いてオープンソース SBOM を作成しているところは日本国内に複数社ありますよ。「お前はなぜそんなことまで知っている。もしかして産業スパイか」と思った方、いえいえ、私はスパイではありません。これは SPDX Liteという規格ができた経緯から必然的に導ける結論です。実は、SPDX Lite は日本発の規格なのです。日本の数社が自社内で使っているオープンソース SBOM(に相当するもの)を持ち寄って、その共通部分に手を加えることで規格を作り上げていったのです。ですので、SPDX Lite と類似した形式で管理している会社がすでに複数あるのです。
また、国内の自動車業界では、SPDX Lite そのものを自社内にとどまらず会社をまたいで使用している例があります。(というか、書類の形式がバラバラで扱うのに効率が悪いという業界内での課題を解決するために SPDXLite を作ったという側面もありそうです。)

 

6. まとめ

オープンソース SBOM という言葉を今回初めて聞いたという方も多かったかもしれません。今回はライセンス遵守の観点から、その重要性について述べました。セキュリティ関連のニュースがよく聞かれるようになった昨今、セキュリティの観点からもオープンソース SBOM の重要性は今後ますます高まって行くものと考えられます。(SBOM に言及している大統領令もセキュリティの文脈から出ています。)
ただ、いくら重要だからと言われても、今まで何もしてこなかった方がいきなりツールでオープンソース SBOM を作って取り扱うというのは難しいのではないかと思います。そのような場合には、まずは自分が作っているものに使われている OSS を手で書き出してみるというところから始めてみてはいかがでしょうか。その時には SPDX Lite 形式で書いてみるのがお勧めです。

 

1. https://mars.nasa.gov/technology/helicopter/
2. https://nasa.github.io/fprime/
3. https://stopcovid19.metro.tokyo.lg.jp
4. https://github.com/tokyo-metropolitan-gov/covid19/
5. https://github.com/tokyo-metropolitan-gov/covid19/pull/827/
6. https://android.googlesource.com/
7. https://pr.fujitsu.com/jp/news/2010/01/4.html 世界最高水準︕次世代株式売買システム
「arrowhead」を稼働
8. 英語に抵抗のない方は原文に当たってもらえば良いですが、英語はちょっとという方はジェトロのサイトにある
https://www.jetro.go.jp/biznews/2021/05/35e8aca1614f6fe5.html はいかがでしょうか。この
文でも SBOM という言葉はまだ一般的ではないと考えているのか、注の中でだけ SBOM と書いており、本文
中では「ソフトウエアの構成要素に関する詳細」と書いています。
9. ISO/IEC 19770-2
10. ISO/IEC DIS 5962
11. https://owasp.org/www-project-cyclonedx/
12. https://github.com/OpenChain-Project/OpenChain-JWG/blob/master/subgroups/licensing/outcomes/spdx-lite-overview-20190829.pdf
13. https://spdx.github.io/spdx-spec/appendix-VIII-SPDX-Lite/

 

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

 

Tips集のご案内

テクマトリックスでは、開発企業としてOSSと上手につきあうための「OSS活用Tips集 – シーズン2」を提供しています。「資料ダウンロードはこちら」から、ホワイトペーパーを一括でダウンロードできます。

  1.「OSS最新動向-コロナに負けないオープンソース」
  2.「オープンソースSBOMが必要な理由とは!」
  3.「ソフトウェアイノベーションはOSSから、コンテナ・AI技術がイノベーションを牽引」
  4.「OSSと上手に付き合う方法~攻めは最大の防御なり~」
  5.「OSSと上手に付き合う方法~サプライチェーンを安全に~」
  6.「ISO/IEC 5230で変わる?OSSコンプライアンス対策」
  7.「著作権トロールとは?」

企業向けSBOMガイドのご提供

「SBOMの導入によるライセンス コンプライアンスと ソフトウェア セキュリティの強化」 企業向けSBOMガイドの資料を提供しています。

SBOM導入ガイド