KubeCon EU 2020から脆弱性スキャンのTrivyとOPAを紹介

クラウドネイティブなシステムに関するカンファレンスKubeCon/CloudNativeCon EU 2020は、オンラインイベントとして開催された。セッションは実に200以上も開催され、とても短時間ですべて視聴できるボリュームではないが、今回はその中からAqua SecurityのエンジニアによるOpen Policy Agentを組み込んだコンテナセキュリティのセッションを紹介する。

企業は脆弱性にどう向き合うべきか？

Teppei Fukuda氏によるセッション

動画へのリンク：Handling Container Vulnerabilities with Open Policy Agent - Teppei Fukuda, Aqua Security

これは「Handling Container Vulnerabilities with Open Policy Agent」と題した30分に及ぶセッションで、「脆弱性に対して企業はどう対処するべきか？」を解説するものだ。またオープンソースプロジェクトのルールエンジンであるOPA（Open Policy Agent）をインテグレーションしたデモを紹介し、脆弱性のスキャナーであるTrivyとの連携も解説した。ちなみにFukuda氏はTrivyの開発者であり、TrivyがAqua Securityに譲渡されたと同時にAqua Securityに移ったエンジニアである。

脆弱性は年々増加傾向にある

最初のスライドはここ数年の脆弱性の多さを紹介するものだが、この数の多さに驚くよりもそれらの脆弱性が自社のIT資産においてどれだけ関係しているのか？ つまりこれらの脆弱性が発見されたソフトウェアを、自社で実際に使っているのか？ これを検証するべきだと解説した。

2019年には一日に50件弱の脆弱性が発見された計算になる

つまりWindowsベースのシステムを使っていない、Kubernetesも使っていないという状況であれば、それらに関連する脆弱性は無視しても良いというわけだ。

自社のIT資産の棚卸しをすることで関連する脆弱性は少なくなる

また脆弱性のスキャンを行うツールも商用からオープンソースまで多く開発されており、コンテナベースのシステムであってもコンテナの中に含まれるライブラリーなどを含めて、検査を行うことができると解説した。

コンテナに対応したスキャナー

前述のとおり、ここで挙げられているTrivyは、Fukuda氏がメンテナーを務めるオープンソースのスキャナーで、Aqua Securityが中心となって開発を行っている。またClairはRed Hatが買収したCoreOSが、2015年に公開したスキャナーである。

脆弱性は軽微なものから深刻なものまで存在する

次に脆弱性の深刻度の分布を紹介する。このスライドは、すべての脆弱性が重要（深刻）というわけではなく、重要度には軽重があることを示している。これを理解するためには、脆弱性の度合を示すCVSSを理解しておくべきだろう。以下のIPAのホームページを参考にされたい。

参考：共通脆弱性評価システムCVSS概説

また同じ脆弱性であっても、ベンダーによってはその深刻度の評価は分かれることを紹介。ここではNISTのNVDとRed Hatでは値が異なることから、CVSS自体が絶対的なものではないことを解説した。ちなみにこのスライドに使われている脆弱性をSUSEのサイトで調べると6.5という数値になっているように、微妙に異なるのを確認できる。

同じCVEでもベンダーや組織によっては値が異なる

参考：CVE-2017-15896

そして脆弱性に対する対応を「ポリシー」として定義することで自動化することができることを紹介し、そのための指針となるCVSSのスコアだけではなく、「どのパッケージで発見されたのか」脆弱性の種別を定義するCWE（Common Weakness Enumeration）、脆弱性が利用される際の区分や複雑さなどを定義したCVSS Vectorなどを判定した上で、脆弱性に対する修正を行うべきというフローを紹介し、脆弱性を自社のIT資産に対して評価した上で対処するべきであると解説した。

Fukuda氏が提案した脆弱性評価のフロー

Open Policy Agent

ここから脆弱性をポリシーに応じて判定するソフトウェアであるOPA（Open Policy Agent）を紹介するセクションに入った。

OPAの紹介

OPAは2018年にSandboxプロジェクトとしてCNCFにホストされたソフトウェアである。外部からのリクエストを受けて、定義されたルール（ポリシー）に基づいてリクエストの可否を返すというシンプルな機能を備え、アプリケーションのライブラリーとしても常駐するデーモンとしても使えるのがポイントだ。ポリシーはRegoという言語を使って宣言的に記述する。

OPAは脆弱性スキャンニングと連携することで自動化が可能になる

ここでは最初の段階の47.4個（1日辺りの平均）ある脆弱性は、対象となるソフトウェアが自社の資産で使われているかどうかを判定し、その後にOPAによるルール判定を行うことで、対応が必要な脆弱性を減らせるということを示している。

前段の脆弱性スキャンにTrivyを使う

ここでは前段階のスキャンの部分にTrivyを使うことを提案している。TrivyはAqua Securityが開発を推進している脆弱性スキャンツールである。

Trivyの紹介

次のスライドは後半のデモで利用するポリシーのサンプルだが、これを見れば、パッケージの種類や重要性の低いものを無視するといった内容が簡易な表現で記述されていることがわかるだろう。デモの内容は、Trivyを使ってcentos:7（CentOS 7）に関する脆弱性をスキャンし、その結果をOPAのルールポリシーを使って可否を判定するというものだ。

OPAのポリシーのサンプル

実際にポリシーを使って判定することで、本当に対応が必要な脆弱性を洗い出すことができる。

ポリシー適用前と適用後の脆弱性の数の違いに注目

またKubernetes環境においても、Trivyを使ったスキャンニングを実装するための機能「Trivy Enforcer」も開発が進んでいることを紹介した。現在ではPoCの段階だそうだ。

Trivy Enforcerの紹介

カスタムコントローラーとして稼働するTrivy Enforcerを使うことで、実際にPodが起動する前に脆弱性のスキャンが行えるようになる。

Kubernetesの中で動くTrivy Enforcer

ローカルの開発環境からテスト環境、そしてKubernetesで実装された本番環境まで同じスキャンエンジン、ルールを提供することで、セキュリティを開発の段階から組み込む「シフトレフト」が行えるというのが、このセッションのメッセージだ。

開発からKubernetes環境までカバーするTrivy＋OPAのコンビネーション

最初はCLIを使って利用し、Kubernetes上ではOperatorを使って実装するというのもKubernetesの作法に従っている感じなのが、現代的と言えるだろう。

まとめのスライド

脆弱性チェックには商用ベンダーを始めとして多くの選択肢があるが、軽量なツールであるTrivyとOPAを用いて、まずは最初のパイプラインを作ってみるというのもアリだろう。今後は機会があれば、ユースケースなども紹介していきたい。