CNSC 2022からOSSの脆弱性スキャンツールであるTrivyの作者が語るTrivyの最新情報を紹介

CloudNative Security Conference 2022から、オープンソースのスキャンニングツールであるTrivyのセッションを紹介する。TrivyはTeppei Fukuda氏が個人で開発し公開していたオープンソースソフトウェアだが、2019年にAqua SecurityがFukuda氏を招聘することでAqua Securityのポートフォリオの一部となったツールである。セッションのタイトルは「Simplify Cloud Native Security with Trivy」、主に開発プロセスの前半、つまりコーディングからビルド、デプロイするところまでの行程でTrivyが果たす機能を、デモを交えて紹介している。

Trivyについてはオンラインのみで開催されたKubeCon/CloudNativeCon EU 2020でFukuda氏が行ったTrivyとOPAに関する解説を記事として公開しているので参考にして欲しい。

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

今回のセッションは、2年前と比較してTrivy自体にも大きな進化があったことがわかる内容となっている。

セッションを行うFukuda氏。現在はイスラエル在住

Fukuda氏はアプリケーション開発のライフサイクルをコード、ビルド、デプロイ、実行と4つのフェーズに分け、その上でアプリケーションとインフラストラクチャーに分けたマトリックスを使って説明を始めた。

ソフトウェアをアプリとインフラに分け、アプリの実行に至るまでの段階で分類

その上でスキャンニングというタスクについては、アプリケーションのコーディングからビルド、デプロイまでを成果物（Artifact）に対するスキャンニング、実行についてはランタイムプロテクションというカテゴリーを当て、インフラストラクチャーにおいてはクラウドの構成情報に対するスキャンニングというカテゴリーを想定していることを説明した。ここではCNAPPを新しいカテゴリーとして定義したガートナーのカテゴリーに沿って説明を行っている。

ここではCNAPPに沿ってカテゴリーを分類

CNAPPについても触れ、インフラストラクチャーからアプリケーションまで広くカバーする発想でセキュアなシステムを目指していることを説明した。

3つのカテゴリーには多くのOSSが存在するとして例を提示

この領域をカバーするソフトウェアはオープンソースにおいても多くの選択肢があり、商用ツールやサービスを加えればさらに多くなるとして、ここではごく一部だけを紹介している。

その上でアプリとインフラという分け方ではなくフェーズごとに分けてこれから説明を行うとして、コード、ビルド、デプロイ、実行にどのようなセキュリティ施策のカテゴリーがあるのかを示したのが、次のスライドだ。

4つのフェーズに存在するセキュリティ施策

左からソースコードを書いて、ビルドしてからイメージのスキャンニング、そしてクラウドプラットフォームにデプロイするための構成のチェックを経て実行されるというフェーズにそって説明。最後の実行フェーズでは実際にインシデントが起こってからの対応となるために、今回は最初の3つのフェーズに限定して説明を行っている。

Trivyの作者が、自身が開発しているソフトウェアを使ってどこまでできるのか、最新の機能は何かなどを説明するのは当然とは言え、Fukuda氏自身も「若干、マッチポンプですよね（笑）」とコメントしてここからはTrivyの機能をコーディング、ビルド、デプロイのフェーズに沿って説明を行った。

コードのフェーズからTrivyの機能を説明開始

まずはTrivyの概要として「スイスアーミーナイフ」と表現しているのは、とにかく使いやすいこと、使うための準備に手間がかからないことを目指したからだという。Trivyを作った契機として、既存の脆弱性スキャンを行うツールは余りに準備に手間と時間がかかったからだったと説明した。

脆弱性スキャンをコンテナイメージ、ファイルシステム、リポジトリー、Kubernetesに対して実施可能

脆弱性のスキャンについては、コンテナイメージ、ファイルシステム、リポジトリー、そしてKubernetesのクラスターで実行されているイメージについて行うことができると説明。

4つの対象に対して脆弱性チェックが可能

また構成情報のチェックについても同様に行えることを説明。ここでは簡単なデモを交えて説明を行った。

実際に変数などを使った構成情報の生成パターンについても対応可能

構成情報の中に外部向けのIPアドレスが何の制限もなく公開されているようなケースも検知可能として、AWSの例を使って説明を行った。

構成情報の中身についてもチェックを行っている

ここからは最新情報としてVS Codeのエクステンション、Azureの脆弱性スキャナーとして採用されたことなどを紹介した。

AzureのスキャナーとしてTrivyが採用されている

イメージなどにユーザーIDやパスワードがハードコードされていないかをチェックする機能はAWS、GCP、GitHubなどにおけるクレデンシャルの漏洩をチェックできると説明した。

シークレットのチェックも可能

特にコンテナイメージのようにベースのイメージからライブラリーなどが多層に積み重なっている場合、すべてにスキャンを行うと処理に時間がかかるため、ベースイメージを省いてスキャンするなどの工夫がなされていることを説明した。

ベースイメージを省いてスキャンすることで処理を高速化

またKubernetesのクラスターについては、クラスター配下のリソーススキャンのサマリーが出せること、ネームスペースやデプロイメントを選択してスキャンできることなどを説明した。

Kubernetesクラスターに対するスキャンの例

スキャンの結果を脆弱性、構成ミス、シークレットの3つのカテゴリーで表示

最近、何かと取り上げられるSBoM（Software Bill of Material）についてもスキャンした結果をSBoMの形式で出すことも可能だし、生成されたSBoMを入力としてスキャンを行うこともできるという使い勝手の良さを説明した。また単にCLIでコマンドとパラメーターを入力するだけではなく、規定値をYAMLで記述できるなどツールとして成熟具合を語った。

TrivyはSBoMにも対応

特にKubernetesにおいてはRed Hatが推進するOperator Frameworkにも対応することで、クラスターのライフサイクルに合わせて動的にリソースのスキャンが可能となることを説明した。

Trivy OperatorでKubernetesのライフサイクルにも対応

またModulesという実験的な機能として、WebAssemblyで書かれた外部コードによってスキャンニングの動作を変更できる拡張機能を公開している。複雑なスキャンニングが必要な例としてSpring Frameworkの脆弱性であるSpring4Shellを、このWASMのモジュールが検出するという例を挙げている。プラグインが外部の実行モジュールを呼ぶだけなのに比べて、より複雑なスキャンロジックを実装できというのがModulesの特徴だ。しかもそれをメモリーセーフなWebAssemblyで実装するというのが画期的と言える。

WebAssembly製のスキャンニング動作を変更できるModules

Modulesについては以下のドキュメントを参照されたい。

Modulesの公式ドキュメント：https://aquasecurity.github.io/trivy/dev/docs/advanced/modules/

実装例として挙げられているSprin4Shellについては、Aqua Securityのブログを参照されたい。

Aquaブログ：New Zero-day RCE Vulnerability Spring4Shell: What You Should Know

最後にソフトウェアサプライチェーンに関するガイドラインをCISと共同で作成したことを説明。

CISと共同でソフトウェアサプライチェーンに関するガイドを作成

Trivyがコーディング、ビルド、デプロイのフェーズにおいて脆弱性、構成ミス、クレデンシャル漏洩などを発見できることをまとめとして再度強調してセッションを終えた。

他の脆弱性スキャナーとしては、CoreOS由来で現在はRed Hatがコンテナレジストリーとして開発を進めるQuayの中で採用されているClairが今一つ伸び悩んでいるが、Trivyはますます発展を続けている。今後の動向に注目したい。

Trivy公式ページ：https://trivy.dev/