なぜ知っている脆弱性を駆逐できないのか？　Webサービス開発における外部パッケージの脆弱性管理

自己紹介

水谷正慶氏：では始めたいと思います。TrivyとRegoを用いてパッケージ脆弱性を管理する話です。簡単に自己紹介をします。水谷と言います。Ubie Discoveryでセキュリティのエンジニアをしています。

略歴としては、日本IBMの基礎研究所やセキュリティオペレーションセンターでセキュリティのアナリストを少ししていて、2017年にクックパッドに移り、インフラ関連のセキュリティやセキュリティアラートの対応などをしていました。

2021年の9月に転職したばかりで、自分としてはすごく濃密な日々を過ごしていて、もう半年以上いるような気がしつつ、実はまだ3ヶ月しか経っていないので、けっこうびっくりしています。Ubieでも、特にプロダクト周りのセキュリティをしていて、今回お話しするパッケージ管理も、プロダクト開発に関連しています。

現代のWebサービス開発に伴う脆弱性

外部パッケージの脆弱性管理が今回の話のテーマですが、昨今のWeb系の開発で言うと、サードパーティーのパッケージを使わずに開発するシチュエーションはほぼない気がしています。

サードパーティーは主にOSS（Open Source Software）が多いですが、いろいろなパッケージの恩恵を受けながら素早く開発することで、ビジネスとしても価値検証がやりやすくなっていると思います。

サービスそのものの機能や、フレームワークとして動かして使ったり、例えばwebpackのように、開発をする際のサービスとしてプロダクトに出す時に、いろいろとやるために使ったりするものもあるのではないかと思います。

そういったパッケージ関連のエコシステムが、昨今すごく発展しています。例えば、あるプロダクトがいろいろな外部パッケージを使うというものもあるし、使っているパッケージがさらに別のパッケージを使っているという、孫関係やひ孫関係のようなパッケージの依存関係もどんどんできています。

そうすると、今は1つのプロジェクトあたりで使っているパッケージが、数百や数千あるのはよくあることという世界観になっているのではないかと思います。このような関係性がすごく広くなってくると、きちんと管理することが必要になってくると思います。

脆弱性自体が常にいろいろ出てきます。やはりパッケージを使っている以上、なんらかの脆弱性が出てくるのはどうしても起こることなので、脆弱性をきちんとキャッチして管理していくことが必要になっていきます。

脆弱性の情報自体は、昔に比べればすごく取りやすくなっています。インターネット上のSNSや、専用のフィードの情報も取れる状態がどんどん整ってきているので、脆弱性がある情報自体を取ることは、すごく容易になったと思います。

また、プロダクトを使っている中で、脆弱性が入ったものを使っていないかをスキャンするツールも最近はいろいろ出てきています。そういったツールを使うことによって、自分たちが開発しているプロダクトに脆弱性が入っているかどうかを、けっこう簡単に検査できるようになりました。

さらに、いわゆるCI（Continuous Integration）の文化がいろいろ普及してきて、それを後押しするためのサービスやツールもすごく充実してきて、とてもやりやすい環境になってきたのではないかと思います。

ただ、その状況で既にわかっている脆弱性が全部駆逐されて、すごくハッピーな世界になったかというと、実際問題はそうでもないと思います。

なぜ知っている脆弱性を駆逐できないのか？

では、なぜ知らない脆弱性ではなく、知っている脆弱性を駆逐できないのかに関して、3点ほどポイントがあるのではないかと思っています。

1つ目が、修正版のリリースのタイミングです。そもそも、外部のパッケージを利用しているので、外部のパッケージがどういったタイミングで脆弱性の修正をするかや、それをリリースするかは、自分たちでコントロールできません。そのため、考慮していく必要があると思います。

特にOSSの場合は、コントリビュータの方もボランティアでやっていることがほとんどだと思うので、OSSのパッケージを更新するタイミングは、やはりコントリビュータの方の都合に依存するところもあります。

例えば、こちらからプルリクエストを出して「こういうふうに修正してください」とお願いしても、それを取り入れてくれるかどうか、そのタイミングに関しては、基本的にコントリビュータのタイミングによるので、必ずしもすぐに対応できるとは限らないという状況があるかと思います。

特に難しいのが、依存関係の先の孫の部分にあるパッケージが脆弱で、使っているパッケージの側で上げないと、その先のパッケージがアップグレードされないパターンがあることです。

次の問題は、更新によって、プロダクトが破壊的に変更されてしまうかもしれないということです。これは一定あるのではないかと思います。

基本的に、パッケージを更新することによって、今まで使っていた機能の後方互換性がきちんと担保されているかは必ずしも保証できません。もちろん、テストなどできちんと検証していければすごく簡単ですが、やはり本番環境にデプロイしてみないと再現しない問題も、絶対に一定はあります。そのため、一定のリスクを抱えながら変更作業をする必要は、どうしても出てくると思います。

そういった状況では、すぐに変更していく作業をすることによって、ビジネス自体が止まってしまうこともあります。影響の大きい脆弱性に関しては、すぐに修正しないと厄介なことになります。しかしそうではなく、それほど広い範囲で影響を及ぼさないことがわかっていて、変更によって発生するリスクを考えて少し優先順位を下げてやっているうちに、だんだんそれが溜まっていくようなケースも現場では多々あるのではないかと考えています。

ほかのパターンとしては、パッケージ更新。いわゆるバージョンアップをして、ソースコード自体の脆弱性を修正しなくても、ほかの方法で緩和されている状態もあったりします。

これは別に、緩和されているから直接的に問題ではありません。しかし、脆弱性によっては外部の要因、フィルタした時に、それをフィルタしているかどうかをきちんと管理したいということがあるので、更新がきちんとできていないかどうかの判断が、難しくなってくるのかなと思っています。

必ずしも既存の脆弱性がすぐ更新できるわけではないとなると、脆弱性がどういう状況なのか、そしていつ更新するべきなのか、あるいは更新するべきではないのかを、それぞれ管理していく必要があるかと考えています。

3つの脆弱性の管理要件

その時に実際にどういうことをしなければいけないかも、3点ぐらいポイントがあるかと思っています。

1つ目が、プロダクトや脆弱性ごとに状態を管理したいということです。プロダクトはすぐに修正できません。リリースのタイミングがなかったり、なんらかの緩和策でやっているから、今は修正しなくていいという状況がどうしても発生します。

そうすると、すぐに修正できないのか、それともしないのか。しないにしてもいつまで待っていればいいのかを、組織ごとに管理することが必要になってくるのではないかと思います。

アップデートできないのに、「今はまだ脆弱性があります」という警告だけずっと出ているとなると、本来見るべき脆弱性の情報がノイズになるので、そういったものをなるべく出さないようにして、対応するべきものだけをわかりやすくしていく必要があるのではないかと考えています。

2点目が、脆弱性がどうなっているかを組織全体で管理したいということです。出てくる脆弱性はプロダクトごとに変わってくるので、組織全体ではどういう脆弱性を抱えているのかの問題であったり、新しく検出された脆弱性で、例えば新しく使い始めたパッケージに脆弱性があったというパターンもあるので、そういったものがどこまできちんと管理されているかの全体を把握していくのも、組織の統制という観点からは必要かと思います。

あとは、独自の脆弱性ごとにも評価をしていく必要があると思っています。CVSS（Common Vulnerability Scoring System）など、共通の企画で「この脆弱性はだいたいHigh severityです」とか、「この脆弱性はだいたいミドルです」ということがあります。

共通の公式によって求められた深刻度になるので、やはり組織ごとの事情に応じて「これは深刻だ」とか「これは別にそうでもない」というのは、ブレがけっこう大きくなってきます。そのため、そういったブレに対して、外部の評価を過度に考慮するだけではなく、なるべく自分たちで判断した内容を管理する必要があるのではないかと考えています。

この2つに関しては、既存の製品でカバーされているところが多いかと思っていて、そういったものを使っていく選択肢もありました。

しかし、3つ目の判定やCIの結果をなるべくカスタマイズしたいということは、けっこう難しいところです。もちろん既存のツールでも、例えば「この脆弱性は無視します」とか、「このパッケージに関しては無視します」というような、単純な1項目ごとの条件の判定ができるツールはけっこう多いです。

複数の条件を組み合わせて例外を発生させたり、あるいはリポジトリに合わせた対応、例えば外部に公開しているプロダクトであれば即座にやらなければいけないものの、外部のネットワークから切り離されて使っているプロダクトであれば、それほど猛ダッシュでやる必要はなかったりするということです。

そういった脆弱性の条件に関してもいろいろあるので、プロダクトの文脈をきちんと判断した上で、「これはすぐにやるべきだ」とか、「これはちょっと待ってもいい」という判断をする必要があると思っています。

こういうものをルールとしてきちんと記述できていないといけないのですが、先ほど少し言ったとおり、すごく細かい単一の条件を指定できるツールはたくさんありますが、全体的に自由に表現できるツールがなかなかなかったので、そこを含めてやるとなると、自分たちで用意したほうがよいということでやったのが今回の話です。

（次回に続く）