いつの間にかLinuxのDocker cliで脆弱性診断できるようになってたようです。
matsuand.github.io
DevOps、マイクロサービス、ノーコードなど、コンテナがインフラとして採用されるケースが増えてきましたが、それに伴ってコンテナの脆弱性診断も重要になってきました。特に、適当にDevOpsを構築すると脆弱性ソフトウェア製造工場になってしまいます。
ということで、今回は、コンテナスキャンの種類を整理したうえで、コンテナイメージスキャナのTrivyとDocker scanコマンドを紹介します。
スキャンの種類
コンテナのスキャンは静的診断と動的診断に大別され、その中で脆弱性診断やコンプライアンスチェックに分類されます。
静的スキャン
アプリケーションコード
C、PHP、Javaなど、開発者が自由にコーディングするソースコードの診断です。
つまりセキュアコーディングが実施できているかの確認になります。
この診断はコンテナであろうとなかろうと大きな違いはありません。
Fortifyあたりが有名かと思います。
Dockerfile
Dockerfileはコンテナイメージの設計図となるため、コンテナベースの開発を実施する場合、セキュリティを考慮する必要があります。
具体的には、Dockerfileのベストプラクティスが該当します。これをスキャンする有名なツールにはhadolintがあります。
コンテナイメージ
コンテナイメージにはOSのカーネル以外の部分(コマンド類、共有ライブラリ)やアプリケーションがファイルバンドルとして格納されています。ルートファイルシステム全般の情報が含まれているため、理論上は、OSからアプリケーションまで脆弱性診断を実施できます。ただし、多くのスキャナは、パッケージマネージャから抽出した依存パッケージと脆弱性データベースを照合するため、完全なものは存在しません。特に、開発者側のコーディングに依存するアプリケーションレイヤはほとんどスキャンできません。逆に、OS側の脆弱性診断は得意といえます。
また、アプリケーションレイヤとOSの中間に位置するのが、アプリケーションの依存パッケージになります。CやGoといったコンパイル言語であれば.so形式の共有ライブラリ、PythonやRubyのようなスクリプト言語であれば、スクリプト実装となる場合もあります。特に、スキャナの性能に差が出るのがこの依存ライブラリになります。yumやaptなどOS直上で動作するパッケージマネージャであれば、比較的実装は容易ですが、gem、pipのような言語パッケージマネージャへの対応は個別実装が必要になります。OSSにおいては、上記の点でTrivyが優れているといわれています。
また、コンプライアンスチェックも必要になります。コンプライアンスチェックは主に設定ミスに起因する脆弱性を判定する診断になります。前述した脆弱性診断は、存在自体が害悪でソースコードレベルで修正される脆弱性となります。一方、コンプライアンスチェックで主に対象となるのは、利便性等の理由から修正されずに利用者の設定に委ねられている部分になります。コンテナ固有ではありませんがファイルパーミッションの設定はこちらに該当します。chmodは便利ですが777を設定してしまうとまずいですよね。自動車が危険だから乗るのをやめる、とはならないのと同じで、適切な設定でリスクを管理する要塞化も必要となります。コンテナではNIST SP 800 190やCIS Docker Benchmarkあたりが該当しますが、dockleやdocker benchなどのツールでスキャンが実施できます。
動的診断
動的診断には、ネットワーク経由のレスポンス方式やOS上で動作させて設定ファイルなどを参照するダイレクト方式があります。また、診断時に対象システムの設定を変更する破壊検査と変更しない非破壊検査があります。破壊検査は、Metasploitや人手のペネトレーションテストが該当しますが、環境が変更されてしまうため、場合によっては実施しないケースもあります。一方、非破壊検査は、精度自体は破壊検査に劣るものの、手軽に実施できるという利点があります。
さらに、診断レイヤによってアプリケーションスキャンやプラットフォームスキャンといった分類がされるケースもあります。
アプリケーション
WAFで対象とされるようなインジェクション攻撃などが主な対象になります。実際に動作させているため、ソースコード診断で検出できなかった脆弱性が見つかることもあるため、静的診断と合わせた実施が必要です。レスポンス方式であれば、ホストOSとコンテナのポートをフォワーディングして実施することになるかと思います。
ツールとしてはOWASP ZAPやAppscanが有名です。
プラットフォーム
プラットフォーム診断は、レスポンス方式とダイレクト方式の両方が実施されます。ツールとしては、openscapやvulsが対応しているようです。
TrivyとDocker scan
コンテナイメージの静的診断については前述したとおりですが、今回は、dvwaという脆弱なwebサーバコンテナを検体として上記2ツールを動かしてみます。
いずれもスタンドアロンで動作するため、CICDとの相性が良く有望視されています。
ちなみにTrivyはaqua securityというコンテナセキュリティのトップベンダがバックについていて、Kubernetesとの統合も視野に入れるなど、イケイケドンドンなOSSになります。Docker scanはsnykというSaaSスキャナをベースにしているようです。こっちは正直よくわかんないです。
まずはTrivy。1600項目出力されていますね。さすがdvwa
次にDocker scan。930項目出力されていて、Trivyよりは少ないですね。
もし誤検知に差がなければ、Trivyの方が精度がよいのかもしれません。
一方、Docker scanはパッケージの依存関係も出力することができ、脆弱性のある箇所を把握しやすいメリットがありそうです。
コンテナイメージはレイヤ構造をとっているため、どのイメージレイヤに脆弱性があるかも重要になります。
このイメージレイヤの情報を出力する機能もDocker inspectとして備わっているため、脆弱性対応の作業をDockerのみで行えるのは大きな魅力かもしれません。大雑把に動かした限り、Trivyに大きく見劣りするわけではなさそうなので今後に期待です。Trivyも統合してええんやぞ?(願望)
ゼウスのごとく万能なツールがないのが悩ましいところですが、動向を確認しながらうまく付き合っていくことになりそうです。containerdの猛追によりDockerの優位性が失われつつありましたが、こちらもDockerの差別化になりそうです。
