はじめに
アクセンチュア株式会社 テクノロジー コンサルティング本部の銭谷（ぜにや）と申します。
私の所属するチームは「インテリジェント クラウド イネーブラー グループ クラウド検証開発チーム」といって、Terraformを使った社内向けIaCテンプレートの開発や、AWSをはじめとしたクラウド技術の検証を担当しています。こちらのブログではアクセンチュアで働くエンジニアの業務の一例をご紹介いたします。
この記事では以下の内容について記述します。
- tfsecでやっていたこと
- なぜTrivyに移行したのか
- Trivyとは？（簡単な使い方つき）
- 検証内容と移行の判断ポイント
- おわりに
最初に結論
私たちは以下2点の理由によりtfsecからTrivy（トリビー）に移行しました。いずれも私たちのチームのユースケースに照らした検証の結果です。
- 検知性能に差異がない
- 使いやすさの面ではTrivyの方が優れている
・参照先モジュールの中身もスキャンしてくれる
・空ディレクトリがあっても再帰的にスキャンしてくれる
tfsecでやっていたこと
リリース前のセキュリティスキャン
私たちの業務の1つに、社内向けIaCテンプレートの開発とメンテナンスがあります。これはTerraformで作成したAWSインフラのテンプレートになっており、AWS利用上のベストプラクティスを反映したリソースを機能ブロックごとに簡単に再利用できるようにしたものです。随時機能拡張を行っており、リリース前には必ずtflintとtfsecを使った静的なスキャンを行って、検知項目に基づいた処置を済ませてからリリースしています。tfsecはこの運用の重要な部分を占めていました。
（他にも、実際にAWS上にリソースを作成してAWS InspectorやAWS Config、AWS Security Hubの検知項目を確認して処置を行ったりもしているのですが、ここでは割愛します）
Terraformとは？
IaC（Infrastructure as Code）ツールの代表格の1つで、従来は管理画面から手作業で構築していたクラウドサーバやネットワークを、プログラムのようにソースコードを書くことで構築することができるツールです。インフラ環境をソースコードとして管理できるので「プログラムのソースコードと同じ方法でバージョン管理できる」「再利用しやすい」といったメリットがあります。
tfsecとは？
Terraformのコードに対してセキュリティスキャンを行うためのツールです。OSSとして開発されており、Web上でも使い方などの情報が豊富に見つかるため、利用しやすいツールです。
なぜTrivyに移行したのか
tfsecの現状
tfsecはGitHub上のリポジトリも残っていてソフトウェア自体も利用可能な状態ですが、Terraformの最新機能に追従できていません。例えばTerraformでは1.5.0でCheck blockという機能が追加され、変数の値が想定を外れている場合に警告を表示することができるようになったのですが、このCheck blockを使用しているとtfsecでスキャンした際にエラーで停止してしまいます。このことはGitHub上でもissueとして上がっていたのですが「Trivyでサポート済み」として、改善されないままCloseされてしまいました。
実はtfsecは2023年2月にAqua Security社に買収されており、Trivyファミリに組み込まれることが発表されています。
全くの私見ですが、買収関連の事情が前述のTerraformの最新機能に追従できていなかった原因の一つなのかも、と考えています（GitHub上の議論を追っていけばわかるのかもしれませんが……）。
そして2023年8月31日、ついにリポジトリ内のREADME.mdの冒頭に「tfsec to Trivy Migration」という移行を促すアナウンスが追加されました。これを受けて、チーム内でもTrivyへの移行に向けた検証を開始することが決まりました。
Trivyとは？
OSSのセキュリティスキャンツール
Trivyとは、Aqua Security社が開発しているOSSで、様々な環境の脆弱性スキャンを行うことができます。読み方は「トリビー」です。前述の経緯から（少なくともAWSを対象とした）Terraformコードにも対応したほか、Dockerfileなどもスキャン可能なので、All-In-Oneのスキャンツールとして期待を持ちました。
開発ペースも落ちていないため、TerraformのCheck blockのような新機能にもしっかり追従できているのも評価ポイントです。
簡単な使い方
AWS Cloud9などのLinux系環境を対象にしています。
コマンド実行例
#インストール
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sudo sh -s -- -b /usr/local/bin
#インストール成功確認
trivy --version
#スキャン（ディレクトリの中身を再帰的にスキャンしてくれます）
cd [開発ディレクトリ等]
trivy config [スキャンするディレクトリ名]
検知結果の例
検証内容と移行の判断ポイント
移行ガイドの確認
評価検証の前にtfsecのリポジトリにあった移行ガイドに目を通しました。Trivyの使い方がtfsecとの比較でコンパクトに記述されています。特にtfsecとの違いはなさそうなので安心して検証に臨めそうです。
https://github.com/aquasecurity/tfsec/blob/master/tfsec-to-trivy-migration-guide.md
同一ディレクトリに対する検知結果の比較
評価検証は「Trivyがtfsecと同じ項目を検知できるか」という観点で行いました。具体的には、様々なAWSリソースを含むTerraformコード群を1つピックアップし、tfsecとTrivyでそれぞれスキャンし、結果を比較しました。Trivyがtfsecと同じ項目を検知できていれば移行可能、という判断基準です。
検知結果にほぼ差異無し。Trivyはその他機能で優れている
検証結果は以下の表のとおりとなりました。検証に使用したのはtfsec v1.28.1、Trivy v0.44.1です。差異があった部分を太文字で表記しています。
| No. | 説明 | tfsec | Trivy | 差異 |
|---|---|---|---|---|
| 1 | Listener for application load balancer does not use HTTPS | CRITICAL | CRITICAL | - |
| 2 | Security group rule allows ingress from public internet | CRITICAL | CRITICAL | - |
| 3 | Security group rule allows egress to multiple public internet addresses | CRITICAL | CRITICAL | - |
| 4 | Load balancer is exposed publicly | HIGH | HIGH | - |
| 5 | IAM policy document uses sensitive action 'ecr:CreateRepository' on wildcarded resource '*' | HIGH | HIGH | - |
| 6 | IAM policy document uses sensitive action 's3:AbortMultipartUpload' on wildcarded resource 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' (2 similar results) | HIGH(2件) | HIGH(1件) | ※1 |
| 7 | Bucket does not have encryption enabled | HIGH | × | ※2 |
| 8 | Bucket does not encrypt data with a customer managed key | HIGH | × | ※2 |
| 9 | Bucket does not have logging enabled (2 similar results) | MEDIUM(2件) | MEDIUM(2件) | - |
| 10 | Bucket has logging disabled (2 results) | × | LOW(2件) | ※3 |
ご覧いただいた通り、tfsecとTrivyでは検知結果にほぼ差異がありません（スペースの都合上LOWで差異がなかったものは割愛しています）。しいて挙げれば以下の3点ですが、いずれも運用上の問題とはならず、むしろ好ましいと言えます。
（※1）
No.6 IAM policy document uses sensitive action 's3:AbortMultipartUpload'
tfsecでは重複して2件検知されていますが、Trivyでは1件のみとなっています。
（※2）
No.7 Bucket does not have encryption enabled
No.8 Bucket does not encrypt data with a customer managed key
Trivyは参照先モジュールもスキャンした上で検知対象か判定しています（tfsecは参照先モジュールを見ていないのでHIGHと判定しています）。
なお、参照先モジュールでS3バケットの暗号化を行っている部分をコメントアウトするとTrivyでも検知されるので、この点も参照先モジュールをしっかり見ていることの証といえます。
（※3）
No.10 Bucket has logging disabled
Trivyではtfsecが検知していない箇所を検知できています。
（No.9で検知している項目と重複している気もしますが……）
特に2の挙動は私たちにとって嬉しい誤算でした。tfsecではモジュール参照に起因する検出結果が地味に多く、対応要否の振り分けに手間がかかっていたので、その辺の運用がかなり楽になりそうだからです。
最後に、参考としてtfsecとTrivyの検知結果の画面ショットを掲載します。細かい部分では違いがあるものの、主要な項目は共通していることがおわかりいただけるかと思います。
tfsec
Trivy（再掲）
Trivyは再帰的スキャンの挙動も理想的
検証していて気づいたのは、Trivyは階層の深いディレクトリに対してもしっかり再帰的にスキャンしてくれるという点です。tfsecは（私たちのチームで使用していた範囲では）ファイルのないディレクトリが2階層続くと再帰的スキャンを中断してしまうため、ディレクトリ構造の深い、規模が大きめのソースコードをスキャンする際に使いづらさがありました。これは嬉しい進化です。
検知除外の運用が楽になりそう
これはtfsecとの比較ではないのですが、Trivyにも検知除外の方法がいくつか用意されていて、期待を持っています。除外したいブロックの手前に所定の書式でコメントを記載する、あるいは除外したいルール番号をスキャン対象ファイル名ごとに記述したYAMLファイルを用意する方法などがあるようです。特にYAMLファイルは管理の負担も減らせそうで、チーム内で運用に組み込む検討を進めています（従来は対処不要の検知項目をExcel管理して目視照合！という超アナログ手法でした）。
おわりに
少なくとも私たちのチームではTrivyへの移行に支障がなく、むしろメリットの方が大きいと判断しました。今後はTrivyのテンプレート機能を使った出力整形などを試しつつ、チーム内のCI/CDパイプラインへの組込みを検討していこうと考えています。
本記事がセキュリティ静的解析ツールの導入を検討されている方のお役に立てれば幸いです。
以上、アクセンチュアの銭谷がお届けしました。
アクセンチュア株式会社ではエンジニア職の積極採用を行っています。私たちと一緒に働きませんか？
アクセンチュア株式会社所属の社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion