はじめに
SRA Advent Calendar 2024の19日目です。
関西事業部の南部です。
毎年毎年くどいですが、可能な限り誕生日の本日(12/19)に記事を書くようにして8年。48歳になりました。
今回は、SBOMレポーティングサービスなるものを始められそうになってきたので、プロモーションも兼ねて記事を書いてみました。
SBOMとは
昨年の記事にもあるとおり、Software Bill of Materialsの頭文字をとったもので、ソフトウェア部品表を意味し、ソフトウェアを構成するコンポーネントやそれらの依存関係、ライセンス情報などを含めた一覧表になります。
よく食料品におけるどんな原材料で構成されているか表した食品の原材料表示に例えられますし、弊社ウェビナーでもそういう説明をしています。
ChatGPTに聞くと、
SBOM（Software Bill of Materials）は、ソフトウェア製品に含まれるすべてのコンポーネント、ライブラリ、モジュール、依存関係などの詳細をリストアップしたものです。SBOMは、ソフトウェア開発や運用において次のような目的で使用されます。
1. 透明性の向上: ソフトウェアに含まれるすべてのコンポーネントを明確にすることで、透明性を確保します。
2. セキュリティの向上: 使用されているコンポーネントの脆弱性を特定し、迅速に対応することができます。
3. コンプライアンス: ライセンスや法的な要件を遵守するために必要な情報を提供します。
4. メンテナンスの効率化: ソフトウェアの更新やバグ修正を行う際に、影響を受ける可能性のあるコンポーネントを特定するのに役立ちます。
SBOMは、ソフトウェア開発者、運用担当者、セキュリティ専門家など、さまざまなステークホルダーにとって重要なツールです。例えば、あるソフトウェアに脆弱性が発見された場合、SBOMを使って影響を受けるコンポーネントを特定し、迅速に対策を講じることができます。
と当たり障りのない回答でした。
なぜ、SBOMを作成するのか？
SBOM作成は脆弱性対応の第一歩、入口だと考えます。
Log4jの時のように脆弱性が検出されたOSSが自分達が作ったソフトウェアの中にあるかないかを迅速に見つけだすためにもOSS、コンポーネントがまとまっているSBOMは非常に役に立つと思います。
ましてや、EUサイバー・レジリエンス法（CRA）では、脆弱性が発見された場合、24時間以内に報告する必要があります。
OSを含んだ製品の場合、OSに含まれる何百ものOSS、コンポーネントの中から対象があるのか確認が必要になるため、日頃からSBOMを最新化し、OSS、コンポーネントを把握して迅速に対応出来るようにしておく必要があると考えます。
SBOMを作成する範囲は？
弊社ウェビナー参加者との打合せの中で、よく聞かれる質問が"SBOMを作成する範囲"があります。
経産省の手引きでもあまり明確にどの範囲まで作成することが必要との記載がなく、明確化しなさいよとあるため、いろいろ悩むかと思いますが、私はSBOMを作成する範囲＝責任を持たないといけない範囲だと考えています。
例えば、Windows上で動くソフトウェアを作成した場合は、そのパッケージを対象としたSBOMを準備しておけばいいと思いますし、OSを含んだ製品を製造した場合は、製品に含まれているソフトウェア(OS含む)を対象としたSBOMの準備が必要だと考えます。
そしてサービス化へ
私がSBOM管理環境構築に携わったところでも、OSを含んだ製品を製造するため、OS部分のSBOMを作成しようと取り組みました。
そのため、OSに含まれているOSSの一覧を作成し、SCAツールでスキャンするためソースコードを集めようとしました。
しかし、ソースコードの収集はものすごく大変でした。また、ソースコードが見つからないものもありました。
そのため、ソースコードの収集は断念。代わりにOSのパッケージ管理情報からSBOMを作成出来ないかと考え、そのSBOM作成環境を構築することが出来ました。
その経験を活かし、他にも同じ苦労している人がいれば、お役に立てないか(儲かるのでは)と考え、昨年度から事業部内にワーキンググループを発足。今年度も活動を継続する中で、ツールを作成し、サービスとして提供できる下地を作成するに至りました。
おわりに
ようやく形が見えてきたばかりのサービスで、これからの方向性も模索状態なサービスです。
これからの活動の中で、成長していければと思っています。
乞うご期待ください。