Dockerイメージとコード依存関係のためのセキュリティスキャン基盤

F5エコシステム | 2020年9月21日

今年初め、私たちのチームは、PCI-DSSおよびSOC 2への準拠に向けて、既存のセキュリティツールとソフトウェアの開発・テスト手法を強化するよう求められました。特に強化が必要だった領域の1つが、K8sベースのマイクロサービスといくつかのモノリシックサービスに対する脆弱性スキャンです。そのため、DevOpsチームは、ソフトウェアの脆弱性スキャンを実装するために、複数の商用ツールとオープンソースソリューションから選定する必要がありました。これらのツールの機能は非常によく似ています。依存関係（プロジェクトライブラリまたはOSパッケージ）をスキャンし、NISTのNVDなどの脆弱性データベースと照合します。

自社開発か、購入か？

いくつかのオープンソースツールを使用して独自の脆弱性スキャンソリューションを構築することも、基本的なスキャンに加えて運用を容易にする追加機能を備えた商用製品を使用することもできます。たとえば、次のようなものがあります。

プロジェクト内の脆弱性をすばやく把握できる、見やすいダッシュボード
通知（メール、Slackなど）
Gitリポジトリ（GitHub、GitLab）との連携
他のサービス（Dockerレジストリ、Kubernetes）との連携
プロジェクト管理ツール（Jiraなど）との連携
脆弱性のある依存関係を修正するためのマージリクエストの自動作成
チーム、プロジェクト、RBACのサポート

ほとんどの商用ソリューションは、公開されている脆弱性データベースを独自の脆弱性データベースで補完し、誤検知や見逃しをなくして、より関連性の高い結果を提供します。ただし、こうした商用ツールはいずれも、開発者数が増えるにつれて非常に高額になります。そのため、購入するのか、既存のオープンソースツールを使用して独自のソリューションを構築するのか、どちらが自社にとって「より良い」選択肢かを検討する必要があります。

当初は、時間的な制約を考慮し、市販ツールがニーズに最も適していると判断しました。しかし、業界をリードする市販製品の導入とテストに3か月を費やした結果、golangのサポートが限定的であること、誤った依存関係を選択して正常に終了しないこと、ゼロからビルドしたコンテナとベースイメージを使用してビルドしたコンテナで問題が生じることなど、多くの課題に直面しました。そのため、この製品の使用を断念し、利用可能なオープンソース技術を活用して独自のツールを構築する方針に切り替えました。

この記事では、オープンソースを選択する場合に役立つ、確かな出発点をご紹介します。また、記事の最後には、すぐに始められるよう、F5のオープンソースリポジトリへのリンクも掲載しています。

何をスキャンするか

脆弱性スキャンの対象は、基本的に次の2つです。

プロジェクトのコード依存関係（yarn.lock、Gopkg.lockなど）
Dockerイメージ内のOS依存関係（Debianパッケージ、Alpineパッケージなど）

将来的には、ライセンスチェックや静的コード解析などの機能を追加することも可能ですが、これらは本記事の対象外です。

スキャンのタイミング

まず、コードやDockerイメージの変更によって新たな脆弱性が持ち込まれないようにする必要があります。そのため、すべてのマージリクエストをマージ前にスキャンすることを推奨します。

ただし、時間の経過とともに新たな脆弱性が現れる可能性があるため、定期的なスキャンも必要です。また、深刻度が変わることもあります。当初は無視していた深刻度の低い脆弱性でも、新たな攻撃ベクトルやエクスプロイトが見つかると、時間の経過とともに重大な脆弱性になる可能性があります。商用ツールは前回のスキャン結果を記憶し、新たな脆弱性が見つかると通知しますが、このオープンソースソリューションでは、プロジェクトのmasterブランチに対してスキャンを繰り返すだけです。

ツールの選択

利用可能なオープンソースツールは数多くありますが、使いやすく、活発に開発されており、複数のプロジェクトやOSの種類をスキャンできることから、Trivyを選びました。

Trivyは、コンテナやその他のアーティファクトに対応する、シンプルで包括的な脆弱性スキャナーです。ソフトウェアの脆弱性とは、ソフトウェアやオペレーティングシステムに存在する不具合、欠陥、弱点を指します。Trivyは、OSパッケージ（Alpine、RHEL、CentOSなど）とアプリケーションの依存関係（Bundler、Composer、npm、yarnなど）の脆弱性を検出します。使い方は簡単です。バイナリをインストールすれば、すぐにスキャンを開始できます。スキャンするには、コンテナのイメージ名などの対象を指定するだけです。

簡単にインストールでき、ビルド済みのDockerイメージまたはプロジェクトのルートを対象にローカルで実行できます。また、JSON形式や表形式など、複数の出力形式にも対応しています。

残念ながら、Trivyではスキャンできないプロジェクト（Golangなど）があり、コードの多くがGolangで記述されているため、OWASP Dependency-Checkに頼らざるを得ませんでした。

Dependency-Checkは、プロジェクトの依存関係に含まれる公開済みの脆弱性の検出を試みるソフトウェア構成分析（SCA）ツールです。特定の依存関係にCommon Platform Enumeration（CPE）識別子が存在するかどうかを確認します。存在する場合は、関連するCVEエントリへのリンクを含むレポートを生成します。

レポートを含むHTMLページ、JUnit形式およびJSON形式の出力（ほかにもいくつかの形式）を生成できます。

レポートとダッシュボード

いよいよ、さらに興味深い内容に近づいてきました😊

DevOpsチームとSREチームではすでにElasticsearch + Kibana + Fluentdを使用していたため、既存のインフラストラクチャを活用してセキュリティスキャンのJSON出力を分析するのは自然な選択でした。

必要だったのは、信頼できないインフラストラクチャ（CIランナー）からセキュアなElasticsearchへデータを送信する方法を見つけることだけでした。そのため、中間にメッセージキューを配置することにしました。FluentdにはAmazon SQSからメッセージを読み取るin_sqsプラグインがあり、使い方も簡単です。最終的なアーキテクチャは次のようになりました。

セキュリティスキャンのアーキテクチャ

データがElasticsearchに取り込まれた後は、Kibanaでダッシュボードをいくつか簡単に作成できます。また、Discoverを使用して脆弱性を照会し、必要に応じて詳細情報を確認することもできます。

脆弱性の概要

重大な脆弱性の検索

脆弱性への対処

スキャンと便利なダッシュボードが用意できたところで、次はどうすればよいでしょうか。開発者がこれらのダッシュボードを定期的に確認するとは限りません。そこで、重大度が「高」以上で、修正方法が提供されている問題が見つかった場合はCIを失敗させることにしました。これにより、対応の責任を開発者とプロジェクトオーナーに移します。

当然ながら、一部のCVEを許可リストに登録したり、プロジェクトごとにこのデフォルト動作を上書きしたりできるようにする必要がありました。そこで、セキュリティスキャンプロファイルを格納するリポジトリを作成しました。これらのプロファイルは、Trivyの実行をラップし、その動作と出力を処理するスキャンツールによって使用されます。

これにより、どの開発者でもこのリポジトリに対してマージリクエストを送信し、例外を申請できます。kibanaプロジェクトのプロファイル例：