Tanzu Application Platform (TAP) はリリースとともに最新の機能を順次リリースしています。このブログで紹介する新機能が Scan 2.0 です。TAP 1.5 から存在はしていたこの機能ですが、TAP 1.8 からは正式機能としてリリースされています。Scan 2.0 は旧来の Scan 1.0 の改善を試みたものであり、主に以下の機能を提供しています。
- Trivy をデフォルトの脆弱性スキャナとして採用
- カスタムの脆弱性スキャナの利用が容易に
- 継続スキャン機能の提供
執筆時点では、Scan 2.0 はオプトイン、つまりデフォルトではScan 1.0 が使われ、追加でインストールが必要です。設定自体は非常にシンプルでありTAP のインストールファイルである、tap-values.yaml に以下の記述を追加することで対応可能です。
ootb_supply_chain_testing_scanning:
image_scanner_template_name: image-vulnerability-scan-trivy
この記事では TAP の Scan 2.0 の機能を深掘りしながら紹介していきます。なお、SCAN 2.0 は本来は、TAP の Artifact Metadata Repository (AMR) も強く関連がありますが、これはまた別記事で取り上げたいと思います。
Trivy をデフォルトの脆弱性スキャナとして採用
TAP がリリースされた当初ではこの記事でも紹介しているようにスキャン機能には、Achore Grype が採用されていました。当時はまだ Software Bills of Materials (SBOM) *の考えが浸透していない中で、いち早く SBoM をベースとしたスキャン機能を実現するために採用がされました。時は経ち、多くの脆弱性スキャナーがこの SBoM の機能を搭載していくことになります。Scan 2.0 では採用するスキャナーの見直しが図られ、Trivy がベースとして採用されました。(なお、Anchore Grype も引き続き使用は可能ですが、今後は Trivy の利用が推奨されています。)
* SBoM 入門については、筆者が解説している動画を参照してください。
Trivy は Aquasecurity により OSS 化されている脆弱性スキャナです。Tanzu の他のプロダクトですと、Harbor などでも採用されており、知っている方も多いと思います。Trivy の脆弱性スキャンは以下の特徴をもっています。
- OS だけでなく、開発言語(Java, python, git など)の依存関係の脆弱性を検知 (データソースはこちら）
- 脆弱性データベースはインターネット非接続環境でもダウンロードが可能なフォーマットを採用
- SBoM 機能に対応
- （TAPでは利用されていないですが）構成ファイルの間違えなどの検知も可能
- 主要な開発者が日本人
インストール後、TAP GUI などワークロードビューに反映された、Trivyでの脆弱性検査機能が有効になります。
カスタムの脆弱性スキャナの利用が容易に
Scan 2.0 が開発された一つの目的が脆弱性スキャニングのツールを柔軟にカスタマイズするためでした。Scan 1.0 からもカスタマイズ方法は提供されていたものの、複雑な構成をとっていたためにカスタマイズを躊躇することが多かったです。Scan 2.0 ではこの仕様が見直されました。SCAN 2.0から以下の特徴をもったスキャナを登録することができます。
- Vulnerability Disclosure Report(VDR) を組み込んだ SBoM を生成できること
- 出力された SBoM が TAP がサポートするフォーマットおよびバージョンであること
ポイントが業界標準化された SBoM に対応した脆弱性スキャナであれば、対応が可能という点です。マニュアルにはすでにサンプルとして、Snyk, Prisima などと連携する方法が紹介されています。もちろん、これ以外のスキャナーを導入することも可能です。
例として、上の条件に当てはまるものが、OWASP DepScan です。OWASP DepScan は以下のコマンドで、VDR を含んだ SBoM を出力が行えます。SBoM のファイル名は sbom-universal.vdr.json です。
# depscan --src <検査対象ディレクトリ> --reports-dir <脆弱性保管ディレクトリ>これを TAP Scan 2.0 で表現したサンプルを Git のレポジトリに配置しています。ポイントは以下です。詳細はマニュアルを参照ください。
- 脆弱性スキャナを ImageVulnerabilityScan オブジェクトとして記載
- スキャンのプロセスを Step に記載
- (この例では) 最初のステップとして対象のコンテナのイメージをファイルシステムに展開（Vendir を利用）
- 次のステップでは、OWASP DepScan を使い、スキャンの実施
- 最後のステップで、レポート出力のデータベースの掃除を行い、必要なファイル名へ変換
本番利用を想定していませんが、もしこれを検証環境で試したい場合は、以下のコマンドで Yaml ファイルを適用してください。
# kubectl apply -f https://raw.githubusercontent.com/mhoshi-vm/tap-scan2.0-owasp-depscan/main/image-vulnerability-scan-depscan.yamlその後、tap-values.yaml をいかに更新してください。
ootb_supply_chain_testing_scanning:
image_scanner_template_name: image-vulnerability-scan-depscanそうすることで以下のように OWASP DepScan のスキャンレポートを TAP GUI に反映することが可能です。
カスタムスキャナも使えるようになったのも TAP Scan 2.0 の大きな特徴といえます。
継続スキャン機能の提供
これまで TAP 1.0 では、ビルドをトリガーにしないとスキャンがされないという問題がありました。当然リリース後も新しい脆弱性の報告は日々行われています。高頻度のビルドをしなくなったリリース後のスキャンで脆弱性がもれてしまう可能性があります。ただし、バランスを考慮しないといけないのが、スキャンにかかる負荷です。過去に OSS では、無作為に稼働中のすべてのコンテナをスキャンするようなものがありましたが、スキャン時の負荷が高くなりすぎてしまい、使いにくい問題に悩まされていました。
こういった、考慮点を含めて改善されたのが TAP 2.0 の継続スキャン(Recurring Scan)の機能です。
さきほどの OWASP DepScan のサンプルをおいたレポジトリに同じく継続スキャンのサンプルを配置しています。詳細はマニュアルを参照の上ですが、ポイントは以下です。
- Scan 2.0 のカスタムスキャナとほぼ同じ書式でスキャンのロジックを記載
- スキャン対象をしぼるために、コンテナが動いている期間 (ranWithinDays) や、ビルドされてからの期間 (createdWithinDays) を指定が可能
- Cronの書式にて起動時間を記載
同じく本番利用を想定していませんが、もしこれを検証環境で試したい場合は、以下のコマンドで Yaml ファイルを適用してください。
なお、<MY-REG/REPO> はスキャン結果を保管可能なコンテナレジストリに切り替えてください。
# export MY_REG_REPO=<MY-REPO/REG>
# git clone https://github.com/mhoshi-vm/tap-scan2.0-owasp-depscan
# cd tap-scan2.0-owasp-depscan
# sed -e "s@MY-REG/REPO@${MY_REG_REPO}@g" recurring-image-vulnerability-scan-depscan.yaml | kubectl apply -f-これを実行することで継続スキャンを設定することができます。
まとめ
この記事では、TAP 1.8 から正式にリリースされた Scan 2.0 を実例を交えながら紹介させていたただきました。VMware Blog ではさらに TAP の様々な機能を紹介していく予定です。
