Snyk ContainerとCloud Native Buildpacks：クラウドネイティブアプリケーションセキュリティの正しいアプローチ

コンテナでマイクロサービスを実行していますか？おめでとうございます！これは、アプリケーションをできるだけ早くお客様に届けるというビジネスニーズに応えるための重要な一歩です。しかし、ソフトウェアのデプロイを迅速化することで生じる潜在的なリスクは、どのように軽減できるでしょうか？答えはシンプル、Snykです。

Snyk Containerを、OCI準拠のコンテナイメージを作成するビルドツールと組み合わせれば、リスクを軽減し、本当に重要な優れた顧客体験の提供に注力できます。その仕組みを見ていきましょう。

DockerイメージとOCI準拠イメージの違い

どのコンテナランタイムでも、あらゆるビルドツールが生成したイメージを実行できるように、オープンソースのコンテナコミュニティは、コンテナイメージの形式とランタイムに関する業界標準を定めるため、Open Container Initiative（OCI）を立ち上げました。OCIイメージがあれば、OCI Runtime Specificationを実装したコンテナランタイムなら、イメージを展開して隔離された環境で実行できます。

Dockerという企業をご存じの方も多いでしょう。OCIイメージとDockerイメージの違いは何だろうと思うかもしれません。現在の答えは「ほとんど違いはない」です。OCI仕様より前に作られた古いDockerイメージが少数残っています。正式にはDocker v1仕様形式と呼ばれ、OCIに寄贈されてOCI仕様の基礎となったDocker v2スキーマとは互換性がありません。しかし、これらのv1イメージは2017年までのものです。現在では、ほぼすべてのコンテナレジストリ、Kubernetesプラットフォーム、コンテナランタイムがOCI仕様を基盤にしています。Dockerエンジン、Docker Hubをはじめ、Dockerの各種ツールや製品もその例です。

なぜこれが重要なのでしょうか？オープンな仕様によって、さまざまなグループが革新的なコンテナ構築方法を生み出せるようになりました。そして、いずれもOCI準拠のイメージを作成するため、どこでも実行でき、Snyk Containerのようなセキュリティツールで保護できます。開発チームには、Dockerfileの書き方を気にしたり、どのオープンソースライブラリを使うべきか何時間もかけて確認したり、Docker Hubにある何千ものイメージタグを調べてベースイメージを選んだりするのではなく、アプリケーションの中核となるコードに集中してほしいものです。ここでは、ソースコードから直接コンテナを構築する方法のひとつ、Cloud Native Buildpacksを見ていきましょう。

Cloud Native Buildpacks：ワンステップでソースコードからコンテナへ

Cloud Native Buildpacks（CNB）は、アプリケーションのソースコードを、あらゆるクラウドで実行できる完全準拠のOCIイメージに変換します。さらに、主要なプログラミング言語すべてに対応しています。コンテナの課題を解決し、制御性、コンプライアンス、保守性も実現します。

Heroku、Pivotal PaaS（現在のVMware Tanzu Application Service）、または関連するオープンソースのCloud Foundryを使ったことがあれば、Buildpacksに似た仕組みを目にしたことがあるでしょう。コードをそれらのサービスにプッシュするだけで、適切なランタイム環境にパッケージ化してくれます。CNBは、同じ体験をOCIイメージでも実現します。開発者がコードを書くと、CNBがアプリの依存関係をビルドし、アプリの実行に必要なものをすべてコンテナイメージにパッケージ化します。

Cloud Native Buildpacksの仕組み（出典：vmware Tanzu Developer Center）

例

1$ pack build pasapples/pbs-demo-image:latest --builder paketobuildpacks/builder:base --publish --path ./target/springbootemployee-0.0.1-SNAPSHOT.jar

Cloud Native Buildpacksは、具体的に何を構築するのでしょうか？

他のイメージ構築ツールと同様に、Cloud Native Buildpacksは、ランタイム、アプリケーション、そのすべての依存関係を含むファイルシステムレイヤーのセットと、アプリケーションの起動方法をコンテナエンジンに伝えるメタデータを作成します。以下は、docker image historyコマンドを使って、上記の例のレイヤー情報を表示したものです。

1$ docker image history pasapples/pbs-demo-image:latest
2IMAGE      CREATED    CREATED BY   SIZE  COMMENT
35d29940d2e52   41 years ago            68kB
4<missing>  41 years ago            46.3MB
5<missing>  41 years ago            10B
6<missing>  41 years ago            7.05MB
7<missing>  41 years ago            451kB
8<missing>  41 years ago            2.09MB
9<missing>  41 years ago            7.23MB
10<missing>  41 years ago            3.04MB
11<missing>  41 years ago            140MB
12<missing>  41 years ago            214B
13<missing>  41 years ago            6.69MB
14<missing>  41 years ago            2.27MB
15<missing>  41 years ago            398kB
16<missing>  41 years ago            6.51MB
17<missing>  41 years ago            7B
18<missing>  41 years ago            745B
19<missing>  41 years ago            987kB
20<missing>  41 years ago            63.2MB

「41年前」というタイムスタンプに戸惑うかもしれませんが、これは再現可能なビルドを実現するためのものです。詳しくはこちらをご覧ください。Time Travel with Pack

diveというツールを使うと、レイヤーの内容をさらに詳しく確認できます。下のスクリーンショットの左上のウィンドウでは、イメージの下から2番目のレイヤーを選択しています（diveではレイヤーが下から上へ表示されますが、上記のビルド出力では逆順です）。右側では、そのレイヤーの内容を確認しています。OCIイメージ内にあるSpringbootアプリケーションのJARファイルが含まれています。CNBは、ソースコードをもとに、これらすべてをまとめてくれました。

Snyk ContainerによるOCIコンテナイメージのセキュリティ対策

Snyk Containerは、Cloud Native Buildpacksやその他のビルドツールで作成されたものを含む、準拠したあらゆるOCIイメージをスキャンし、SDLC全体を通じてコンテナやKubernetesワークロードの脆弱性を検出します。さらに、Snykはコンテナに含まれる脆弱性を一覧表示するだけではありません。Snyk Containerは、より安全で脆弱性の少ないコンテナを迅速に構築するためのアドバイスを提供します。また、新しく改良されたベースイメージ検出機能により、これまでDockerfileを含めた場合にのみ提供できていたレベルのアドバイスを提供できるようになりました。

Snyk Containerによるベースイメージの自動修正

開発者がより安全なベースイメージへのアップグレードや、古くなったベースイメージを使ったイメージの再ビルドによって、多数の脆弱性をすばやく解消できるようにし、セキュリティ対策を拡大しましょう。

OCIイメージをスキャンすると、Snykはイメージのベースとなっているベースイメージを検出し、以下のように脆弱性の少ないベースイメージを提案できます。

このOCIコンテナには、どのベースイメージを使えるでしょうか？または、最近更新したベースイメージはあるでしょうか？

ベースイメージの推奨情報は、ライフサイクルのどの段階で、どこからイメージをスキャンしても確認できます。上の例はDocker Hubに保存されたイメージを示しています。下の例ではSnyk CLIを使ってイメージをスキャンしています。これはCIパイプラインでのスキャンにも適用できます。以下のように、Snykは脆弱性の少ないベースイメージを提案できます。

1$ snyk container test pasapples/pbs-demo-image
2
3Testing pasapples/pbs-demo-image...
4
5✗ High severity vulnerability found in openssl
6  Description: NULL Pointer Dereference
7  Info: https://snyk.io/vuln/SNYK-UBUNTU1804-OPENSSL-1089073
8  Introduced through: openssl@1.1.1-1ubuntu2.1~18.04.5, ca-certificates@20180409, openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
9  From: openssl@1.1.1-1ubuntu2.1~18.04.5
10  From: ca-certificates@20180409 > openssl@1.1.1-1ubuntu2.1~18.04.5
11  From: openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
12  and 1 more...
13  Fixed in: 1.1.1-1ubuntu2.1~18.04.9
14
15...
16
17Organization:  pas.apicella-41p
18Package manager:   deb
19Project name:  docker-image|pasapples/pbs-demo-image
20Docker image:  pasapples/pbs-demo-image
21Platform:      linux/amd64
22Base image:    ubuntu:bionic-20200403
23Licenses:      enabled
24
25Tested 93 dependencies for known issues, found 57 issues.
26
27Base Image          Vulnerabilities  Severity
28ubuntu:bionic-20200403  49           0 critical, 0 high, 16 medium, 33 low
29
30Recommendations for base image upgrade:
31
32Minor upgrades
33Base Image Vulnerabilities  Severity
34ubuntu:bionic  25           0 critical, 0 high, 3 medium, 22 low
35
36Major upgrades
37Base Image  Vulnerabilities  Severity
38ubuntu:rolling  17           0 critical, 0 high, 2 medium, 15 low

アプリケーションとコンテナの脆弱性をまとめて確認

コンテナ内で実行されている元のソースコードにアクセスできない場合でも、コードの依存関係にある脆弱性への対処は重要です。Snykは、コンテナスキャンの一環として、主要なプログラミング言語のオープンソース依存関係を検出・監視できます。

CNB OCIイメージのベースレイヤーとオープンソース依存関係を明確に表示します。

開発者が最もリスクの高い脆弱性に集中できるよう支援

Snykを使えば、何百もの問題をひとつずつトリアージするのではなく、優先度の高い問題に簡単に集中できます。ベースイメージの脆弱性を無視または除外したり、悪用の成熟度や安全でないワークロード設定などのリスクシグナルを活用したりすることで、コンテナ脆弱性レポートにありがちなノイズを整理し、チームが重要な問題に集中できるようにします。

Snyk Containerは、クラウドネイティブアプリケーションの脆弱性を開発者が見つけて修正できるよう設計されたSnyk Cloud Native Application Securityプラットフォームの一部です。ぜひ今すぐお試しください。