開発部門が直面する脆弱性管理の課題に対策を！ ～SSVC や脆弱性統合管理ツール活用による成功へのヒント～

3行でわかる本記事のサマリ

• ソフトウェア開発において、OSSを含む脆弱性の管理が重要視されており、効果的な優先順位付けが課題に
• 膨大な脆弱性管理・対応のため、シフトレフトがうまく実践できているケースは少ない
• SSVCや脆弱性統合管理ツールを活用することで、組織の脆弱性管理の負担を軽減可能

目次

1. はじめに　～ソフトウェア開発における脆弱性管理の必要性～
2. 開発現場における脆弱性対処の課題　～シフトレフトの実情～
3. リリース後の脆弱性対処の課題
4. 脆弱性の一元管理
5. 脆弱性管理の基本から一歩先へ　～SSVCを活用した運用～
6. ツールを用いた自動化の構成例
7. まとめ

1. はじめに　～ソフトウェア開発における脆弱性管理の必要性～

近年サイバー攻撃は急増しており、その半数以上がソフトウェアに混入した脆弱性に起因するものと言われています。こういった中、企業や組織は自社が開発して提供するサービスはもちろんのこと、外部から調達するデバイスやソフトウェアに存在する脆弱性の状態を一元的に可視化し、それらを管理する必要性が高まっています。
脆弱性を利用するサイバー攻撃は比較的古くから存在したものの、近年ではHeartbleedやShellshockなど2014年に報告された非常に深刻な脆弱性の存在により、より多くの関心を集めました。最近ではLog4Shellが記憶に新しく、誰もが当たり前のように使っていたものが、これほど深刻な影響がある脆弱性を持つことで、脆弱性に対する課題意識はより一段と高まっています。

こういった背景もあり、PCIDSSや薬機法など様々な認証規格やレギュレーション、更には一部法規制においても脆弱性の対応に言及されるケースも増えており、企業や組織はより厳密な脆弱性の管理と対応を求められます。

特にOpen Source Software(以下、OSS)は非常に脆弱性の数が多く、管理が厄介です。昨今の開発ではOSSは広く利用されており、世の中の多くのソフトウェアの中身は7割以上がOSSと言われます。OSSは、その名の通りソースコードが公開されているため利用者も多いです。そのため脆弱性が発見されやすく、時間の経過とともに新たな脆弱性が報告され続けています。

※    2024/4/23時点でhttps://nvd.nist.gov/から取得したデータをグラフ化
※    "Log4Shell logo is provided courtesy of Fractional CISO, LLC."

2. 開発現場における脆弱性対処の課題　～シフトレフトの実情～

ソフトウェア開発の早い段階、つまり設計や開発フェーズ（左側）でセキュリティ対策を実施する考え方である「シフトレフト」というキーワードが、バズワードのように世に広まっていますが、実態はどうでしょうか？
「より影響が少ないうちに可能な限り脆弱性を排除する」という考え方は理にかなっており、ほとんどの人が共感できるものですが、日本はもちろんのこと、米国を含む海外の国々でもうまく実践できているケースはかなり少ないと言われています。

多くの組織では「シフトレフト」を実現するために、開発チームにセキュリティテストを押し付けているのが実情であり、そのために必要となるセキュリティの知見の獲得も含めて丸投げになっているケースが多いためです。
この結果として、異なる開発モデルや目的のために設計されたセキュリティツールが開発プロセスに持ち込まれ、フィードバックループが長引くだけでなく、多くのノイズを発生させています。
特にOSSに対する既知の脆弱性は多くの現場で膨大な数の検知があり、すべての脆弱性に対処することが難しい場合も多いです。こういったケースでは適切にリスクを判定して優先度をつけていく必要がありますが、それは容易ではありません。
従来他のチームの責任だった作業を押し付けられ、自分の生産性が妨げられることに不満を感じない人はいないでしょう。

3. リリース後の脆弱性対処の課題

リリース後のSaaSなどの自社サービスの運用やモバイルアプリ、出荷した後のデジタルデバイスの脆弱性はどうでしょうか？
開発時にはわからなかった脆弱性が時間の経過とともに発見され続け、中にはLog4Shellのように深刻な影響を及ぼす可能性のあるものが見つかるケースもあります。

深刻な脆弱性が見つかった場合でも、まず自社のどの製品に対象の脆弱性が含まれるのかを把握することに大きな労力がかかります。
開発チームが複数ある場合はそれぞれが別々のツールを用いてソフトウェアの脆弱性検査を行うケースも多く、情報が分散してしまい、どうしても問題の発見や対処が後手に回りがちです。

また、世の中ですでに騒がれている脆弱性はすぐに修正・対処に進む判断ができますが、その時点では対処自体が間に合わない可能性もあります、とはいえ、脆弱性が検知されるたびに、リリース済みのサービスや製品に対してアップデートを継続することも、負荷の観点から現実的ではありません。

4. 脆弱性の一元管理

ここでキーとなるのがセキュリティに責任をもつチームが主体となって、自社にある資産の脆弱性を一元管理することができる「脆弱性統合管理ツール」の導入です。Palo Alto Networks社のPrisma Cloud のようにアプリケーションライフサイクルを通しての保護(脆弱性管理を含む)を行うような統合管理ツールを全社的に採用する方法が理想です。開発チームごとのツールの一元化が難しければ、様々なツールのアウトプットを取り込んで一元管理するようなツールを採用する方法があります。

こういったツールの多くは、APIやSBOMなどを介してシームレスに複数の脆弱性スキャナと連携する機能があり、取り込んだ脆弱性情報に対して同じ基準でのセキュリティポリシーを適用したレポーティングができるものが多いです。
従来、脆弱性情報は開発部門などで個別に管理され、それぞれのセキュリティ基準にばらつきがありました。このような統合管理ツールの採用によって情報や基準を一元化していくことができれば、脆弱性ごとのセキュリティリスクの判定も同じ環境で行い、結果を開発チームと共有することができるため、開発チームは、より効率的に脆弱性対応の優先度づけを行うことができます。

5. 脆弱性管理の基本から一歩先へ　～SSVCを活用した運用～

脆弱性統合管理ツールで組織内の脆弱性情報を一元化できたら、次はそのツールを運用していく必要があります。
採用した製品によってはツールの中にあらかじめ優先度付けをするための機能がある場合がありますが、その製品がどのような根拠で優先度を設定するかも重要な要素であり、自組織の方針にあっているかの精査も必要です。
例えば、CVSSのスコアリングをそのまま利用するには現時点では様々な課題があるとされており、あまり有用とはいえません。

詳細はこちらの記事「リスクベースの脆弱性トリアージの必要性を考えよう」をご参照ください。

昨今の優先度づけフレームワークとして望ましいとされるものの一つに、SSVC(Stakeholder Specific Vulnerability Categorization) があります。SSVCについては上記のブログでも触れている通り、CVSSによるCriticalやHighのリスク判定によって対処の件数を劇的に絞り込むだけでなく、MediumやLowに埋もれているものの、実際にリスクが確認されている脆弱性を洗い出すことができる利点があり、より効率的な脆弱性対応方針を検討するために大いに役立ちます。

SSVCなどで判定された分類結果に対して記録を行えることも、多くの脆弱性統合管理ツールがもつ機能です。特に「タグ」による記録の機能は広く採用されています。「タグ」機能をうまく使いこなすことが、こういったツールの運用を効率的に行うために有効な方法のひとつです。

一般的には「要調査」「〇〇にて対処中」「対処済み」といった対処状況のステータスを記録する使い方が多いですが、こういった人手によるタグ付けに入る前にSSVCなどによる脆弱性の優先度付けをおこない、分類結果をタグ付けすることで、膨大な数の脆弱性のどこから見ていくべきかを最初の段階で見極めることができるため、非常に効率的に運用できるようになります。
タグ機能はひとつの脆弱性ごとに複数割り当てることができるのが一般的であるため、SSVCの分類を付与したうえでリスクが高いカテゴリーのものに「要調査」タグを追加でき、さらに外部に情報開示する必要がある場合は「要VEX追記依頼」などのタグも同時に付与するといった運用も可能です。

6. ツールを用いた自動化の構成例

実際に脆弱性統合管理ツールを運用していくには、工数削減だけでなくヒューマンエラーを防止する観点において、可能な箇所は自動化することが重要です。

脆弱性統合管理ツールには、開発部門でよく利用される比較的メジャーなセキュリティツールとの連携が利用できる場合は、スムーズな情報連携が可能です。もしあらかじめ連携機能が用意されていない製品であったとしても、それぞれがAPIをサポートしている場合は、APIを活用することで情報連携を自動化できるケースも多いです。

情報連携の次はSSVCによる脆弱性の分類を行いますが、これは人手で行うと膨大な作業となるため、自動化することが望ましく、それに対応したツールを導入することが推奨されます。弊社では、LeanSeeksというSSVCベースの脆弱性の分類と優先度付けを自動化するSaaS型ソリューションを提供しているため、以下の図ではLeanSeeksを利用する前提での構成を記載しています。

このような構成を構築することで、開発部門からの脆弱性情報の抽出と、SSVCに基づいた統一基準での脆弱性分類を行い、対処すべき脆弱性を明確化するところまでを自動化することができ、開発部門での調査対応範囲も絞り込めるため、シフトレフトを行いつつ、開発業務への影響を最小限に抑えることが可能です。

7. まとめ

今回は脆弱性統合管理ツールによる情報の一元化の有効性と、ツールに含まれるタグ機能を活用した対処判定の明確化、リスク判定基準の一元化による開発チームと運用チームでの共有のメリットについて紹介しました。
今回の構成例はあくまで方法論の一つであり、脆弱性統合管理ツールや優先度付けの方法、開発チームとの情報共有の方法はこの限りではありませんが、もし既存の管理方法に課題や不安がある方の参考になれば幸いです。

本ブログで紹介したLeanSeeksに関して、ホワイトペーパーをご用意しております。
詳しく知りたい方は、是非ダウンロードください。

昨今 DevSecOpsといったキーワードや、それを実現するための「シフトレフト」というアプローチが重要と聞かれるようになりました。
シフトレフトは非常に理にかなったコンセプトであるものの導入は容易ではなく、それを運用していくためには大きな課題があります。
本書では、脆弱性対応の視点でのシフトレフトの実現を妨げる大きな課題とその解決方法を解説します。