SBOMで始める脆弱性管理の実際
NTTコミュの記事
意外と歴史古い
SPDXは2010年に発案された規格で、元々はソフトウェア部品のライセンス管理を目的として設計されました。 CycloneDXは2017年に発案された規格で、OWASP Dependency-Track と呼ばれるコンポーネント分析プラットフォームのために設計されました。 なるほど、乗っかってきたわけかsta.icon
因果関係どうなってんだ？sta.icon
SBOM考えて、その実装としてSPDXやCycloneDXを考え始めた、ではないのか……
SBOMの問題点3
コンポーネントはアトミックではない
ソフトウェアを分解しても、車の部品のように規格化されたモジュールとして取り出すことはできません。
ちなみに「ネット上のその辺のコード」や「プロプライエタリ（社内で流用したとか）」の流用は検出できない
で、どうする？
そして実運用の観点では、npmやPyPIなどの言語パッケージや、Ubuntuのaptで管理されるOSパッケージがアトミックな単位として機能します。言い換えれば、「パッケージマネージャ」がなければ大規模なSBOM運用は難しいと思います。
まずはパッケージ単位で管理できる状況をつくるところから、言うてるね
これは俺も+1sta.icon
特にnpmは一番良く出来てる
脆弱性は状況に依存する
コンポーネントの利用方法を知らなければ実際のリスクを評価できないと指摘しています。タイヤがパンクする欠陥を見つけたとしても、走行中の車なのか、木のブランコなのかで対処の優先度は大きく変わります。これはSBOMに限った話ではありませんが、実際のサービス影響を考慮した脆弱性評価を現場は求めています。
SBOMというか脆弱性管理の話sta.icon
で、どうする？
「脆弱性は状況に依存する」は正しいですが、ライブラリ次第では使われ方のコンテキストがほぼ一定のものがあります。npmにおいては、google-auth-libraryのような認証系のライブラリがその例です。
一方、全く使われ方が想定できないものも存在します。ユーティリティ系のライブラリです。有名どころでは、lodashやanymatchがありますが、社内のリポジトリを調べても本当に多種多様な使われ方をしていました。
利用傾向や利用ランキングを調べればコンテキスト理解が進む、という程度を言うてるねsta.icon
間接的なレイヤは根本的な依存を排除しない
Gantman氏は、サードパーティライブラリのリスクはソフトウェア提供者でなければ判断が難しいことを指摘しています。先に述べたように、アトミック性やコンテキストの問題がある以上、利用者によるサードパーティライブラリのリスク評価は低精度かつ高ノイズなものになります。その結果、利用者は提供されたSBOMの情報をもとにソフトウェア提供者へリスクを問い合わせる状況が生まれます。
利用者がソフトウェア提供者にサードパーティライブラリのリスク評価を委任できるのであれば、そもそもSBOMの情報を提供する意味があまりないように感じます。
依存するすべてのサプライヤーがSBOMをちゃんとつくれるか問題、つまり全員がちゃんと従ってくれるか問題と同義やねsta.icon
で、どうする？
SBOMの収集によって、本番環境に本来必要がないライブラリを検出できたことは、開発者のミスや勘違いを防ぐ仕組みとして意義があると思います。
逆に言えば、第三者にSBOMを提供するメリットは、実用上これくらいしかないのでは？という気がします。
米
2022年9月の米国大統領令の中には、「募集要項でSBOMを要求する場合がある」と書かれているだけですが、アメリカ以外の政府機関もこの方向に動いていく可能性は十分に考えられます。
知らん。俺も調べよ
誰のためのSBOMなのか
脅威アナリスト、開発者、運用者の3つに分けてる
まずは社内で
Gantman氏の記事にも注釈がある部分ですが、SBOMはまず社内利用またはグループ会社間の利用を想定すべきだと個人的には思います。
「透明性の確保」を目的に外部提供を推進する動きもありますが、実際のユースケースを集めずにSBOMの生成や利用の基準を統一することは困難でしょう。
+1sta.icon
ユースケース集められたとしても難しいとおもうけど
つーか社内でも統一すんのむずくない？
うちでも既に社内システム、BlackDuck、その他……で勢力がnつあるsta.icon
俺はBlackDuckみたいに自社でデータベース拡充させて、それを外売りして業界を食ってくのが良いと思っているよ（誰にも通じてないけど）sta.icon
SBOM対応脆弱性スキャナ
知らんsta.icon
Syftはしょぼかった覚えあるけど
Trivyはスキャン速度早いらしい
コンテナだけじゃないっけ？ソフトウェアプロジェクト自体にかけるってできるの？
アタックサーフェスマネジメントツール Threatconnctome(スレットコネクトーム)
来年にはOSS公開できると思いますので、皆さん期待して待っていてください。
早いなーsta.icon
うちとは大違いだぜ
ファイルフォーマットの選択もあまり意味がなく、osqueryでサーバのパッケージ情報を集めるような運用から始めても全く問題ないと思います。
むしろ、重要なことは「どの情報を」「何のために使うか」です。これを決めずにSBOM運用を始めるのはオススメしません。
+1sta.icon
重要なのはソフトウェアやシステムの構成情報を把握すること。それをどんなフォーマットでどう使うかはそれぞれ。SBOMもその一つでしかない
ちなみにうちでは、というか俺は「構成情報を集める基盤」をつくって、この基盤に多様な入力手段を設けて貯めつつ、各管理システムは常にここからデータ取ってくるような3層にするのが良いのでは、言うてる
一応通じたけど、予算取ってくるには説得しないとねーとか言われてる
いや必要なの明らかだし、これくらい投資しねえとSBOM含めて構成情報の界隈に切り込んでいけないと思うんだけどねぇ……
で、その際に重要になってくるのが表記揺れの問題
たとえばReactは「React」が正解だが、「react」や「リアクト」は不正解。「React」という文字列でシステム側に登録してもらわないといけない
こういう揺れをどう解決するよって話？
sta.icon
ソフトウェア屋さんって感じがするね
逆にうちはSIerなので「本番環境のシステム」の管理がメインってなってる
が、スキャンなんでOSのパッケージ取るくらいしかない（もちろんコンテナはそんな扱えてないので不得手！）し、お客様環境みたいな事情もあるから結局手作業が多い……
そしてこのシステム対象の管理でソフトウェアもやらせようとする狂気も持ってはる
この辺何とかしようぜってのが今動いてて、今sta.iconもそのメンバーの一員ではあるのだけどね……
上述のとおり、俺は既に理想論つくってるけど、末端の平社員ですからね、伝える手段がない
慌てず直属とのやり取りで鍛えていくべきなのかねぇ