SBOMで始める脆弱性管理の実際 - NTT Communications Engineers' Blog

この記事は、 NTT Communications Advent Calendar 2022 1日目の記事です。

はじめに

こんにちは。イノベーションセンターテクノロジー部門の西野と申します。

「Metemcyber」プロジェクトで、脅威インテリジェンスの運用や活用に関する研究開発をしています。

今回の記事では、SBOMを利用した脆弱性管理の取り組みについてご紹介します。

実は NTT Communications Advent Calendar に6年連続で寄稿しているので、そろそろ名前を覚えてあげてください。

SBOMとは？

SBOMは「ソフトウェア部品表（Software Bill Of Materials）」と呼ばれるもので、一般的には特定のソフトウェアに含まれるコンポーネントの依存関係を記述するために利用されます。記述フォーマットとしてはSPDXやCycloneDXが有名です。

SBOMに関するNTIAのレポート¹では、SBOMのデータフィールドに含める具体的な情報として以下のような項目（ベースライン情報）を挙げています。

サプライヤー名
コンポーネント名
コンポーネントバージョン　など

NTIAのレポートは2021年にリリースされましたが、それぞれの仕様を載せているレポジトリ² ³を調べると、SBOMに使われている記述フォーマットの歴史はさらに古いことが確認できます。

# SPDX の firtst commit
$ git log --reverse
commit 01597d36837bdcdf70f0501f50284eb7a94a6341 (tag: v1.0)
Author: Thomas Steenbergen <opensource@steenbe.nl>
Date:   Wed Aug 17 09:00:00 2011 +0100

# CycloneDX の firtst commit
$ git log --reverse
commit 62da520711b3bfb6bb51b4736066e5127922c8e2
Author: Steve Springett <steve@springett.us>
Date:   Sun May 28 21:22:06 2017 -0500

SPDXは2010年に発案された規格で、元々はソフトウェア部品のライセンス管理を目的⁴として設計されました。

CycloneDXは2017年に発案された規格で、OWASP Dependency-Track と呼ばれるコンポーネント分析プラットフォームのために設計⁵されました。主なユースケースは、脆弱性の識別、ライセンス管理、古いコンポーネントの分析です。

なぜ今SBOMなのか？

SolarWinds製品への攻撃⁶、Codecovのセキュリティインシデント⁷を皮切りに、2021年頃からサプライチェーンを狙ったサイバー攻撃の危険性が本格的に認識されるようになりました。

Typosquattingはもちろん、Dependency Confusionと呼ばれる新たなサプライチェーン侵害のテクニックも報告されています。

ソフトウェアサプライチェーンのセキュリティに注目が集まる中、SBOMの重要性は上がり続けており、2022年9月には米政府機関のソフトウェア調達⁸にSBOMの内容が盛り込まれる事態となりました。

さぁ皆さん、SBOMを使ってソフトウェアサプライチェーンのセキュリティを万全にしましょう。

…とは、ならない話が今回のメインテーマになります。

なぜ今までSBOMが話題にならなかったのか

QualcommのセキュリティエンジニアリングVPであるAlex Gantman氏が、SBOMの課題⁹を端的に表現しています。

「最良の（アイディアであるが、誰も実行していない）プラクティス」

Gantman氏はSBOMに3つの問題があると指摘しています。

コンポーネントはアトミックではない
脆弱性は状況に依存する
間接的なレイヤは根本的な依存を排除しない

コンポーネントはアトミックではない

Gantman氏は、「ソフトウェア部品」のアナロジーがそもそも不適切であると指摘しています。ソフトウェアを分解しても、車の部品のように規格化されたモジュールとして取り出すことはできません。サードパーティのパッケージがどのように使用されているかも不明な状況で、コード断片に一意の識別子やバージョンを付与しても意味のある管理にはならないと述べています。

脆弱性は状況に依存する

Gantman氏は、コンポーネントの利用方法を知らなければ実際のリスクを評価できないと指摘しています。タイヤがパンクする欠陥を見つけたとしても、走行中の車なのか、木のブランコなのかで対処の優先度は大きく変わります。これはSBOMに限った話ではありませんが、実際のサービス影響を考慮した脆弱性評価を現場は求めています。

間接的なレイヤは根本的な依存を排除しない

Gantman氏は、サードパーティライブラリのリスクはソフトウェア提供者でなければ判断が難しいことを指摘しています。先に述べたように、アトミック性やコンテキストの問題がある以上、利用者によるサードパーティライブラリのリスク評価は低精度かつ高ノイズなものになります。その結果、利用者は提供されたSBOMの情報をもとにソフトウェア提供者へリスクを問い合わせる状況が生まれます。

利用者がソフトウェア提供者にサードパーティライブラリのリスク評価を委任できるのであれば、そもそもSBOMの情報を提供する意味があまりないように感じます。

運用上の課題は他にも

SBOMは優れたアイディアですが運用例があまり報告されておらず、実際のメリットは未知数な部分が大きいです。

また、SBOMのユーザ提供はソフトウェアの模倣リスクを高めることにも繋がるため、各社ベンダはメリットとデメリットを十分理解した上で取り組む必要があります。

ソフトウェアセキュリティの業界フォーラムであるSAFECodeも、以下のような声明を出しています。

Much of the text in the NTIA request for comments describes benefits from an SBOM that are highly speculative. It is important that no guidance or requirements about SBOM be issued under the Executive Order until there are clear and complete demonstrations at scale that the putative benefits are in fact realizable.” - SAFECode

2022年9月の米国大統領令¹⁰の中には、「募集要項でSBOMを要求する場合がある」と書かれているだけですが、アメリカ以外の政府機関もこの方向に動いていく可能性は十分に考えられます。

実運用からみたSBOMの利用

NTTコミュニケーションズでは、既にSBOMを利用したアタックサーフェスマネジメントを実験的に始めています。

取り組みの際、私たちが考慮したことは「SBOMの生成や収集が目的になるような運用をしない」ことでした。先にも説明しましたが、SBOMのユースケースは、脆弱性の識別、ライセンス管理、古いパッケージの検出と多岐に渡ります。

「なんとなく良い/悪いけど、いまいち効果が分からない」事態を避けるため、実際の使い道を決めてからT字型に運用の幅を広げていくアプローチを取りました。

何のためのSBOMなのか

私たちは、脆弱性管理の観点から最初の取り組みを始めました。その理由は大きく分けて2つあります。

社内に脆弱性管理をするシステムが既に存在する
GitHubのDependabotと機能や性能を比較検証できる

これだけ聞くと、既に脆弱性管理ができているので取り組む意味がないと感じるかもしれません。しかし、「既存の脆弱性管理システムをSBOMでどう改善できるのか？」「業界標準のサービスと比較して、新たにSBOMを利用する意味があるのか？」という2点は、SBOMのメリットやデメリットを確認する素晴らしい試金石になりました。

誰のためのSBOMなのか

また、SBOMの利用者についても考える必要があります。私たちの議論では対象となる人物像を3つに絞りました。

脅威アナリスト
- SBOMを利用して、収集したサイバー脅威情報をフィルタリングしたい
- SBOMを起点に、サイバー脅威情報のハンティングをしたい
開発者
- 脆弱なパッケージを利用しているか検知したい
- 脆弱なパッケージが見つかれば修正したい
- 修正できなければサイバー攻撃を緩和する実装を知りたい
- 余分なパッケージが混入しているか検知したい
- 余分なパッケージを利用していれば削除したい
運用者
- 脆弱なパッケージを利用しているか検知したい
- 脆弱なパッケージが見つかれば修正したい
- 修正できなければサイバー攻撃を緩和する手法を知りたい

正直にいうと、全てのロールで実際の検証ができたわけではないのですが、誰がどう使うのかを意識しながら検証を進められた点は非常によかったと思います。

Gantman氏の記事にも注釈がある部分ですが、SBOMはまず社内利用またはグループ会社間の利用を想定すべきだと個人的には思います。

「透明性の確保」を目的に外部提供を推進する動きもありますが、実際のユースケースを集めずにSBOMの生成や利用の基準を統一することは困難でしょう。

SBOM対応の脆弱性スキャナ

OSSで有名な脆弱性スキャナはいくつかありますが、SBOMの観点から以下の2つを候補に選びました。

どちらも非常に優れた脆弱性スキャナなので、どちらを使ってみるかは好みで良いと思います。開発の都合上、私たちは何度もスキャナを動かすことが想定されたので、スキャン速度が早いTrivyを採用しました。脆弱性スキャナの詳細に関しては、7日目の志村さんの記事をご覧ください！

Gantman氏の問題を実運用から考える

結論から言うとSBOMに関するGantman氏の指摘は正しく、SBOMの実運用にはある程度の割り切りが必要です。

パッケージマネージャがアトミック性を決める
コンテキスト問題はSBOMで解決できない（が、使われ方に偏りあり）
想定外のパッケージ混入を開発者に確認できる

パッケージマネージャがアトミック性を決める

「コンポーネントはアトミックではない」は正しいですが、アトミック性を意識したソフトウェア開発は可能です。そして実運用の観点では、npmやPyPIなどの言語パッケージや、Ubuntuのaptで管理されるOSパッケージがアトミックな単位として機能します。

言い換えれば、「パッケージマネージャ」がなければ大規模なSBOM運用は難しいと思います。

本来のSBOMであれば、パッケージマネージャに拘らない絶対的な基準があるべきかもしれませんが、対応できたとしても実運用上は管理が困難です。

脆弱性管理やライセンス管理に関しては、「まずはパッケージ単位で管理できる状態をつくる」ことがSBOM導入の最初のステップになります。

コンテキスト問題はSBOMで解決できない

「脆弱性は状況に依存する」は正しいですが、ライブラリ次第では使われ方のコンテキストがほぼ一定のものがあります。npmにおいては、google-auth-libraryのような認証系のライブラリがその例です。

一方、全く使われ方が想定できないものも存在します。ユーティリティ系のライブラリです。有名どころでは、lodashやanymatchがありますが、社内のリポジトリを調べても本当に多種多様な使われ方をしていました。

SBOMはコンテキスト問題を解決できませんが、私たちはSBOMを根拠に社内で使われているライブラリの利用状況を調べることができました。

全てのパッケージを調べることは困難だと思いますが、パッケージの統計的な利用傾向やよく利用される上位のパッケージを調べることで、脅威アナリストはサービス影響のコンテキストを理解しやすくなると思います。

想定外のパッケージ混入を開発者に確認できる

「間接的なレイヤは根本的な依存を排除しない」は正しいですが、第三者がパッケージの使用について指摘できる点はメリットがあると感じました。

具体例を挙げると、react-scriptsの使用によってnth-checkの脆弱性アラートが検出された事例です。

これは界隈では有名なissueですが、npmの脆弱性管理をシンプル化するには、本番環境で必要のないパッケージをdependenciesではなくdevDependenciesに移動する必要があります。

  "dependencies": {
    "react": "^18.2.0",
    ...
  },
  "devDependencies": {
    "react-scripts": "^5.0.1"
    ...
  },

SBOMの収集によって、本番環境に本来必要がないライブラリを検出できたことは、開発者のミスや勘違いを防ぐ仕組みとして意義があると思います。

逆に言えば、第三者にSBOMを提供するメリットは、実用上これくらいしかないのでは？という気がします。

Threatconnectome

SBOMの検証を通じて、私たちはアタックサーフェスマネジメントツール Threatconnectome(スレットコネクトーム) を開発しました。

SBOMと脅威情報のマッチングによるアラート機能
脅威を軽減または削除するアクションの実行管理
アクションの実績からチームや個人のスキルレベルを評価

などの機能があります。

Software Identification（SWID）やCommon Platform Enumeration（CPE）は今回の目的では利用が難しく、UUIDと独自の命名規則でソフトウェア部品を管理しています。現在はTrivy対応だけですが、SyftやGrypeの連携も今後行う予定です。

来年にはOSS公開できると思いますので、皆さん期待して待っていてください。

SBOMを脆弱性管理に使ってみた感想

まず、社内の脆弱性管理を効率化するために、あらゆるメタデータを集めておくことが重要です。これはCODE BLUE 2022でAirbnb社のセキュリティエンジニアPlattner氏、Mashal氏が講演していた内容¹¹とも被りますが、あくまで「SBOM」は収集するメタデータの1つに過ぎません。

ファイルフォーマットの選択もあまり意味がなく、osqueryでサーバのパッケージ情報を集めるような運用から始めても全く問題ないと思います。

むしろ、重要なことは「どの情報を」「何のために使うか」です。これを決めずにSBOM運用を始めるのはオススメしません。

社内の脆弱性管理システムの改善

誤解ないように説明すると、全てのプロダクトにいきなりSBOM管理は適用できません。理由は先にも述べた通り、「アトミック性を意識したソフトウェア開発」と「パッケージマネージャ」の存在が不可欠だからです。これらを考慮せずに作られたプロダクトに対して、大規模なSBOM管理は上手くいきません。

SBOM管理が可能なプロダクトに対し、アラート通知の効率化やオートクローズ対応を行うことで、開発者や運用者に余裕をつくることが最初のポイントになると思います。

また、脆弱性対応の人為的ミスがないことを検証するフェーズも重要です。もし検証するフェーズがない場合は、SBOMを利用した検証から始めるのも良いでしょう。

GitHubのDependabotと比較

この部分の内容は、あくまでリポジトリを対象とした脆弱性管理であり、コンテナや物理サーバが対象ではないことに注意してください。

脆弱性管理の観点では、trivy-dbからエクスポートしたデータで脆弱性管理をしていたので、Dependabotで検知されたものは全て検出ができました。(trivy-dbは様々な脆弱性情報を収集しており、その中にはDependabotが使用するGitHub Security Advisoriesも含まれる)

私たちの環境では、GitHubアクションでmainブランチのSBOMを抽出し、その情報をThreatconnctomeに自動登録するワークフローを実行していました。

GitHub上で開発をしているのであれば、Dependabotによる脆弱性検知をまず最優先で有効化してください。 脆弱性検知の観点では、SBOM管理のソリューションを新たに導入するメリットはほぼないと思います。

一方、脆弱性管理の点ではDependabotアラートだけでは難しい状況がありました。実運用では「必ずしもライブラリのバージョンを上げたくない」ケースがあり、その場合は分散したレポジトリをアナリストが継続的に監視する必要があります。また、複数のレポジトリを横断する分析もGraphQLだけでは限界があり、アタックサーフェスマネジメントの点でも課題が残りました。

私たちはThreatconnctomeでこれらの問題を解決しました。組織によってはGitHub Advanced Securityで十分なケースもあると思いますので、そちらの利用も是非検討してみてください。