SBOMとはSoftware Bill Of Materialsの略で、ソフトウェア部品表のことです。製品に含まれるプロプライエタリやOSSのソフトウェアコンポーネントの名称や、バージョン、ライセンスなどを一覧できるものになります。
2021年5月に米国大統領令が出て以降、NISTでSP800-161やSP800-218などソフトウェア脆弱性管理に関わるガイダンスが制定され、その手法の一つにSBOMがあり注目を集めるようになりました。
SBOMは世界的な動き
米国では、先に述べたように連邦政府を中心にSBOM提供のガイダンスが制定され調達要件となっています。米国政府はもちろん、政府と取引のある企業へソフトウェア商品を提供する場合、SBOMを要求される可能性があります。
EUでは、2022年9月にCyber Resilience Act(CRA)が発表され、SBOM提供が要件の一つとなっています。CRAでは重要なデジタル商品のクラス分けがされていて、クラスによっては2024年9月以降欧州市場の欧州企業に商品提供する場合、SBOM提供と第三者認証や自己適合宣言が必要となってきます。
日本では、2019年9月より経済産業省を中心にタスクフォースが立ち上がり、2023年7月にソフトウェア管理に向けたSBOMの導入に関する手引 Ver1.0をリリースしています。まずは日本企業がSBOM提供可能な環境構築や体制整備を促す内容であって、まだ法的にSBOM提供を要求する段階ではありません。
また業種によっては、医療業界や自動車業界でSBOM対応が必要となる動きもあります。
SBOMの構成要素について
SBOMに入れる情報については、NTIAが定める最小要素がデファクトスタンダードとなっています。
必要な情報は以下の通りです。
- Supplier Name : サプライヤー名
- Component Name : コンポーネント名
- Version of the Component : コンポーネントバージョン
- Other Unique Identifiers : ID
- Dependency Relationship : 依存関係
- Author of SBOM Data : SBOM作者
- Timestamp : 日時
SBOMのフォーマットについて
SBOMは機械判別することが前提ですので、フォーマットがあらかじめ決まっています。一般的なものはSPDX、CycloneDX、SWIDタグというのがあります。
どのフォーマットも自動化前提でツールなどをつかって出力することになります。
SPDXについて
SPDXはLinux Foundation傘下のプロジェクトで2011年からある歴史あるフォーマットです。ISO/IEC 5962:2021で国際標準化されていますので、特別な理由がなければSPDXを採用すべきです。
SPDX2.2では日本が主導してSPDX Liteの仕様が定められています。これはExcelで閲覧編集可能ですので、運用上色々な利点がありお勧めです。SBOM運用が世間で広まるまでのこの5,6年はSPDX Liteで十分と思います。
CycloneDXについて
CycloneDXは2017年からあるOWASPのSBOMフォーマットになります。SPDXより少し新しいこともあって、機能が豊富です。でもそれが実際に運用していくと面倒というか、手間というか、必要ないというか、そんな感じになります。個人的にSPDXがお勧めです。
SWIDタグについて
SPDXとCycloneDXと比較しマイナーですが、SWIDタグもよく記事で取り上げられています。ISO/IEC 19770で定められていて国際標準なんですが、NTIAとうまく対応していないこともあり、広まっていません。
SBOMの生成について
OSSやプロプライエタリのコンポーネントをどのように、どこまで管理しているのかによってSBOM生成の方法は変わってくると思います。
自社で開発したコードだったり、委託したコードの中には、どこからかコピーしてきたコードが混入していることは良くあることです。そういったコードをスニペットと呼びますが、SBOMを作るうえでスニペットの検査は必須です。パッケージ管理ソフトウェアを使っている場合などは依存性解析機能も必須です。
コードスニペットの検査や依存性解析が可能なツールとしては、Black Duckが一番メジャーです。
他にはFOSSIDも使えます。機能的に調べ切れていませんが、ツールとしては他にFossolgy、WhiteSource、FOSSAなどがあります。
これらのツールの一部ではSBOMも生成可能で、その機能をつかってSBOMを生成することが一番効率的でしょう。逆にこれらのツールを使って生成していないSBOMは、その生成プロセスの十分性を疑われてしまいます。
しかしBlack Duckは非常に高額なツールですので、小規模なソフトウェアでは無償のツールを使ったり、手動での作業が入っても致し方ないところだと思います。
SBOM生成の注意点
SBOM管理の目的は、脆弱性が含まれているかどうか簡単に確認できることにあります。
脆弱性が含まれるOSSを利用している場合は、それがすぐにばれてしまうことになります。たとえ脆弱性が含まれる機能を使っていなかったとしても、コンポーネント名とバージョンという粒度でしか確認はされませんので、クリティカルな脆弱性を持つOSSを使っている場合は、すぐに不適合な製品とみなされてしまいます。
このようにSBOM提供するということは、脆弱性管理のレベルをあげることにつながります。脆弱性は製品を出した後に見つかることも多く、迅速にパッチを提供したりする体制も整えておく必要もあります。
またツールでSBOMを生成すると、ソースコードのパスであったり、開発者のコメントなどが流出する可能性があります。こういった中には外に流出させたくないものも含まれるリスクがあります。こういった意味からもSBOMの構成はNTIAが指定する最低限のものだけにしておくことがお勧めです。
まとめ
今回はサプライチェーンセキュリティで注目を浴びているSBOM提供について、ざっと説明させていただきました。日本国内ではまだまだSBOM提供を要求されることは少ないかもしれませんが、米国を中心に既に良く行われるようになっています。ツールを整備したり、運用プロセスを整えたりと、準備にはそれなりの時間がかかりますので、できるだけ早くSBOM周りの準備は進めておきたいものです。
コメント