コンテナイメージを安全に保つ3つのステップ

Dockerを使ったコンテナイメージのセキュリティ

コンテナイメージの脆弱性をスキャンしたことがあれば、数件どころか、数百件、場合によっては数千件もの問題が見つかったことがあるでしょう。SnykとDockerが共同執筆したこのガイド開発チームのためのコンテナセキュリティでは、コンテナイメージとその中にパッケージ化されたソフトウェアに焦点を当てています。こちらから、コンテナセキュリティガイドのPDF版をダウンロードできます。

まず、コンテナセキュリティが重要な理由を見ていきます。コンテナの利用はますます広がっていますが、セキュリティリスクも伴い、生産性の低下、売上の減少、さらには数百万ドルの罰金といった損害を企業にもたらす可能性があります。この記事では、安全なコンテナイメージを作成するための3つのステップを紹介します。無料のSnykアカウントに登録すると、Dockerイメージやオープンソースライブラリの脆弱性を簡単に見つけて修正できます。

コンテナイメージのセキュリティを確保する3つのステップ

先ほど述べたように、コンテナイメージのセキュリティは単一の領域に限られた課題ではありません。開発、セキュリティ、運用の各チームにまたがります。コンテナには、次のような複数のセキュリティ上の懸念事項があります。

• コンテナイメージ自体と、その中のソフトウェア

• コンテナ、ホストOS、同じホスト上の他のコンテナ間の相互作用

• ホストOS自体

• コンテナのネットワークとストレージに関する懸念事項

• 多くの場合、Kubernetesクラスターでの実行時セキュリティ

これらの各項目について詳しく解説するには、それぞれ独自のガイドが必要です。最初の項目以外は、すでに1つ以上のガイドが用意されています。このガイドでは、コンテナイメージとその中にパッケージ化されたソフトウェアに焦点を当てます。

安全なコンテナイメージを作成するための主なステップは、大きく分けて3つあります。

1. コードと依存関係を安全に保つ

2. 信頼できるソースの最小限のベースイメージから始める

3. 開発ライフサイクルを通じて、イメージに追加するツールやパッケージを管理する

このアプローチで安全なコンテナイメージを作成する方法を、各ステップを詳しく見ながら確認しましょう。

1. コードと依存関係を安全に保つ

クラウドネイティブアプリケーションを迅速に提供することは、そもそもコンテナを作成する主な理由の一つでしょう。そして、アプリケーションは組織の生命線です。それほど遠くない昔、アプリケーションセキュリティはコードの保護に始まり、コードの保護に終わっていました。コンテナなどの最新の開発手法によって「アプリケーションコード」の意味は広がりましたが、この領域が依然として重要であることに変わりはありません。

幸いなことに、コンテナイメージの中で、開発者が直接管理しやすく、十分に理解できていると期待できるのがこの部分です。それでも、コードの依存関係をすべて把握し、セキュリティ上の問題をどう修正するかを判断するのは簡単ではありません。ソースコードにアクセスできる場合は、Snyk Open Sourceのような専用ツールを使ってソフトウェア構成分析（SCA）と静的アプリケーションセキュリティテスト（SAST）を実施し、コードとその依存関係を分析しましょう。最新のアプリケーションでは、サードパーティ製のオープンソース依存関係がコード行数の大半を占めることも珍しくありません。

図2：アプリ内のオープンソースコードの量は、プロプライエタリコードの量を容易に上回る可能性があります。

開発の早い段階で問題を発見し、セキュリティツールをソースコードに統合すれば、コンテナ化の工程とは切り離してこのプロセスを自動化できます。コンテナをスキャンして一部の種類のコードを分析することも可能ですが、Gitのコミット、パイプライン、リポジトリで直接問題を検出するほうが、開発者の作業プロセスに適しているでしょう。

2. 信頼できるソースの最小限のベースイメージから始める

イメージを小さくするメリットとは？

ベースイメージ（DockerfileのFROM行）は、セキュリティを考えるうえで最も重要な要素の一つです。幸い、多くの信頼できるベンダーが、簡単に利用できるコンテンツを提供しています。コンテナのベースイメージを入手する先として、Docker Hubが圧倒的に広く利用されています。

Docker Hubには、380万を超えるイメージと700万を超えるリポジトリがあります。非常に活発に利用されており、月間プル数は約110億回にのぼります。これらのイメージの一部はOfficial Imagesです。Dockerが厳選したDockerのオープンソースリポジトリや、そのまま使えるソリューションのリポジトリとして公開されています。

DockerはVerified Publishersが公開するイメージも提供しています。これらの高品質なイメージは、DockerがVerified Publisherとして認証した企業が直接公開・保守しています。認証済みパブリッシャー向けのDockerのガイドラインは、社内でコンテナイメージのベストプラクティスを定める際にも役立つ出発点です。

図3：Docker Hub上の公式イメージ。「Official」バッジと最近の更新に注目してください。

Docker Hubでユースケースに合う公開イメージを見つけるのは簡単ですが、選ぶイメージの出所には注意が必要です。信頼できないWebサイトからソフトウェアをダウンロードしてインストールしないのと同じように、誰が公開したのか分からず、信頼性を確認できないイメージをDocker Hubから使うのは避けたいでしょう。

Docker Officialプログラムのイメージを使うか、Notaryなどでデジタル署名を確認するなどして、サードパーティ製イメージの出所と内容を把握・検証すれば、一定の品質を保証できます。さらに脆弱性を減らし、コンテナに含まれる内容をより細かく管理するには、もう一歩進んで、用途に合った最小限のベースイメージを選びましょう。

例として、上の図3にはPythonのリポジトリが示されています。このイメージを使ってPythonアプリをビルドすれば、ほぼ確実に動作するでしょう。Docker Hubにあるこのイメージは、幅広いユースケースで使いやすいように設計され、適切に保守されているためです。ただし、このリポジトリには他にも1,000を超えるPythonイメージがあります。

覚えやすい名前の_pythonイメージをそのまま使うべきでしょうか？それとも、用途に合い、セキュリティ上の攻撃対象領域も減らせる、より小さなイメージがあるでしょうか？答えはお察しのとおり、セキュリティの観点からより適切な選択肢がほぼ間違いなく存在する、ということです。

コンテナイメージのサイズが重要なのは、持ち運びやすさやダウンロードの速さのためだけではありません。pythonというタグのイメージは、OSライブラリや開発用パッケージが多数あらかじめインストールされているため、簡単に使えます。そのため、幅広いプロジェクトで問題なく動作し、コードや依存関係のコンパイルに必要なものがそろっているでしょう。一方で、脆弱性スキャナーを使うと、対応が必要な問題が多数見つかる可能性があります。

図4：Python 3.x向けの、2つのDebianベースイメージの比較。

どちらのイメージにも脆弱性があり、とりわけ深刻度の高いものが含まれている点を気にするかもしれません。しかし、これらの脆弱性を詳しく見ると、いずれも基盤となるOSパッケージに関するものです。修正プログラムが提供されているものはなく、実際に悪用された事例も確認されていません。また、DockerのVerified Publisherプロセスの一環として、両方のイメージはここ数日以内にすべてのパッケージが最新バージョンに更新されており、適切に保守されています。

状況を考慮することも大切です。見つかる脆弱性は、本番用イメージから削除したい開発ツールに存在することがよくあります。たとえば、curl、開発用ライブラリ、シェルやパッケージマネージャーなどです。しかし時間が経つにつれて、スリムなイメージよりも大きなPythonイメージのほうが、新たに発見される脆弱性の影響を受ける可能性は高くなります。

コンテナイメージのセキュリティを実践する：ベースイメージの選定例

先ほど述べたように、「スリムなイメージから始める」というアドバイスは、どこでも耳にします。しかし、DockerとSnykが提携した理由の一つは、アドバイスを実際の行動につなげることです。Docker Desktopに統合された脆弱性スキャン機能を使えば、ベースイメージの選定作業の一部を自動化できます。

引き続きPythonを例に、Snykを活用したDockerの脆弱性スキャン機能を使って、Pythonイメージからpython:3-slim-busterイメージを選ぶ方法を見ていきます。必要に応じて、以下の手順を実際に試してみてください。

まずはシンプルな例として、pythonイメージを使い、とても簡単なコンテナイメージをビルドします。そのためのDockerfileは次のとおりです。

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

これ以上ないほどシンプルです。hello.pyファイルは、(“Hello, World!”)を出力するだけの簡単な1行のステートメントです。

次に、イメージをビルドしてスキャンを実行します。

$> docker build -t hello-python .

[+] Building 67.4s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.4s => => transferring dockerfile: 36B 0.1s => [internal] load .dockerignore 0.4s => => transferring context: 2B 0.1s => [internal] load metadata for docker.io/library/python:latest 1.6s => FROM [1/1] FROM docker.io/library/python 65.1s
...
=> exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:3a92e9... 0.0s => => naming to docker.io/library/hello-python 0.0s

$> docker run hello-python
Hello, World!

$> docker scan hello-python -f Dockerfile
/ Analyzing docker dependencies for hello-python/Dockerfile

Organization: snyk-pmm Package manager: deb
 Target file: Project name: Docker image: Base image:
Dockerfile docker-image|hello-python hello-python
python

Tested 431 dependencies for known issues, found 268 issues. Base Image Vulnerabilities Severity
python:latest 268 6 high, 34 medium, 228 low

Recommendations for base image upgrade:
Alternative image types
Vulnerabilities Severity
75 1 high, 10 medium, 64 low
Base Image
python:3-slim-buster
python:3.9-rc-slim-buster 75 1 high, 10 medium, 64 low

まず、結果にはイメージ内で431件の依存関係と268件の問題が見つかったと表示されています。簡潔にするため、個々の脆弱性はすべて省略しました。詳しくは後ほど説明します。ベースのpythonイメージに何も追加していないため、出力からも分かるように、268件の脆弱性はすべてベースイメージに由来します。

出力の最後には、セキュリティを強化するためのベースイメージの推奨候補が表示されます。具体的には、先ほど紹介したpython:3-slim-busterイメージです。実は、この推奨機能を使って、最初に比較したイメージを選びました。この新しいイメージを使えば、元のpythonイメージにあった脆弱性を70％以上削減し、深刻度の高い脆弱性を1件に減らせることが分かります。念のため、実際にもう一度ビルドしてスキャンしてみましょう。

DockerfileではFROM行を変更するだけです。Dockerfile.slimという名前で別のコピーを保存します。

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

次に、イメージを別々に管理できるよう、slimタグを付けて再度ビルドし、スキャンします。

```
$> docker build -t hello-python:slim . -f Dockerfile.slim

[+] Building 21.0s (8/8) FINISHED
=> [internal] load .dockerignore                                        0.1s
=> => transferring context: 2B                                          0.0s
=> [internal] load build definition from Dockerfile.slim                0.1s
=> => transferring dockerfile: 135B                                     0.0s
=> [internal] load metadata for docker.io/library/python:3-slim-buster  11.5s                                                                            
...
=> exporting to image                                                   0.0s                           
=> => exporting layers                                                  0.0s                            
=> => writing image sha256:63768699.                                    0.0s                                          
=> => naming to docker.io/library/hello-python:slim                     0.0s                                                         

$> docker run hello-python:slim
Hello, World!

$> docker scan hello-python:slim -f Dockerfile.slim

Package manager:  deb
Target file:      Dockerfile.slim
Project name:     docker-image hello-python
Docker image:     hello-python:slim
Base image:       python:3-slim-buster
Licenses:         enabled

Tested 94 dependencies for known issues, found 75 issues.

According to our scan, you are currently using the most secure version of the selected base image
```

今回は、完全なスキャン結果で依存関係が94件だけであり、深刻度の高い脆弱性も1件のみであることが分かります。このように、DockerとSnykはより安全なベースイメージ選びを支援します。Docker Hub上のすべてのイメージをカバーしているわけではありませんが、人気のある公式ベースイメージの大半をカバーしています。

3. ベースイメージとコードの間にあるすべてのレイヤーを管理する

ベースイメージには特別な考慮が必要なため、詳しく説明しました。独自のレイヤーをその上に重ねていくと、ベースイメージに含まれるものをすべて引き継ぐことになります。スリムなイメージを使えば、セキュリティ上の負担を軽減できることも少なくありません。では、コンテナに追加するレイヤーはどうでしょうか？スリムなイメージから始めた場合、ツールやライブラリ、コード、動作に必要なさまざまな要素を追加することになるでしょう。これらすべてについて、脆弱性を監視する必要があります。

幸い、最初のFROM行より後から、コードを実行するための設定を行うDockerfileの最後の行まで、これらの中間レイヤーはすべて自分で管理できます。具体的には、DockerfileのRUN、COPY、ADDコマンドに注目します。これらのコマンドでソフトウェアなどをインストールするためです。厳密には、コードがこれらの中間レイヤーに含まれる場合もありますが、考え方としてはコードを最終レイヤーと呼ぶことにします。主な理由は、ステップ1ですでにコードを扱ったからです。

図5：コンテナイメージの中間レイヤー

これらの中間レイヤーにある脆弱性を管理するうえで特に難しいのが、ライフサイクルの各段階で何に優先して対応するかを判断することです。

段階ごとに異なるツールが必要になることもありますが、イメージを本番環境に移す際には、アプリケーションの実行に不可欠なもの以外をすべて削除しましょう。最小限のベースイメージから始めて必要なツールを追加する形でイメージをカスタマイズしておけば、Dockerfileから不要なツールを削除して再ビルドするだけで、簡単に取り除けます。さらに、マルチステージビルドを使えば、すべての段階を単一の自動化されたビルドプロセスにまとめられます。

コンテナの脆弱性修正に優先順位を付ける

とはいえ、セキュリティ脆弱性は見つかるものであり、その対処方法を判断する必要があります。理論上、脆弱性ゼロは理想的ですが、現実には実現が難しく、費やす時間に見合わない場合もあります。

まずは、開発、テスト、本番という従来の作業段階に沿って、次のように進めることをおすすめします。ソフトウェアの本番環境へのリリースプロセスは、さらに複雑な場合もありますが、状況に応じて調整してください。

• 開発用イメージから始める
  開発用イメージは、ツールやサポートパッケージを最も多く必要とするため、中間レイヤーに含まれる脆弱性が最も多くなる傾向があります。ただし、段階的にイメージをビルドし、本番用イメージにこれらの追加要素を含めないのであれば、この段階の脆弱性の多くは無視しても問題ない可能性があります。その判断には、コンテナにインストールされた依存関係を追跡し、開発のイナーループに何が必要かという知識と照らし合わせる必要があります。あるライブラリが、別の依存関係のさらに依存関係としてインストールされ、その先の依存関係に脆弱性が含まれていることは珍しくありません。開発用パッケージを1つ削除するだけで脆弱性を解消できるかどうかを判断できる必要があります。
  
  

  次の例ではRubyアプリケーションを使っています。開発を簡単にするため、RubyにSQLiteをバンドルするのは一般的ですが、本番環境では同じSQLiteデータベースを使わないでしょう。この点を把握し、コンテナの脆弱性スキャンで適切な情報を得られれば、開発環境でSQLiteとともにインストールされるライブラリの脆弱性は無視する、と判断できます。Dockerスキャンでこうした情報や、作業を大幅に簡単にする追加情報をどのように得られるかを見ていきましょう。
  

  

• テスト用イメージを整理する
  テスト用イメージ:脆弱性への対処方法という点では、実際のところ開発用イメージと大きな違いはありません。本番用イメージに含まれないテスト用パッケージに脆弱性があるとわかっていれば、無視してもよいでしょう。この段階では、特に開発段階で重大な脆弱性を無視することにした場合、開発段階のスキャン結果と比較するのがおすすめです。開発用イメージにあった脆弱性は、テスト用イメージで本当に解消されていますか？解消されているなら、プロセスは機能しています。そうでなければ、開発用イメージまたはビルド手順を見直す必要があるかもしれません。

• 本番用イメージをしっかり固める
  本番用イメージ:は、実際にどこかで実行され、外部に公開される可能性もあるため、特に重要です。それでも、可能な限りイメージを軽量化して不要なものを削除したとしても、脆弱性ゼロの実現は困難でしょう。多くの場合、目標はリリースプロセスの自動化です。高リスクの脆弱性、特に既知のエクスプロイトがあるものには必ず対処しましょう。また、開発段階やテスト段階のイメージもスキャンする理由の1つは、リリース直前に予期せぬ問題が発生するのを減らすことです。早い段階でリスクを軽減できていれば、本番環境のスキャンは主に、直前に発見された新たな脆弱性を見つけるためのものとなります。

別の例を見て、DockerとSnykを活用して中間レイヤーに対処する方法を確認しましょう。

実践例：ユーザーが追加した脆弱性の修正を優先する

この例では、Snykを活用したDockerの脆弱性スキャン機能で使える、中間レイヤーに関する実践的なテクニックをいくつか紹介します。まずは、今回はもう少し興味深いアプリケーションを使います。Rubyアプリですが、今回の演習ではそれほど重要ではありません。

こちらがDockerfileです。

```
FROM ruby:2.5.1

RUN apt-get update && \
  apt-get install -y git vim && \
  rm -rf/var/lib/apt/lists/*

RUN gem update --system 3.0.4 && \
  gem install bundler -V '2.0.2'

WORKDIR /usr/src/app/alpha-blog

COPY . .

ENV BUNDLER VERSION 2.0.2

RUN bundle update && \
  bundle install && \
  rails db:setup && \
  rails db:migrate

EXPOSE 3000

CMD ["rails", "server", "-b", "0.0.0.0"]
```

Rubyの親イメージに複数のレイヤーを追加する、シンプルなDockerfileです。

• 最初のRUN行では、イメージ内でローカル開発を行うためのユーティリティをいくつか追加します。

• 続いて、Rubyの主要コンポーネントを更新し、使える状態にします。

• COPY . . コマンドでコードをコピーします。

• RUN bundle…コマンドでRailsプロジェクトをセットアップします。

「イメージにgitやvimをインストールするのはおかしい」と思ったなら、そのとおりです。これはやめましょう。前述のラボ全編では、このイメージの経緯と、なぜこれらが含まれているのかを説明しています。

何が起きているのかはそれほど複雑ではありませんが、ご想像のとおり、Dockerfileの各行によってかなりの量がインストールされ、イメージに新たな脆弱性が追加される可能性があります。

前と同じ方法で、このイメージをビルドしてテストできます。

```
$> docker build -t blog .

[+] Building 111.5s (11/11) FINISHED
.
.
.
=> [6/6] RUN bundle update && bundle install && 
  rails db:setup && rails db:migrate 108.8s
=> exporting to image                                           1.6s
=> => exporting layers                                          1.6s 
=> => writing image sha256:0b7c017032e301429...433c23a5         0.0s                                  
=> => naming to docker.io/library/blog                          0.0s                 

$> docker scan blog -f Dockerfile

Testing blog...
.
.
.
X High severity vulnerability found in bzip2
  Description: Out-of-bounds Write
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-BZIP2-450801
  Introduced through: bzip2@1.0.6-8.1, bzip2/libbz2-dev@1.0.6-8.l, imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-11+deb9u6,meta-common-packages@meta
  From: bzip2@1.0.6-8.1
  From: bzip2/libbz2-dev@1.0.6-8.1
  From: imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-ll+deb9u6>imagemagick/libmagickcore-6.q16-dev@8:6.9.7.4+dfsg-1l+deb9u6 › bzip2/libbz2-devel.0.6-8.1
  and 1 more..
  Introduced by your base image (ruby:2.5.1)

X High severity vulnerability found in apt/libapt-pkg5.0
  Description: Arbitrary Code Injection
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-APT-407402
  Introduced through: apt/libapt-pkg5.0@1.4.8, apt@l.4.8
  From: apt/libapt-pkg5.001.4.8
  From: apt@l.4.8 > apt/libapt-pkg5.001.4.8
  From: apt@l.4.8
  Introduced by your base image (ruby:2.5.1)
  Fixed in: 1.4.9

Organization:      snyk-pmm
Package manager:   deb
Target file:       Dockerfile
Project name:      docker-image|blog
Docker image:      blog
Base image:        ruby:2.5.1
Licenses:          enabled

Tested 413 dependencies for known issues, found 871 issues.

Base Image     Vulnerabilities   Severity
ruby:2.5.1     867               48 high, 237 medium, 582 low

Recommendations for base image upgrade:

Minor upgrades
Base Image     Vulnerabilities   Severity
ruby:2.5       257               6 high, 34 medium, 217 low

Alternative image types
Base Image                       Vulnerabilities   Severity
ruby:2.5-slim                    53                0 high, 5 medium, 48 low
ruby:2.7.0-slim-buster           61                1 high, 8 medium, 52 low
ruby:2.7.0-preview3-slim-buster  63                1 high, 9 medium, 53 low
ruby:2.7.0-preview2-slim         63                1 high, 9 medium, 53 low

このDockerfileの作成者は、前のセクションで説明したアドバイスに従わなかったようです。脆弱性は871件、親イメージだけでも867件あります。この人を探し出して、このガイドを渡さなければなりません。しかし、まずはDockerfileのコマンドによって脆弱性が追加されたかどうかを確認しましょう。問題の合計数とベースイメージの問題数の差から、少なくとも4件の脆弱性に対処する必要があることがわかります。

docker scanコマンドで–exclude-baseオプションを使い、ベースイメージ由来の脆弱性をすべて除外すれば、原因をすばやく絞り込めます。ベースイメージの脆弱性を除外して再スキャンした結果の一部を見てみましょう。

—exclude-baseオプションを使うには、これまで使用してきた-f Dockerfileオプションを指定して、スキャン対象にDockerfileを含める必要があります。

X High severity vulnerability found in curl/libcurl3
  Description: Buffer Overflow
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-CURL-466505
  Introduced through: curl@7.52.1-5+deb9u7, curl/libcurl4-openssl-dev@7.52.1-5+deb9u7, gitel:2.11.0-3+deb9u7
  From: curl@7.52.1-5+deb9u7 > curl/libcurl3@7.52.1-5+deb9u7
  From: curl/libcurl4-openssl-dev@7.52.1-5+deb9u7 › curl/libcurl3@7.52.1-5+deb9u7
  From: curl@7.52.1-5+deb9u7
  and 2 more..
  Introduced in your Dockerfile by `RUN apt-get update && apt-get install -y git vim && rm -rf/var/lib/apt/lists/*`
  Fixed in: 7.52.1-5+deb9u10

Organization:     snyk-pmm
Package manager:  deb
Target file:      Dockerfile
Project name:     docker-image|blog
Docker image:     blog
Base image:       ruby:2.5.1
Licenses:         enabled

Tested 413 dependencies for known issues, found 70 issues.

これなら、問題は871件から70件に減り、対処しやすくなります。検出された脆弱性の一覧を確認すると、「Introduced in your Dockerfile by」で始まる行も見つかります。特定の脆弱性を発生源までたどれる依存関係のパスも表示されますが、コマンドをわかりにくく解釈した結果ではなく、実際のDockerfileのコマンドが表示されるため、問題がどこで持ち込まれたかを直接確認できます。

それでも、脆弱性70件を一度に処理するのは大変です。

セキュリティチームと開発チームが最初に対処したいのは、修正可能で深刻度の高い脆弱性であることがよくあります。

JSON出力オプションと、コマンドライン用のJSONユーティリティjqを使って絞り込めば、さらに詳しい情報も簡単に確認できます（jqはコマンド内の改行にも問題なく対応します）。

```
$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

[
  {
    "packageName": "curl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "7.52.1-5+deb9u7",
    "nearestFixedInVersion": "7.52.1-5+deb9u13"
  },
...  
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Integer Overflow or Wraparound",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Buffer Overflow",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  }
]
```

これで完了です。最終的な表示には36件の脆弱性があり、すべて深刻度が高く、修正プログラムも提供されています。Dockerfileのコマンドと修正バージョンも確認できます。これをもとに脆弱性を修正できるはずです。jqコマンドに慣れていないと複雑に見えるかもしれません。ここで実行した処理を簡単に説明します。jqは非常に強力なので、少し時間をかけて学ぶ価値があります。

まず、docker scanコマンドに--json出力オプションを追加し、jqを使って次の処理を行いました。

• 出力から脆弱性だけを選択

• 修正可能な脆弱性と、深刻度が「high」の脆弱性だけを選択

• 脆弱性に関する一部のフィールドだけを表示し、出力を整理

まとめ

コンテナセキュリティは幅広いテーマであり、イメージのセキュリティだけに絞っても、検討すべきセキュリティ上の要素は複数あります。イメージを保護するうえで、押さえておきたいポイントは次のとおりです。

• 信頼できるプロバイダーのベースイメージから始めましょう。デジタル署名を使って真正性を確認してください。

• 可能な場合は、基本的なOSパッケージと選択したフレームワークのバージョンだけを含む最小限のベースイメージを選び、そこから必要なものを追加しましょう。

• イメージは早い段階から、定期的に脆弱性をスキャンしましょう。積極的にメンテナンスされ、すべてのセキュリティチェックに合格した承認済みのベースイメージを用意し、新しいイメージを作成するたびに再度スキャンしてください。

• ソフトウェアライフサイクルの複数の段階でスキャンを実施しましょう。デスクトップ、CI、レジストリに保存されたイメージ、クラスターで実行中のコンテナやPodが対象です。

• スキャンツールを選ぶときは、表示される脆弱性の一覧だけで判断しないでください。

  • 脆弱性を報告するだけでなく、より新しい、またはより適切なベースイメージがあることも通知してくれますか？

  • 脆弱性の検出によってビルドが失敗した場合、開発者やDevOpsチームが問題を修正できるだけの情報を提供しますか？

  • 必要なセキュリティゲートを柔軟に設定できますか？

  • すべてに通用する方法はありません。開発者は、本番環境では許可できないツールをイメージに追加する必要があるため、開発ライフサイクルの各段階で異なるイメージを使うこともあります。こうした段階をサポートする自動化、CI、Dockerfileを活用すれば、適切なセキュリティゲートを設け、セキュリティと生産性のバランスを適切に保てます。

DockerとSnykでコンテナイメージの保護を始めるなら、今すぐ登録しましょう。