Skip to main content

SnykLaunchの振り返り:カスタムベースイメージの推奨

blog feature snyklaunch container images

2023年4月4日

0 分で読めます

本日のSnykLaunchで紹介された注目の新機能の一つが、カスタムベースイメージの推奨(CBIR)です。2022年後半からオープンベータとして提供されているCBIRは、すでに複数の組織で利用されています。一般提供に向けて機能を拡充し、柔軟性を高めるとともに、手間のかからない自動化機能を追加しました。これにより、ユーザーはCBIRをCI/CDパイプラインで活用できます。

カスタムベースイメージの推奨は、Snyk Containerの中核をなす強力なベースイメージ推奨機能を拡張し、より高度なDevOpsワークフローを採用している組織やエンタープライズでも利用できるようにします。キュレーションした「ゴールデン」ベースイメージの選定、構築、カスタマイズ、強化を専門チームが担う場合も、人気の公式イメージ以外のイメージから始める場合も、ぜひ活用したい機能です。

コンテナ化されたアプリケーションの構築とリリースにはさまざまなワークフローがありますが、ベースイメージの選定、ビルド(共通ライブラリ、コンポーネント、プロジェクトファイルの追加)、デプロイという、共通する大まかなマイルストーンがあります。

ベースイメージの推奨が必要な理由

ベースイメージの選定は、多くの場合、プロジェクトで使われているプログラミング言語に基づいて「Docker Official」イメージを選ぶところから始まります。PythonアプリならPythonイメージ、JavaアプリならJavaイメージを探します。

コンテナイメージのデリバリーサイクルで重要なのは、脆弱性によるリスクを最小限に抑えることです。多くのツールは、イメージ内の脆弱なパッケージを検出し、修正版を提案できます。たとえば、node:14.0.0のベースイメージには、1,000件を超える脆弱性が含まれています。しかし残念ながら、多くのツールが次のように脆弱性ごとの対処方法しか提示しません。

┌────────────────┬──────────────────┬──────────┬─────────────────────┬─────────────────────┐
│     Library    │  Vulnerability   │ Severity │  Installed Version  │    Fixed Version    │
├────────────────┼──────────────────┼──────────┼─────────────────────┼─────────────────────┤
│ apt            │ CVE-2020-27350   │ MEDIUM   │ 1.4.9               │ 1.4.11              │
│                ├──────────────────┤          │                     ├─────────────────────┤
│                │ CVE-2020-3810    │          │                     │ 1.4.10              │
│                ├──────────────────┼──────────┤                     ├─────────────────────┤
│                │ CVE-2011-3374    │ LOW      │                     │                     │
├────────────────┴──────────────────┴──────────┴─────────────────────┴─────────────────────┤
│ ...                                                                                      │
├────────────────┬──────────────────┬──────────┬─────────────────────┬─────────────────────┤
│ curl           │ CVE-2020-8286    │ HIGH     │ 7.52.1-5+deb9u10    │ 7.52.1-5+deb9u13    │
├────────────────┴──────────────────┴──────────┴─────────────────────┴─────────────────────┤
│ ...                                                                                      │
└──────────────────────────────────────────────────────────────────────────────────────────┘

この例では、脆弱性の一部を修正できるバージョンが示されていますが、何をすればよいのかは明確ではありません。1つだけパッチを適用するべきでしょうか。それともすべてに適用するべきでしょうか。

ベースイメージの推奨を利用すれば、より優れたイメージを見つけて、そこから開発を始められます。脆弱性を1つずつパッチする代わりに、ワンクリックで大量の脆弱性をまとめて解消できます。この例では、node:14.21.3にマイナーアップグレードするだけで脆弱性を64%削減でき、bullseye-slimに移行すれば、低深刻度の脆弱性が少数残るだけになります。

Node.jsのベースイメージのアップグレード、脆弱性の件数と深刻度、修正PRを作成するオプションを比較した表

高度なDevOpsワークフロー

組織によってはアプリケーション開発チームがコンテナイメージの構築とメンテナンスを担いますが、より高度なワークフローを採用する組織もあります。そうした組織では、作業を分担し、プラットフォームチームが開発者向けの社内キュレーション済み、または「ゴールデン」ベースイメージを構築します。プラットフォームチームはベースイメージの起点を選び、社内基準に沿ってコンテナのベースイメージを設定・構築します。これには、共通ライブラリの追加、命名規則やタグ付け規則への準拠、ベースイメージの脆弱性を軽減するための強化などが含まれます。

アプリケーション、構成、ソフトウェア、ベースイメージの各レイヤーについて、中央集権型チームとプラットフォームチームを並べて比較した図。

責任を分担することで、開発者はベースイメージを修正する必要がなくなり、作成するアプリケーションに集中できます。

CBIRを使ったこの高度なワークフローの仕組みを見ていきましょう。

カスタムベースイメージのライフサイクル

プラットフォームチームとセキュリティチーム

この分業モデルでは、プラットフォームチームが起点となるイメージの選定と、開発者が使用するカスタムベースイメージの構築を担います。開発者がイメージをビルドするための、拡張性に優れた安全なサプライチェーンの自動化に責任を持つ一方、セキュリティチームにはベースイメージの状況を完全に可視化し、修正の優先順位を付けられるようにします。この可視性がフィードバックループとなり、チームはより安全なイメージをリリースできます。プラットフォームチームは、標準のベースイメージ推奨ロジックを使ってカスタムベースイメージを構築することもできます。

カスタムベースイメージを作成したら、CLI、CI/CD、API、Snyk UIなど、従来と同じ方法でSnykにインポートして監視できます。Snyk Containerでイメージの監視を開始した後、「カスタムベースイメージ」として指定し、任意で推奨の対象にできます。Snykは、セマンティックバージョニング、日付のマーキング、カスタムスキーマの命名パターンに基づいて、新しいバージョンを自動的に検出できます。

カスタムベースイメージと推奨オプションが選択され、バージョニング方式が「マーキング日」に設定されたカスタムベースイメージ推奨の設定

このプロセスはAPI経由で自動化することもできます。「推奨に使用」フラグを無効にすると、別のバージョンに置き換えたイメージを代替候補として提示しないようにできます。

開発者

コンテナがカスタムベースイメージから派生している、またはFROMでカスタムベースイメージを指定している場合、イメージファミリーに基づいて推奨が提示されます。また、イメージのビルドに使ったDockerfileが含まれていれば、この例のようにワンクリックでアップグレードすることもできます。この例では、開発者が脆弱性185件を含むmybaseimage:1.0を使用しています。最新のバージョン6.0では脆弱性が減少しており、開発者はすぐにアップグレード用のプルリクエストを作成できます。さらに、新しいベースイメージのバージョンがリリースされると、カスタムベースイメージから派生したイメージに対するプルリクエストを自動的に作成することもできます。

現在のバージョンとマイナーアップグレード版の脆弱性数と深刻度を比較し、ベースイメージのアップグレードを推奨する表。

プラットフォームチームが提供するキュレーション済みのカスタムベースイメージを使えば、開発者が確認すべきノイズを取り除けます。その結果、手動またはパッケージマネージャー経由でコンテナに追加したパッケージや、アプリケーションに集中できます。ベースイメージについて心配する必要がなくなるのがポイントです。

コンテナサプライチェーンの自動化

前述のとおり、監視対象のベースイメージをカスタムベースイメージとして指定するAPIと、コンテナの命名に使うカスタムバージョニングスキーマを登録するAPIを新たに利用できます。これにより、使い慣れた方法でイメージに名前を付けながら、カスタムの推奨機能も利用できます。

これらのAPIを使えば、カスタムイメージのタグ付けとカスタムベースイメージの推奨を自動化ワークフローに組み込み、開発者がより安全なソフトウェアの提供に集中できるようになります。

機能の詳細については、カスタムベースイメージの推奨のドキュメントをご覧ください。

今すぐお試しください!

Snyk Containerのカスタムベースイメージの推奨は現在、Enterprise Tierのお客様にご利用いただけます。今後は無料プランを含む他のプランでも利用可能になる予定です。GA前に機能を有効にするには、担当アカウントマネージャーにお問い合わせいただくか、サポートチケットを起票してください。コンテナサプライチェーンのワークフローを自在に管理しましょう。

デモを実際にご覧になるには、SnykLaunchのオンデマンド録画をご視聴ください。

開発者ファーストのコンテナセキュリティ

Snykは、コンテナイメージとKubernetesワークロードの脆弱性を検出し、自動的に修正します。

続きを読む

Blog

フロンティアモデルは脆弱性を発見した。攻撃者だけがエクスプロイトチェーンを見つけた。

静的解析で欠陥は見つかりましたが、ライブ攻撃テストで侵害につながる連鎖を実証できたのは唯一でした。Evo COS、Claude Security、Claude Code Securityを比較します。

feature insights context
Blog

自律型攻撃はすでに始まっている。防御もそのスピードに追いつかなければならない。

自律型攻撃者によって、防御に使える時間は短くなっています。継続的な検出、修復、検証、予防で、セキュリティチームが攻撃に歩調を合わせる方法をご紹介します。

Blog

AIコーディングエージェントが不適切なアクセス制御を繰り返し実装する理由

AIコーディングエージェントは、コンパイルが通りレビューも通過する一方で、あるテナントのデータを別のテナントに公開してしまう認可ロジックを生成することがあります。不適切なアクセス制御が検出しにくい理由と、その防止策をご紹介します。