はじめに
弊社では、複数の SaaSサービス 及び パッケージソフトウェアを開発しています。
これらの製品、サービスに対して 4月から取り組み始めたSBOM(Software Bill of Materials)を利用した脆弱性管理の導入に関する取り組みについてのまとめです。
これからSBOMを導入しようとしている方が導入時の流れをイメージする助けになればと思います。
SBOMを利用した脆弱性管理
SBOMを使って、脆弱性管理を部門内横断的に実施していこう！というのが、現在私が取り組んでいることになります。
ソフトウェアの脆弱性管理はどの企業でも行っている事だと思いますが、これにSBOMを導入することでソフトウェアの構成を整理し、
- 脆弱性残留リスクの低減
- 脆弱性対応期間の低減
- 脆弱性管理にかかるコストの低減
といったことを目指していこう。といった取り組みです。
なお、取り組みを開始するにあたっては、経済産業省のページからダウンロードできる「ソフトウェア管理に向けたSBOMの導入に関する手引Ver.2.0」が大変参考になりました。こちら、SBOM管理を行っていこうとする方には必携の手引書かと思います。
特に、今年8月末に更新されたVer.2.0では、SBOM管理とは何ぞや？という概念の話だけでなく、具体的な手順の話が追加されています。
実際の取り組み
では、実際にどのような取り組みをしているのかを紹介します。
現状把握と情報整理
最初に行ったのが、現状の把握になります。
- プロジェクト(製品名)
- 開発言語
- ツール
- IDE
- ビルド環境
- 構成管理
- 動作環境など
これらの情報を、製品の開発責任者の方へヒアリングし、回答をいただきます。
…結構バラバラでした…
並行して、SBOMの適用範囲(5W1H)をまとめました。
| 観点 | 適用項目 |
|---|---|
| 作成主体(Who) | 自組織 |
| 作成タイミング(When) | ソフトウェアビルド時 バージョンアップ時 |
| 活用主体(Who) | 開発ベンダー(自組織) |
| 対象範囲(Where) | 開発主体が直接利用するコンポーネント |
| 作成手順(How) | SBOMツールを用いて自動作成 難しい場合は構成管理情報から手動作成 |
| 活用範囲(Where) | 脆弱性管理 |
| フォーマット(What) | CycloneDX |
SBOM管理ツールの選定
SBOM管理ツールを選ぶにあたっては、
- 有償/無償
- 作成・提供元
- 商用対応
- 扱えるSBOM形式
- 脆弱性管理
- EOL管理
- CI/CDへの統合
- GUIが標準提供
といった観点で比較を行い、最終的にOWASPが提供するDependency-trackを選んで検証することに決定しました。
Dependency-Trackを選んだ理由
Dependency-Trackは先にも書いた通り、OWASP(Open Worldwide Application Security Project)が提供している、フリーのSBOM管理プラットフォームです。
- 複数のプロジェクトの管理
- SBOM収集
- 複数の脆弱性DBとの連携
- 脆弱性の解析
- 脆弱性対応状況の管理
- Docker Compose定義が提供されており、導入が容易
といった特徴があります。
今回、SBOMの適用範囲にて活用範囲(Where)を「脆弱性管理」に定めているので、セキュリティに特化したSBOMフォーマットであるCycloneDXを提唱したOWASPが提供するツールは、ぴったりのツールと言えると思います。
また、Dependency-trackはOWASPのSlackコミュニティーの活動が活発で、こまめなアップデートが続けられている点も好印象でした。
実運用に向けての課題
実運用に向けて準備をする中で、現状の課題点を紹介します。
SBOMの作成
SBOM管理をするには、当然ながらSBOMを作成しなければなりません。
ですが、最初に行った現状把握の通り、プロジェクト毎に使っているツールが結構バラバラで、画一的なSBOM生成をするのが難しいというのが課題です。
歴史のあるプロジェクトによっては、プラグインの提供されているJenkinsなどではなく、内製の構成管理ツールを利用しているものもあるため簡単ではないのです。
今のところ、CycloneDX Generatorが割とイケそうな予感？(検証中)
有償のSBOM管理ツールの場合、バイナリ解析も行えるSBOM生成ツールが付属している製品もあるようですが…(お高い)
複数の脆弱性DBと連携可能だけれど…
先にも触れたとおり、Dependency-trackはNVD、GitHub Advisories、Trivyなど、複数の脆弱性情報源に対応していることが特徴です。
脆弱性情報源が1つだけだと、抜け漏れの発生する恐れがあるところを、複数の情報源を参照することでカバーできる利点があると思いますが、同時にちょっと困ったことも起こします。
例えば、Aの情報源では「High(重要)」と分類された問題が、Bの情報源では「Unassigned(未割り当て)」のとして分類される…ということが起きてしまうことがあるのです。
抜け漏れが発生するよりは良いのでしょうが、実運用では開発者の脆弱性トリアージの際に混乱を招くことの無いように準備をしていきたい点です。
これから取り組むこと
現段階では実運用に向けた準備中といったところですが、まずはともかく運用を開始してみよう！と思っています。
この先は課題のところにも書いた、脆弱性トリアージを混乱なく実施できるようなルール作りを整備することが重要になりますが、実際には実運用の中での調整が必要となりそうです。
また、ツールの利用を通じて「プラス・セキュリティ」の意識を広げることが出来れば良いな。というのがひそかな思い。
セキュリティは担当者だけが頑張っても広げるのが困難なので、少しずつ草の根で意識を広げていきたいところです。
余談
筆者は2024年1月からB-EN-Gの一員として、開発部門のセキュリティあれこれに関するお仕事をしています。
今回の取り組みは、プロダクト横断的に脆弱性の管理を一元管理する仕組みを導入できると便利そう…という漠然とした思いを上司との面談の時に話したら、
「それは良い！ぜひやってください！」
とのお言葉をいただいたことがキッカケでした。
あれ？なんか自分で仕事増やしちゃった？
入社して3か月足らずで今回のような取り組みをさせてくれる職場環境に感謝です！