SBOMを活用した脆弱性検知とトリアージ自動化の実践例

はじめに

本ブログは今話題のSBOMの概要と、SBOMを活用した脆弱性検知、それからLeanSeeks ₍※₎でのトリアージまでの処理を自動化する方法について紹介します。ちょうど今年(2023年)の3月末にGitHubがリポジトリのSBOMを出力する機能を公開しましたので、今回はそれを活用して脆弱性情報の取得とトリアージまでを解説します。
※ LeanSeeksはSSVCをベースとした脆弱性トリアージサービスを提供するSaaS型のソリューションです。

目次

1. SBOMとは
2. SBOMにかかわる規制の動き
3. 脆弱性スキャンの課題とSBOMの活用
4. SBOMからCVE情報を取得する
5. SBOMの取得から脆弱性情報の取得、対処すべきもののトリアージまでを自動化する
6. まとめ

1. SBOMとは

昨今SBOMというワードがよく聞かれるようになりました。従来よりBOM(Bill Of Materials=部品表)というワードは製造業を中心に使われていましたが、SBOMはBOMにS(Software)を追加した、ソフトウェアの部品表を表します。
ソフトウェアを構成するコンポーネント名やバージョン、作成者といった情報を記録することでソフトウェアの透明性やサプライチェーンのトレーサビリティを提供することを目的としています。
SBOMが適切に管理・提供されることで、例えば先般のLog4shellのような深刻な脆弱性レポートが上がった時に、都度ベンダーや開発者に問い合わせたり、脆弱性スキャナーなどで改めてスキャンしなおす必要もなく、影響度調査や対策実施判断などを迅速に進められるといったメリットが挙げられます。
現在SBOMを作成する主要な業界標準フォーマットとして、SPDX(Linux Foundation)やCycloneDX(OWASP)、SWIDタグ(ISO)などがあり、特にSPDXとCycloneDXについてはスキャナーなどの対応製品が多くなってきています。GitHubも2023年3月からSPDXによるSBOM出力が可能になりました。(本ブログ執筆時点ではSPDX2.3のJSONフォーマットによる出力のみに対応)

2. SBOMに関わる規制の動き

製品の侵害により、その製品のユーザー側で発生した多くのインシデント事例や、前述のLog4Shellのように多大なインパクトのある脆弱性の報告といった状況から、ソフトウェアの透明性の向上が強く求められるようになっています。
米国では大統領令14028 (出典： https://www.gsa.gov/technology/technology-products-services/it-security/executive-order-14028-improving-the-nations-cybersecurity) によって米国連邦政府へのソフトウェアの提供に付帯して当該ソフトウェアのSBOMの提供が求められるようになりました。
また、2025年後半の適用を目標としたEUサイバーレジリエンス法の草案においてもSBOMの要件が明記されており、制定されればEUに対するソフトウェアの輸出においてもほとんどのケースにおいてSBOM付帯が義務付けられるようになります。
この他にも2025年4月から適用されるPCIDSSバージョン4にもソフトウェア構成表の維持管理が要件に組み込まれていることから、PCIDSS準拠においてもSBOMの導入が標準的な適合要件となることが考えられます。

3. 脆弱性スキャンの課題とSBOMの活用

昨今はデジタル基盤の普及や顧客要望からソフトウェア開発のライフサイクルも早まっている傾向があり、DevSecOpsといった観点からも、「セキュリティのシフトレフト」といったことが重要と言われています。「セキュリティのシフトレフト」は、ソフトウェア製品の設定の不備や脆弱性対応をなるべく開発者に近いところで実施することであり、比較的修正の影響度が少ないうちに対策を行うことで、リリースやテストへの影響や修正に伴う工数などのトータルコストを削減するためのプラクティスで、リポジトリへのコミットに連動して動作するCIツールの環境に組み込むことを前提としたツールが多く見受けられます。しかし、たとえ数行の変更であっても既存のCIパイプラインに変更を加えることは簡単に実施できることではありませんし、変更を加えたあとも当該の処理を継続的に維持管理することになります。
また、CIパイプラインに組み込むのが「脆弱性スキャナー」である場合は、そのソフトウェアに含まれる脆弱性の情報はスキャン実行時点のものであり、最新の脆弱性情報を取得するためには都度ソフトウェアのスキャンを実行しなおす必要があります。一部の特殊なソフトウェアのスキャンを行うためにはソフトウェアをホストするために専用のハードウェアなどの環境を用意してCIと連携させる必要がある場合もあり、都度スキャンしないと最新の脆弱性情報がわからないのは、大きな運用課題になります。

こういったケースにおいて、コードリポジトリ上でSBOMを生成できるのであれば、既存のパイプラインや環境に手を入れずに内包ソフトウェアの情報が取得でき、それをもとにいつでも最新の脆弱性情報を取得する仕組みをつくることが可能です。
また、例えばリリース単位でSBOMを保管しておくことで、手元にないバージョンのソフトウェアの脆弱性調査も手軽に行うことができるようになりますし、Log4Shellのようなクリティカルな脆弱性が見つかったときに該当するパッケージを古いリリースのものも含めて迅速に探し出すことも可能です。

4. SBOMからCVE情報を取得する

SBOMのソフトウェア部品情報そのものには脆弱性情報は含まれていません。ただ、ソフトウェア名やバージョンは明確にわかるので、それらで見つかっている脆弱性と紐付けることができます。代表的なものの一つとして、Google社が提供しているOSV-Scanner、またはSPDX-to-OSVというライブラリがあります。OSVというのはGoogle社が提供するOSS向けの分散型脆弱性データベースで、非常に膨大な脆弱性情報を提供しており、かつ誰でも利用することが可能です。OSV-ScannerはCycloneDXまたはSPDXフォーマットで記載されたSBOMをそのまま読み込み、OSVのデータベースに問い合わせた結果を応答してくれる機能をもっているため、CycloneDXまたはSPDXフォーマットのSBOMさえあれば、手軽に手元で最新の脆弱性情報を取得することができるようになります。

5. SBOMの取得から脆弱性情報の取得、対処すべきもののトリアージまでを自動化する

GitHubのリポジトリからSBOMを取得するのは、APIでも容易に実行できます。まだ機能自体が新しいこともあり、出力対象や出力フォーマットなど一部の制約はあるものの、ほとんどのケースで利用可能な機能です。
ドキュメント (出典： https://docs.github.com/ja/rest/dependency-graph/sboms?apiVersion=2022-11-28#export-a-software-bill-of-materials-sbom-for-a-repository--parameters)に記載の通り、自身のTokenが発行できていれば、リポジトリ名とオーナー名を指定するだけで取得可能です。
(github.com/macnicadevops/demoというリポジトリの場合、リポジトリ名はdemo、オーナー名はmacnicadevopsになります。)

これを実行すると、.sbomオブジェクトに入ったSPDX2.3フォーマットのJSONのSBOMが取得できますので、.sbomオブジェクトを除いて出力し、SPDXが推奨する拡張子(ファイル名.spdx.json)で保存します。(出典： https://spdx.github.io/spdx-spec/v2.3/conformance/)

上記の手順で出力されたSBOMは、そのままOSV-Scannerで脆弱性情報の取得に用いることが可能です。
なお、OSV-Scannerはデフォルト出力がTableフォーマットで情報量も少ないため、--jsonというオプションを使ってデータをJSONで取得するとより詳細な脆弱性情報を取得することが可能です。

ここで取得したJSONからパッケージ名とバージョン、CVE-IDを抜き出してLeanSeeks用のフォーマットに入れれば、あとはそのデータをLeanSeeksにAPIで投げ込むと、あとは脆弱性情報の補足情報を様々なインテリジェンスから取り寄せ、トリアージを行います。

一連の処理はいずれもコマンドやAPIによる処理の実行が可能ですので、スクリプトなどを用いてすべて自動化することが可能です。
上記の画像はLeanSeeksのトリアージ結果画面で、左側の円グラフがCVSSのセベリティを表しています。CVSSセベリティを見る限り、Criticalが7件、Highが55件、Mediumが12件と、非常に危険な状態に見えます。
LeanSeeksはこれらの脆弱性を5段階にカテゴライズし、対応優先度を明確に提示してくれます。

非常に危険な状態と思われたアプリケーションでしたが、実際にトリアージを行うとリスクがある脆弱性としてはレベル3（対処計画）のものが1件のみで、残りはすべてレベル1（様子見も可）という結果となりました。また、見つかったレベル3の脆弱性についてはCVSSのセベリティがHighのものから検出されており、Criticalとなっていた脆弱性については、今回はすべてレベル1にカテゴライズされた点も、本当のリスクにフォーカスするうえで重要なポイントとなります。

6. まとめ

本ブログでは、SBOMの通常の業務での活用方法の一つの例を紹介いたしました。
SBOMを出力する製品やサービスはさらに増えており、新たに特別なツールを用意しなくても入手できるようになりました。
SBOMを活用することで、単にソフトウェアの構成把握だけではなく、既存のパイプラインに影響を与えずに脆弱性検知と対処検討が実現でき、都度ソフトウェアをスキャンをし直す必要なく最新の脆弱性情報にアクセスできる点で、脆弱性の対応検討にも大きなメリットがあります。
あわせて今回紹介したLeanSeeksを利用することで、大量に検知された脆弱性の中から自動的に本当に対処すべき脆弱性を抽出することが可能です。

LeanSeeksについてご興味をお持ちの方は、是非マクニカまでご連絡ください。