本記事は2021年12月22日に公開した英語ブログSnyk Container in 2021: Shifting container security all the way leftの日本語版です。

Snykのセキュリティプラットフォームは、下記の4つの製品を提供しています。

Snyk Open Source: オープンソースコードの脆弱性を発見し、修正することができます。
Snyk Code: アプリケーションコードの脆弱性を発見し、修正することができます。
Snyk Container: コンテナイメージの脆弱性を発見し、修正することができます。
Snyk Infrastructure as Code: Kubernetes、Helm、Terraformの設定ファイルの脆弱性を発見し、修正します。

そのうち、本日のブログはSnyk Containerについて、2021年の製品アップデートのまとめと、2022年の方向性についての話になります。

コンテナとKubernetesの利用は、どのような形であれ、拡大を続けています。そして、最近の有名な脆弱性により、コンテナ・セキュリティがアプリケーション・セキュリティ・プログラム全体にとっていかに重要であるかが明らかになりました。自分自身のコード、依存しているパッケージ、そして使用するコンテナ化されたサービスを保護することは、すべて必須です。

加えて、コンテナの急速な普及が続く兆しは、弊社も感じています。2021年、Snykのお客様は1億3000万件以上のコンテナテストを実行しました。これは、2020年の10倍のコンテナテスト数です！DatadogとSysdigはそれぞれ10億以上のコンテナを監視していると報告しており、Gartnerは、グローバル企業の75％以上が、2022年には本番環境でコンテナ化アプリケーションを稼働させると予測しています。この割合は2020年には30%未満でした。

2021年末に向け、Snykの各製品の大きな新機能を振り返っていますが、今回はSnyk Containerにフォーカスしてご紹介します。

2021年にSnyk Containerの利用が急増

前述の通り、Snyk Containerは2021年にこれまでに1億3000万件以上のコンテナテストに使用されています。しかし、コンテナをテストすることがSnyk Containerの最終目的ではなく、コンテナの問題をFIXすることが望ましい結果であり、Snyk Containerを使うことで見えてきたことがあります。

2021年にSnyk Containerのユーザーによって修正された脆弱性は5600万件
これは、200万以上のイメージに対して1億3300万回以上のコンテナスキャンを実行し、1億1100万以上のコンテナ固有の脆弱性を検出したことによるもの

（注記）なお、同じイメージに対して繰り返し行うテストでは、検出された脆弱性は1回しかカウントされないため、テスト回数よりも脆弱性の数の方が少なくなっています。

また、パイプラインやレジストリにあるイメージのスキャンだけではありません。47,000のKubernetesプロジェクトとDockerfilesを含む352,000のGitリポジトリもSnyk Containerで監視されました。

Snyk Containerの開発者向け機能強化

2021年、Snyk Containerは開発者のワークフローにフィットするよう、いくつかの機能を追加しました。私たちの目標は、コンテナの問題を発見し修正するプロセスを、できる限りシンプルで明白なものにすることです - 修正しないのは難しいほどシンプルです。

最も大きな新機能の1つは、ソースコードリポジトリからDockerfileをスキャンし、検出された問題を修正するためのプルリクエストをオープンする機能です。これはコンテナセキュリティ製品としては初めてのことで、アプリケーションのために安全で優れたベースイメージを選択することは、コンテナから90%もの脆弱性を削減するためにできる簡単な方法です。

【スクリーンショット】Snyk ContainerはDockerfileをスキャンして、ベースイメージの推奨とPRの修正を提供します。

ビルドの元になるベースイメージの選択は非常に重要であるため、コンテナのライフサイクルのどこでスキャンするかにかかわらず、できるだけ多くのユーザーがSnykのベースイメージガイダンスを受け取れるようにしたいと思いました。そのため、コンテナのベースイメージを検出する方法を変更しました。12月に入り、テストしたすべてのコンテナの80%以上に対してベースイメージガイダンスを提供できるようになりました。この割合は1月時点の約25%から大きく伸びています。

【グラフ】ベースイメージの自動アップグレードアドバイスがあるコンテナプロジェクトの割合

興味深いことに、Snyk ContainerのベースイメージロジックはDockerの公式イメージを中心に構築されており、こうした親イメージの誘導率の高さは、コンテナの世界におけるDockerの人気と重要性が継続していることを明確に示しています。

また、SnykConでは、Snyk ContainerのIDEサポートについて開発中の機能のデモンストレーションを実施しました。Dockerとの継続的なパートナーシップとともに、これはコンテナセキュリティをさらにシフトレフトしていくための大きな予兆と言えます。

コンテナワークフローとエコシステムの改善

2021年には、コンテナベースのワークフローにおいて、問題の解決をより複雑にしている厄介な問題への取り組みも開始されました。また、成長を続けるエコシステムの中で、人気のあるコンテナツールのサポートを広げたいと考えていました。

コンテナのワークフローに関する奇妙な苦労の1つは、Dockerfileとその結果のイメージを互いにリンクさせておくことです。コンテナイメージには、それを作成するために使用されたDockerfileを追跡する固有の方法がありません。そのため、特定のコンテナの担当者を追跡したり、問題を修正する場合にどのDockerfileを編集する必要があるかを追跡することが困難になっています。Snyk Container ではこれを容易にするため、この 2 つの成果物を結びつける方法を提供する OCI 標準のコンテナ・ラベルに従うことにしました。Snyk Container では、この OCI ラベルを使用すると、Snyk でテストしたどのコンテナイメージが特定の Dockerfile からビルドされたかを自動的に表示できるため、コンテナテストを互いに関連付けるだけでなく、変更を加えることができる Dockerfile に直接到達することも簡単にできるようになります。

標準の受け入れといえば、SnykがKubernetesクラスタで何を監視するかを決定するために、オープンポリシーの標準を使用する機能も追加されました。Open Policy Agent (OPA) は、クラウドネイティブ環境向けのポリシーベースのコントロールプレーンとして注目されています。私たちはこれをKubernetesモニターで使用して、自動的に監視するワークロードを決定し、そのワークロードがクラスタ内で動作しなくなったら、いつ、どのように削除するかを決定できるようにします。

また、より一般的なコンテナエコシステムツールとの統合を新たに追加しました。

コンテナノイズの低減とセキュリティの充実

セキュリティ情報を増やしつつ同時に、コンテナの脆弱性のノイズを減らすことは一見、不可能だと思えるかもしれません。しかし、私たちは2021年にSnyk Containerでそれを成功させることができました。

コンテナからのセキュリティ警告のノイズを減らし、修正すべき最も重要な脆弱性に優先的にフォーカスするために、私たちは脆弱性にソーシャルトレンドデータを追加しています。ソーシャルメディア上での話題の増加は、その脆弱性の周辺で悪意あることが起こっている可能性を示すシグナルであり、優先順位付けの大きな助けになります。

また、Snyk プラットフォームのセキュリティポリシー機能を改善し、組織全体のスケールで脆弱性に焦点を当てる新しい方法を提供しました。例えば、本番環境で動作しているアプリのメモリ関連の脆弱性の優先度を上げたいと思うかもしれません。Snykのセキュリティポリシーインターフェースを使用すると、次のようなポリシーを設定できます。

Production属性やタグを持つアプリは...
CWE 125 (out-of-bounds read) または CWE 787 (out-of-bounds write) のいずれかに該当する脆弱性で...
クリティカルに昇格

【スクリーンショット】メモリ関連の弱点がある重要なフロントエンドのプロジェクトの重要度を上げるためのSnykのセキュリティポリシー

また、コンテナのセキュリティ情報をより多く追加するという側面から、Alpine、Debian、Ubuntu、新しいCentOS Streamなど、コンテナで使用される人気のLinuxディストリビューションの最新リリースを、そのメンテナがリリースすると同時にサポート対象に追加しました。また、Red Hat Enterprise Linux、Amazon Linux、CentOS Streamの脆弱性報告の方法を変更し、各CVEについてより詳細な情報を提供するとともに、深刻度に関するディストリビューション固有の詳細も追加しました。

2022年に向けて

弊社のダニエルがSnykオープンソース2021のレビューブログで述べたように、安全なサプライチェーンは重要性を増し注目を集めているテーマであり、コンテナはその主要な部分です。自社独自のビルドプロセスに従って、自社のコンテナに含まれるすべてのコンポーネントを把握することは、より重要になっています。しかし、サードパーティのコンテナ化されたアプリケーションに何が含まれているかを知ることも、同様に重要です。データベースコンテナ、ロギングツール、検索ツール、ロードバランサー、ゲートウェイなどは、アプリケーションと一緒に配備され、重要な機能を提供している可能性があります。しかし、これらのコンテナには危険な脆弱性が潜んでいる可能性があり、そのことを把握し、コンテナの提供元が新しいバージョンを提供したら、すぐにロールアウトできるようにしておく必要があります。

また、脆弱性の優先順位付けについても、やりたいことがたくさんあります。これには、特定のパッケージや脆弱性がより危険であるという新しいシグナルと、注目に値しないノイズのような脆弱性を開発者が排除できるような、よりインテリジェントでスケーラブルなポリシーの両方が含まれます。この 2 つを組み合わせることで、Snyk Containerのユーザーが対応するのは、スキャンで検出された何百もの脆弱性から、最も緊急性の高い脆弱性を修正するためのわずかなステップになるでしょう。過労気味のセキュリティチームの背中から脆弱性管理の負担を軽減できるはずです。

2022年が安全で幸せな年になることを祈っています。

#最後に
日本語の公式SNSを開設しました。最新の脆弱性情報についても発信しているので、ぜひフォローをお願いします。

またSnykは無料でお試しいただけます。ぜひお試しください！

Snykを活用したブログは、ぜひQiitaアドカレ2021もご参照ください。