コンテナのセキュリティを維持することになると、ソフトウェアのバグは避けられません。 多くの場合、無害な不具合ですが、悪意のある人物がシステムにアクセスできるようにするなど、深刻なセキュリティリスクをもたらすものもあります。 商用ソフトウェアまたはオープンソースソフトウェアの脆弱性を発見した場合は、共通脆弱性識別子(CVE)データベースに登録する必要があります。 現在、 170,000 を超えるCVEが記録されており、エンジニアは 2022年3月だけで2,083を超える新しいCVEを発見し ました。
この記事では、脆弱性がコンテナーに与える影響と、信頼できるソースからのイメージの使用がどのように役立つかについて説明します。 次に、DockerのネイティブSnyk統合を使用してソフトウェアサプライチェーンを保護する方法について説明します。
ソフトウェア・セキュリティの現状
開発者は、サービスを構築する際にサードパーティのコードやアプリケーションに目を向けることが増えています。 残念ながら、サードパーティのソフトウェアを使用すると、コードがリスクにさらされる可能性もあります。 信頼できるイメージを活用し、継続的な警戒を通じてコンテナを保護することが絶対に不可欠です。
これが、画像スキャンが開発の初期段階だけでなく、アプリケーションの寿命全体にわたって非常に重要である理由です。 ありがたいことに、Dockerのお客様は、Snykを介してワークフローに統合された継続的なセキュリティスキャンにアクセスできるため、脆弱性をより簡単に見つけて修正できます。 従来のコンテナでもKubernetesアプリケーションでも、Snykのネイティブ統合はソフトウェア開発ライフサイクル全体を通じて価値があります。
脆弱性がコンテナに与える影響
Docker コンテナーは、通常はオンライン ソースからの基本イメージから始まります。 次に、チームはレイヤーを追加して、必要な機能を組み込みます。 これらのレイヤーは、フォルダーの作成などのアクションを実行する単純なコマンドである可能性がありますが、多くの場合、追加のパッケージをプルします。
以下は、 good-nodejsという基本的なDockerfile例です。
[テキスト]
FROM node:lts-alpine3です。15
WORKDIR /ワークディレクトリ
npm i express-openid-connect を実行します
[/テキスト]
このファイルには 3 つのレイヤーがあります。
FROM: この命令は、新しいビルドステージを初期化し、今後の手順のために基本イメージを準備します。 有効なDockerfileものは式FROMで始まります。 上記の例では、Alpine Linux 上に構築された公式の Node.js イメージを使用しています。 このイメージには、Node を起動して実行するために必要なものがすべて含まれています。 複数のレイヤーがあり、そのDockerfileサイズから確認できます。 Alpine Linux OSレイヤーとAlpine を構成するレイヤーの各レイヤーは、潜在的な脆弱性ソースです。WORKDIR: このレイヤーは作業ディレクトリを設定します。 ここでのリスクは、新しい外部ソフトウェアパッケージを導入しないため、WORKDIR最小限または存在しません。RUN: この教育レイヤーは、別のサードパーティパッケージをインストールします。 パッケージコード、その依存関係、およびその他の必要なパッケージを介して、追加の脆弱性が発生する可能性があります。
これらの上記のレイヤーには、目立たないイメージの奥深くに脆弱性を隠すためのコツがあります。 それらを見つけるには、広範な侵入テストを実行する必要がある場合があります。
信頼できるソースの使用
画像のベストプラクティスに従った信頼できるイメージは、サプライチェーンを保護する際の最も強力な味方です。 Docker Hub は、 Docker 公式 イメージと 検証済みパブリッシャー イメージへのアクセスを提供し、名前の横に目立つように表示される色分けされたバッジで示されます。
Dockerの内部チームは、Dockerの公式画像をキュレーションします。 これらの画像は頻繁に更新、スキャン、パッチを適用して、セキュリティを強化しています。 すべての重要なオペレーティングシステム、プログラミング言語、ミドルウェア、およびデータベースが表されます。
Docker の外部パートナーは、Docker 検証済みパブリッシャー イメージを提供します。 これらの画像を使用すると、それらが本物で積極的に維持されていることがわかります。 私たちのプログラムは、これらのコンポーネントが信頼できることを保証するのに役立ちます。 また、上記のような Snyk のリソースもあります。
開発者は、コンテナの問題を修正するために、高度なセキュリティのバックグラウンドを持っている必要も、CVEレポートを読む必要もありません。 このパートナーシップにより、Docker開発者は、オープンソースおよびコンテナ脆弱性インテリジェンスの業界で最も包括的でタイムリーかつ正確なデータベースにアクセスできます。
当社のセキュリティ範囲は、CVEの脆弱性やその他の公開データベースをはるかに超えています。 Snykの社内調査チームは、データベースを維持し、公開ソース、コミュニティへの貢献、独自の調査、機械学習を組み合わせて、動的なセキュリティ脅威に継続的に適応しています。
脆弱性の特定
信頼できるイメージは開発の出発点として最適ですが、完全には機能しない可能性があります。 代わりに、コミュニティから提供された画像または外部の開発者からの画像を活用することを選択できます。 幸いなことに、 Docker HubのSnyk統合 を使用して、画像やコードに隠された脅威を検出できます。 さらに重要なことに、Snykの統合により、開発者は基本イメージの修正に関する推奨事項を使用でき、脆弱性をもたらすDockerfile行が特定されます。
自動脆弱性スキャンにより、コンテナイメージに侵入したCVEを検出できます。 これは、ソフトウェアサプライチェーンを保護するために不可欠なツールであり、サードパーティのコードをプロジェクトに統合する際の最前線の防御メカニズムとして機能します。
このスキャンは、で Dockerfile定義されているすべてのパッケージと依存関係を調べ、記録された脆弱性のリストと照合することによって機能します。
リポジトリの脆弱性スキャンは、それぞれの [設定] タブで有効にできます。
スキャンを有効にすると、Snykはリポジトリにプッシュされた新しいタグ(特定のイメージバージョンやバリアントなど)を自動的に分析します。
先ほどの基本的な Dockerfile を考えてみましょう。 イメージスキャンのしくみを示すために、古いバージョンの基本イメージ (既知の脆弱性を持つ) をプルし、 npm パッケージに対して同じことを行うことができます。
[テキスト]
FROM ノード:15.9。0- アルプスの3。13
ワークディール /ワークディール
npm i express-openid-connect@2を実行します。7。1
[/テキスト]
ここからSnykの機能を試すことができます。 このコードをビルドして Docker Hub リポジトリにプッシュすると (テストタグ bad-nodejs を付けて (前の good-nodejs と一緒に)、Snyk が自動的にスキャンしたことがわかります。 このスキャンでは 22 深刻度が高の脆弱性と 8 つの深刻度が中の脆弱性が検出されました。
次に、結果に飛び込んで、検出されたすべての脆弱性の内訳を取得し、 bad-nodejs 次の情報を表示できます。
- 過酷
- 優先度スコア
- CVE番号
- 問題を引き起こすパッケージ
- バグと修正を含むパッケージバージョン
脆弱性をさらに掘り下げると、Snykはツリーのような構造内に情報を表示します。 どのパッケージが脆弱性の導入に関与しているかを確認できます。 次の例では、 が のインポートzlib であり、 apk-tools領域外書き込みの脆弱性が存在します。
継続的な監視の有効化
古いイメージ バージョンを使用してレガシ システムをレプリケートすることは一般的な方法です。これにより、アプリケーションの下位互換性が保証されます。 ワークフローによっては、新機能よりも安定性を優先する場合もあります。 最後に、新しいソフトウェアバージョンのライセンスは、会社にとって法外なコストがかかる可能性があるため、古いバージョンを維持することができます。
最先端のテクノロジーを使用してイメージを構築し、それを本番環境に展開すると、ある程度のリスクが伴います。 製品開発が長期間停滞すると、誰かが公開リリースに脆弱性を見つける可能性が高くなります。 最新バージョンを選択したため、展開前にこれらの脆弱性について知ることはできません。
Snykのテクノロジーを使用して、Docker Hubはすべてのリポジトリイメージを定期的に再スキャンすることでこれらのリスクを軽減します。 Docker Hub サブスクリプションでは、Docker Desktop がローカル UI として付与されます。 これにより、組織全体のイメージの最近のスキャン結果を表示できます。
Web UI を使用したコンテナイメージの修正
Dockerfiles をパブリックにアクセス可能なソース管理 (GitHub、GitLab、Bitbucket など) にプッシュすると、コードを無料の Snyk アカウントと統合し、詳細な修復の推奨事項を取得できます。 Web UI では、ソース コードへのプル要求を使用して脆弱性を自動的に修正するように求められます。
コマンドラインによるコンテナイメージの修正
Docker デスクトップは、ローカルで強力な CLI スキャンも提供します。 この代替方法により、Snykはあなた Dockerfile を調べ、その結果に基づいて詳細な推奨事項を提供できます。 また、シフトレフトテスト哲学を採用している場合にも不可欠なツールです。
前述の bad-nodejs イメージをコマンドラインでスキャンすると、Docker Hub内で見つかったのと同じ脆弱性が見つかります。
[テキスト]
✗ apk-tools/apk-toolsで見つかった重大な脆弱性
説明: Out-of-bounds Read
情報:https://snyk.io/vuln/SNYK-ALPINE313-APKTOOLS-1533754
導入方法: apk-tools/apk-tools@212。1-r0
差出人: apk-tools/apk-tools@2.12。1-r0
イメージレイヤー:ベースイメージによって導入されます(ノード:15.9-alpine3.13)
修正済み: 2。12。6-r0
[/テキスト]
この出力は、脆弱性がどのように導入されたか、および詳細情報が入手可能なSnykへのリンクを示しています。
CLI スキャンでリンク Dockerfile すると、以前と同じ基本イメージのアップグレードの推奨事項が表示されます。
さらに下にスクロールすると、別の脆弱性が見つかります。 追加した npm パッケージは、古いバージョンを意図的に取得した後に脆弱性を導入しました。 重要なのは、Snykがこれを修正する方法を教えてくれることです。
次のステップ
セキュリティに関する議論は、従来の開発環境では頭痛の種になると同時に複雑になる可能性があります。 プロセスの断片化は、あるチームから次のチームへのセキュリティに影響を与え、多くの場合、まとまりのある戦略を形成する責任はリーダーにあります。 ただし、チームがセキュリティで保護されたアプリケーションを構築、実行、共有しているかどうか疑問に思う必要はありません。
したがって、自動化された脆弱性スキャンは、組織がソフトウェアサプライチェーンを保護するのに役立ちます。 DockerのネイティブSnyk統合により、組織のイメージセキュリティを幅広く監視し、依存関係レイヤー内の脆弱性を検出します。 Snyk用のDocker拡張機能は、コンプライアンス要件を満たしながら、開発のベストプラクティスにより適切に従うのに役立ちます。 Snyk スキャンの開始と Snyk の Docker 拡張機能の詳細については、 こちらをご覧ください。
この統合により、セキュリティを強化するために必要な時間と労力が削減されます。 代わりに、開発チームはサービスの改善に時間を費やすことができます。 Docker の脆弱性スキャンの統合と、イメージの保護を開始する方法の詳細については、 ドキュメントを参照してください。