Docker Hubのコンテナイメージ、51％以上に脆弱性が混入
よりスケーラブルで柔軟性の高いアプリケーションを構築、提供する手段として注目されるクラウドネイティブ技術。中でもコンテナの活用はここ数年で急激に広がっており、調査会社IDC Japanが発行する調査報告書「2021年 国内クラウドネイティブ技術ユーザー動向調査」では、コンテナを導入検討中や検証中、すでに導入済みと回答した組織が2016年には25％だったのが、2021年には56.6％に上昇したとしている。
コンテナ活用が広がる背景には、モノリシックなアプリケーション開発からマイクロサービスの開発へとシフトが進んでいるからだと、日本シノプシス、ソフトウェア インテグリティ グループ、シニア・プロダクトマーケティング・マネージャの松岡正人氏は指摘する。「コンテナはホストに依存せず、機能の追加や改善も速やかに実施でき、バージョン管理や追跡もしやすく、何よりDevOps環境との親和性が高い」（松岡氏）
その一方で、コンテナには固有のセキュリティリスクが存在する。一例として、コンテナイメージの取り扱いが挙げられる。より効率的にサービスを開発する目的で、Docker Hubにアップロードされているコンテナイメージを活用することは一般的だが、このコンテナイメージに不正なアプリケーションやライブラリなどが埋め込まれていることに気付かず、自社環境へデプロイしてしまった場合、システム侵害や悪用を許してしまう可能性がある。
2020年12月にサイバーセキュリティ企業Prevasioが報告したところによると、Docker Hubにアップロードされた約400万のコンテナイメージを調査した結果、51％以上に悪用可能な脆弱性が発見され、6400以上のコンテナイメージからマルウェアが検出されたという。
コンテナイメージ悪用の可能性については、多くの研究者がすでに指摘している。ある論文では、既知の脆弱性を仕込んだイメージをDocker Hubにアップロードし、ユーザーがそのイメージを自社環境などで起動すると、privilegedオプションでホストへのアクセスを許可する攻撃手法について言及されている。
もちろん、Docker Hubでもこうしたリスクを重視し、脆弱性スキャンオプションを追加。サードパーティのスキャンツールも登場している。「コンテナのセキュリティリスクは、ほかにも色々ある。コンテナの構造や流通の仕組み、運用上の取り扱い方法をきちんと把握し、適切なセキュリティ対策を講じることは重要だ」（松岡氏）
対策のひとつに挙げられるのは、ソフトウェア開発ライフサイクルの各ステップにセキュリティテストを組み込む方法だ。たとえば、コンテナの設計・計画段階ではどのような脅威が存在するのか整理し、リスクを分析。コード開発段階ではコードの静的解析やソフトウェアコンポジション解析で脆弱性を網羅的に洗い出し、イメージをビルドしたあとは脆弱性スキャンやファジング、IAST（インタラクティブアプリケーションセキュリティテスト）やDAST（動的アプリケーションセキュリティテスト）などを実行。コンテナをプッシュしたあとの運用段階でもコンテナの随時スキャンを実施するほか、IAST/DAST、ペネトレーションテスト、ファジングを定期的に実施。不正な変更が行われていないかを確認する。
コンテナ環境をセキュアに運用するためのガイドラインは、米国のNISTが公開している「SP800-190 Application Container Security Guide」を参考にするとよいと松岡氏は言う。
たとえば、同ガイドラインにはセキュアなコンテナ環境を構築、運用するためのポイントを6つ紹介している。
- コンテナの開発、実行、サポートなど運用および技術的プロセスは従来のモノリシックなアプリケーションのそれと異なることを理解した上で、新しい手段を後押しするために調整する
- アタックサーフェスを減らすために、汎用ホストではなくてコンテナ専用ホストを使う
- 単一のホストカーネル上で、同じ目的、機微性、および脅威に対する耐性を持つグループコンテナのみを使用し、さらなる多層防御を可能にする
- コンテナ専用の脆弱性管理ツールとイメージのプロセスを採用し、侵害を防ぐ
- トラステッド・コンピューティングの基板を提供するために、ハードウェアによる対策を検討する
- コンテナに対応したランタイム防御ツールを使用する
詳細は、IPA（情報処理推進機構）の翻訳版で確認できる。
脆弱性は技術的負債、開発プロセス全体で適切なセキュリティ施策を
さらに松岡氏は、コンテナ内のアプリケーションについても、CI/CDパイプラインにセキュリティテストを組み込むなど、開発プロセス全体でセキュリティ施策を展開するべきと言及する。
日本シノプシスが毎年公開する「オープンソース・セキュリティ＆リスク分析レポート」（2021年版）によると、17業種、1546の商用コードベースを監査した結果、全体の85％に4年以上前の古いオープンソース依存ファイルが含まれており、84％から1つ以上の脆弱性が発見されたという。これら脆弱性が悪用されて情報漏えいに至った場合、対応などを含めて発生する費用総額の平均は386万ドルに及ぶという試算もある（IBM Securityおよび調査会社Ponemonの「Cost of Data Breach Report 2020」より）。
脆弱性は、いわば技術的負債だ。米テキサス大学のハーブ・クラスナー教授がまとめた調査レポート「CPSQ」（Cost of Poor Software Quality）の2020年版では、低品質なソフトウェアに内在する技術的負債に起因するコストは約1.31兆ドルで、増加傾向にあると指摘されている。アクセンチュアが2019年に実施した年次調査レポート「Cost of Cybercrime Study」では、技術的負債となるLOC（コード行数）はグローバルで1兆6550億コードに上り、約1.3兆ドルのコスト負担に換算できるという。
「セキュリティは、ソフトウェア開発ライフサイクル全体に関わる課題だ。CI/CDパイプラインにセキュリティテストを含めることで、コード開発の早い段階から脆弱性を見つけて対処できる」（松岡氏）
こうして見ると、コンテナはモノリシックなアプリケーションと異なる環境で動作するが、セキュアに保つためのテストや技術はアプリケーションで実施してきたものが基本的にそのまま使える。ポイントは、プロセスの違いを理解し、どのプロセスで何を実施するかを整理し、適用することだと松岡氏は述べる。
「コンテナアプリケーション開発のベストプラクティスは、Dockerのサイトで公開されている。こうした情報を、セキュアな開発や運用のベースラインとして採用し、リスク軽減に取り組んでほしい」（松岡氏）
