KEVを活用した依存ソフトウェアの脆弱性管理の省力化

Published in

The Finatext Tech Blog

8 min readJul 3, 2023

こんにちは、Finatextの @s_tajima です。

今回は、Known Exploited Vulnerabilities Catalog (いわゆるKEV Catalog) や、Amazon AthenaとAmazon QuickSightを用いて、日々大量に発生しすぎて適切に管理することが難しかった依存ソフトウェアの脆弱性管理を省力化したお話です。

背景

依存ソフトウェアとは

昨今のソフトウェア開発において、すべてのシステムを自分たちの独力で作り切ることはほとんどなく、多くの場合、社外で作成されているOSや、プログラミング言語や、それらのサードパーティライブラリやパッケージを利用(依存)しています。

ここでいうサードパーティライブラリやパッケージとは、OSにおいては

RedHat系ディストリビューションにおける dnf/rpm
Debian系ディストリビューションにおける apt/deb
Alpine Linuxにおける apk

また、プログラミング言語では

Go における Go Modules
JavaScript/TypeScript における npm や Yarn
Python における pip

などによってインストール・管理されるものを指します。
この記事では、これらをまとめて依存ソフトウェアと呼ぶこととしています。

依存ソフトウェアの脆弱性とは

これらの依存ソフトウェアにも、当然脆弱性が見つかる場合があり、放置すると自分たちのプロダクトやその利用者に大きな影響を与えるものもあります。

例えば最近だと、

Apache Log4j の Log4Shell (CVE-2021–44228) をはじめとする一連の脆弱性
Spring Framework の Spring4Shell (CVE-2022–22965)
Fortinet製品におけるSSL-VPN機能の脆弱性 (CVE-2023–27997, CVE-2022–42475)

などが近年大きな話題になったと記憶しています。

こういった脆弱性の情報は、

などから取得することができます。

依存ソフトウェアの脆弱性の検知

脆弱性管理において、脆弱性の情報とセットで必要になるのは、それらの脆弱性が組織で管理するどのシステム・ソフトウェアに影響しているかという点です。

この観点においては、昨今様々な便利なツールが存在します。

例えば、

SaaSとしては Snyk や yamory や GitHubのDependabot や AWSのECR image scanning
OSSとしては Trivy や Clair や Vuls

などがそれにあたります。
※それぞれ、検査対象のレイヤーが違ったり、脆弱性検知以外の機能も持っていたりしますが、その説明は割愛します。

これらのツールによって、脆弱性の検知や、そのアラート通知自体はそれほど手間なく行なえますが、そのアラートの量が大量になり、多くの組織がそのトリアージに頭を悩ませていると思います。

依存ソフトウェアの脆弱性の管理・対応の大変さ

依存ソフトウェアの脆弱性は「放置すると自分たちのプロダクトやその利用者に大きな影響を与える」とはいえ、前述のような情報源から取得できる情報や、ツールによって発生するアラートの総量は膨大であり、すべての脆弱性情報に目を通し自社のシステムに対する影響を評価するのはとても現実的ではありません。

cve.orgのMetrics を見ると、2022年には 25,059 ものCVE IDが発行されているのがわかります。営業日関係なく365日対応し続けたとしても、すべて見るためには1日あたり70個近くを確認しなければならない計算です。

すべての脆弱性情報やアラートの内容を見るのは難しいとして、セキュリティ担当者は例えばCVSSの Base Score や Vector をベースに特定の条件に基づきフィルターをする等、様々な方法で確認・対応すべき脆弱性情報の絞り込みを行っていますが、適切な条件を設定するのも難しく、またそれでもなお対応の負荷は高いままであることが多いです。

KEV Catalog

依存ソフトウェアの脆弱性のうち、実際に悪用が確認された脆弱性のリストとして、CISAが Known Exploited Vulnerabilities Catalog (KEV Catalog) というデータベースを公開しています。

CISA の発行している、 “Reducing the Significant Risk of Known Exploited Vulnerabilities” というPDFにおいて、

CISA has observed that risk scores, based on the Forum of Incident Response and Security Teams’ Common Vulnerability
Scoring System (CVSS), do not always accurately depict the danger or actual hazard that a CVE presents.
.. snip ..
Instead of only focusing on vulnerabilities that carry a specific CVSS score, CISA is targeting vulnerabilities for remediation that have known exploits and are being actively exploited by malicious cyber actors.

と記載されている通り、このデータベースには、

CVE IDがアサインされていて、
アクティブに攻撃が行われていて、
明確な緩和措置が存在する

脆弱性が記載されています。
このデータベースは、本来アメリカの政府機関等に向けて公開されているもので、対応に関する強制力があるリストになりますが、それ以外の組織にとっても、アラートのフィルタリングという観点で有益に活用できるものになっています。

Finatextにおける脆弱性管理の仕組み

ここまで説明した背景を前提として、Finatextにおいてどのように脆弱性管理を行っているかを紹介します。
ざっくりとした構成図がこちらです。

要点ごとに説明をしていきます。

①脆弱性のアラートの集約

まず最初に、会社で使っている依存ソフトウェアに関連する脆弱性の一覧を作成します。
このときに、脆弱性のアラート情報を集約する手段として、

Amazon ECR image scanning
GitHub の Dependabot

を利用しています。
両者、定期的にLambdaを実行して情報を取得し、アラートの内容をS3 Bucketに保存する仕組みになっています。

②KEVによるフィルタリングとアラートの通知

ここが一番重要なポイントです。

背景に書いた通り、 ①のプロセスによって取得できるアラートは、膨大な量になります。
そこで、弊社では収集したアラート情報と、KEV Catalogに登録された脆弱性情報を、CVE IDをベースに突合し、マッチしたアラートを通知するようにしています。KEV Catalogを使うことで、CVSSベースのBase Score等を基準とする場合に比べて、アラートのノイズをかなり削減することができています。

また、この時の通知は、OpsgenieというOnCallのツールを経由してSlackに流すようにしています。
こうすることで、アラートが通知だけされて未対応になることを防いだり、脆弱性の内容によってアラートの方法を変化させるといったことができるようにしています。