Dockerハード化イメージのセキュリティとコンプライアンスの検証
このシリーズの パート 1 では、Node.jsサービスをDocker Hardened Images(DHI)に移行し、 100%の脆弱性除去、 90%のパッケージ削減、そして 41という印象的な結果を測定しました。5%のサイズが縮小します。SBOMを抽出し、FIPS、STIG、CISのコンプライアンスラベルを確認しました。
数字は説得力があるように見えます。しかし、これらの主張を独立して どうやって検証 するのでしょうか?
セキュリティツールは約束ではなく検証を通じて信頼を得ます。セキュリティ製品を本番環境で評価する際には、暗号学的な証明が必要です。これは特に、展開するすべてのコンテナの基盤となる画像に当てはまります。この記事では、署名検証、出所分析、コンプライアンス証拠検査、SBOM分析の検証プロセスについて説明します。ここでは、トライアル中に実施できる実践的な検証に焦点を当て、より詳細な技術情報については 公式DHIドキュメント へのリンクをご紹介します。最終的には、DHIのセキュリティ体制を独自に確認し、本番環境への信頼を築くことができるでしょう。
Docker Hardened Imagesで利用可能なセキュリティ証明の理解
検証に入る前に、何を確認しているのかを理解する必要があります。
Docker Hardened Imagesには、画像のビルドプロセス、内容、コンプライアンスの状況に関する暗号学的に署名されたメタデータ( attestations)が含まれます。これらは独立して検証可能な署名済みの声明です。
|
大事な:もし画像をローカルで取得した場合は、 registry:// 証言を扱う際の接頭辞。これにより、Docker Scoutはローカルイメージキャッシュだけでなくレジストリの証明も探すよう指示されます。 |
あなたの硬くなったイメージのすべての証明をリストアップしてください:
docker scout attestation list registry://<your-org-namespace>/dhi-node:24.11-debian13-fips
これは 16 異なる証言タイプを示しています:
https://slsa.dev/provenance/v0.2 SLSA provenance
https://docker.com/dhi/fips/v0.1 FIPS compliance
https://docker.com/dhi/stig/v0.1 STIG scan
https://cyclonedx.org/bom/v1.6 CycloneDX SBOM
https://spdx.dev/Document SPDX SBOM
https://scout.docker.com/vulnerabilities Scout vulnerabilities
https://scout.docker.com/secrets/v0.1 Scout secret scan
https://scout.docker.com/virus/v0.1 Scout virus/malware
https://scout.docker.com/tests/v0.1 Scout test report
https://openvex.dev/ns/v0.2.0 OpenVEX
...
各アテステーションは画像の特定の側面を説明するJSON文書です。検証のための最も重要な証言:
- SLSAの出自:ビルドソース、ビルダーアイデンティティ、ビルドプロセスの詳細
- SBOM:完全なソフトウェア部品表
- FIPS準拠:FIPS 140の証拠 -3 認証暗号モジュール
- STIGスキャン:セキュリティ技術実装ガイドのコンプライアンス結果
- 脆弱性スキャン:CVE評価
- VEXレポート: CVEの脆弱性
これらの認証は、サプライチェーンセキュリティのためのオープンフレームワークである in-toto 仕様に従っています。各証書には以下が含まれます:
- 件名:証言が記述していること(コンテナ画像)
- 前提:実際の請求内容(FIPS認証済み、STIG準拠など)
- 署名:ビルダーからの暗号署名
署名を自分でどうやって確認できるか見てみましょう。
Docker Scoutでの証明の検証
これから検証するアテスティネーションは、Dockerのビルドインフラストラクチャによって暗号的に署名されています。Docker Scoutは、公開鍵や証明書チェーンの管理を省くシンプルで統合されたアプローチを提供し、DHI認証をネイティブに処理します。アテステーションの検証を行うには、–verifyフラグを付け加え、明示的な検証フィードバックを提供します。このプロセスは暗号ハッシュに依存しており、ダイジェストは証明内容のハッシュなので、たった一文字の変更でもハッシュが完全に変わります。さらに、アテスケーションの署名は記述する特定の画像ダイジェストに暗号的にバインドされており、検証対象のメタデータが持っている画像と正確に一致していることを保証し、置換攻撃を防ぎます。
証明の取得
特定の証明(例えばSLSAの出所)を抽出するには、完全な述語タイプURIでattestation getコマンドを使用します。
docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
--predicate-type https://slsa.dev/provenance/v0.2 \
--output provenance.json
成功はこんな感じです:
✓ SBOM obtained from attestation, 32 packages found
✓ Provenance obtained from attestation
✓ Report written to provenance.json
チェックマークはDocker Scoutが認証を正常に取得・検証したことを確認します。舞台裏で、スカウトは次のように述べました:
- 認証署名はDockerの署名キーと一致しています
- 署名は期限切れしていません
- この証明書はこの特定の画像ダイジェストに適用されます
- 証明書は改ざんされていません
署名検証に失敗すると、Scoutはエラーを返し、証明ファイルを出力しません。利用可能な述語タイプについて詳しく知りたい方は 、DHIの検証ドキュメントをご覧ください。
SLSAの出自の検証
署名は証言が本物であることを証明します。画像の出所はどこ から来たかを示しています。
SLSA(Supply-chain Levels for Software Artifacts)は 、Google、Linux Foundation、その他の業界パートナーによって開発されたセキュリティフレームワークです。これは、SLSA 0 (保証なし)からSLSA 4 (最高保証)までのサプライチェーンセキュリティ成熟度のレベルを定義しています。
Docker Hardened ImagesはSLSA 3をターゲットとしており、以下を満たす必要があります。
- プロセスは完全にスクリプト化/自動化されています
- バージョン管理で定義されたすべてのビルドステップ
- ビルドサービスによって自動的に生成される出所
- プロヴィナンスには、ソース、ビルダー、ビルドのパラメータが含まれます
以前に抽出したSLSA provenance.jsonを用いて、ソースリポジトリとコミットハッシュを確認できます:
jq '.predicate.invocation.environment.github_repository' provenance.json
アウトプット：
"docker-hardened-images/definitions"
jq '.predicate.invocation.environment.github_sha1' provenance.json
アウトプット：
"698b367344efb3a7d443508782de331a84216ae4"
同様に、 GitHub Actionsのワークフロー がこの画像を生成した正確な内容も確認できます。
jq '.predicate.builder.id' provenance.json
アウトプット：
「https://github.com/docker-hardened-images/definitions/actions/runs/18930640220/試み/1」
DHIエンタープライズユーザー向け:高保証主張の検証
無料のハードエンドイメージはセキュリティのベストプラクティスに基づいて構築されていますが、DHIエンタープライズイメージはFedRAMP、HIPAA、財務監査に必要な特定の認証を備えています。これらの高保証の主張を検証する方法は以下の通りです。
FIPS 140-3 検証
FIPS(連邦情報処理標準) 140-3 は、暗号モジュールに関する米国政府の標準です。これは、ソフトウェアの暗号が連邦の要件に基づき独立した検査機関によってテスト・検証されていることを証明する認証と考えてください。
政府機関、金融機関、医療提供者向けのソフトウェアを構築する場合、FIPS準拠はしばしば必須です。FIPSがなければ、それらの環境でソフトウェアを使用できません!
画像にFIPS認証暗号が含まれているか確認してください:
docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
--predicate-type https://docker.com/dhi/fips/v0.1 \
--output fips-attestation.json
アウトプット：
{
"certification": "CMVP #4985",
"certificationUrl": "https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4985",
"name": "OpenSSL FIPS Provider",
"package": "pkg:dhi/openssl-provider-fips@3.1.2",
"standard": "FIPS 140-3",
"status": "active",
"sunsetDate": "2030-03-10",
"version": "3.1.2"
}
証明書番号(4985)が重要な要素です。これは公式 NISTのCMVPデータベースにある特定のFIPS検証を参照しています。
STIGコンプライアンス
STIG(セキュリティ技術実装ガイド)は、国防総省(DoD)がシステムのセキュリティチェックリストとして作成しています。これは、防衛や政府業務向けのソフトウェア展開に必要な包括的なセキュリティ構成標準です。
DHI画像はリリース前にSTIGスキャンを受けます。Dockerは、国防総省のGeneral OSセキュリティ要件ガイドに基づくカスタムSTIGを使用しています。各スキャンは数十のセキュリティ管理を確認し、結果を報告します。STIGスキャン結果を抽出してレビューできます:
docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
--predicate-type https://docker.com/dhi/stig/v0.1 \
--output stig-attestation.json
STIGスキャンの概要を確認してください:
jq '.predicate[0].summary' stig-attestation.json
アウトプット：
{
"failedChecks": 0,
"passedChecks": 91,
"notApplicableChecks": 107,
"totalChecks": 198,
"defaultScore": 100,
"flatScore": 91
}
これは、DHIが該当するすべてのSTIGコントロールを合格し、不正チェック 91 ゼロ、 100%スコアを記録したことを示しています。「notApplicableChecks」 107 は通常、特定の最小コンテナ環境やその構成には無関係なコントロールを指します。STIG制御およびDHIコンプライアンスの詳細の完全なリスト、完全なSTIGスキャンレポートの抽出方法および閲覧方法については、 DHI STIGドキュメントをご覧ください。
CISベンチマーク硬化
CIS(インターネットセキュリティセンター)ベンチマーク は、業界のセキュリティ専門家によって作成されるセキュリティ構成標準です。STIGと同様に、これらはコンセンサスのベストプラクティスを表していますが、政府が義務付けるフレームワーク(FIPS、STIG)とは異なり、CISベンチマークはコミュニティによって開発されています。
CIS準拠は法的に義務付けられていませんが、業界標準のセキュリティ慣行を遵守していることを示すものであり、顧客の信頼や監査準備に価値があります。
画像ラベルを通じてCIS準拠を確認することができます:
docker inspect <your-org-namespace>/dhi-node:24.11-debian13-fips | \
jq '.[0].Config.Labels["com.docker.dhi.compliance"]'
出力:「fips, stig, cis」
CISラベルは、 画像がCIS Docker Benchmarkに基づきハード化されていることを示します。
SBOMは具体的に何に使われているのでしょうか?
コンプライアンスの枠組みは、どの基準を満たすかを教えてくれます。SBOMは実際にコンテナの中身を教えてくれます。そこから本当のセキュリティ作業が始まります。
推移依存関係の識別
プロジェクトにパッケージを追加すると、直接依存関係が確認できます。見えないのは、そのパッケージの依存関係や 依存 関係などです。これが推移的依存問題です。
トランジティブ依存関係の脆弱性が、聞いたこともないとアプリケーション全体が危うくなります。実際の例として、Log4Shellの脆弱性は、Log4jが依存チェーンの何層も深く埋もれた推移的依存関係だったため、何百万ものアプリケーションに影響を与えました。
ほとんどの脆弱性は推移依存関係に隠れています。理由は以下の通りです:
- 開発者はその存在を知りません
- 直接依存関係が更新されるときには更新されません
- SBOMがなければスキャンツールは見逃してしまいます
最小限の画像がこのリスクを劇的に減らします。パッケージ数が少なければ、推移依存性が少なく、攻撃面が小さくなります。
依存数を比較する:
- 公式Node.js画像:321パッケージ、~1、依存関係500
- DHI Node.js画像: 32 パッケージ、~150 依存関係
パッケージの90%減少は推移的依存リスクの90%減少を意味します。
既知(悪用可能な)脆弱性のスキャン
SBOMを抽出した後、既知の脆弱性をスキャンします:
docker scout cves registry://<your-org-namespace>/dhi-node:24.11-debian13-fips
アウトプット：
Target: <your-org-namespace>/dhi-node:24.11-debian13-fips
0C 0H 0M 8L
8 vulnerabilities found in 2 packages
CRITICAL 0
HIGH 0
MEDIUM 0
LOW 8
重大、高、中程度の脆弱性はゼロです。Docker ScoutはSBOMを複数の脆弱性データベース(NVD、GitHubセキュリティアドバイザリーなど)と照合します。これが最小限の画像のメリットです。パッケージ数が少なければ、潜在的な脆弱性も少なくなります。公式Node.jsイメージには、クリティカル、ハイ、ミディアムの各 25 のセキュリティが記載されていました。強化版には実行可能な脆弱性が全くありません。これは脆弱性がパッチ適用されたからではなく、脆弱性パッケージが完全に削除されたからです。
VEXによるエクスプロイタビリティの理解
すべての CVE があなたのデプロイメントに関係しているわけではありません。アプリケーションが呼び出さないライブラリ関数の脆弱性や、実行されていないサービスの欠陥は、実際のリスクを生み出しません。Docker Hardened Imagesには、報告されたどの CVE が実際のランタイム文脈で悪用可能でないかを示す署名済み VEX アテスメントが含まれています。これにより、パッケージ内に存在する(報告されている)と 、実際に悪用可能な (このイメージでのパッケージの使い方から悪用可能)な CVE(悪用可能)を区別するのに役立ちます。言い換えれば、VEXは偽陽性を減らします。
|
Docker ScoutはDHIイメージをスキャンする際に自動的にVEX文を適用します:実行時に Docker Scout CVE (英語)Scoutは、非悪用とマークされた脆弱性を抑制するためにVEX認証を使用します。 |
以下のコマンドで評価されたCVEを確認できます:
docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
--predicate-type https://openvex.dev/ns/v0.2.0 \
--output vex.json
ライセンス遵守分析
オープンソースソフトウェアを使う場合、ライセンス条件に縛られます。一部のライセンス(MIT、Apache)は寛容で、商用製品でも自由に使用できます。一方(GPL、AGPL)はコピーレフトで、ソフトウェアを配布する場合はソースコードを公開することが求められます。
SBOMはライセンス遵守を可視化します。SBOMがなければ、コンテナに含まれているライセンスが見えなくなります。
SBOMをSPDX形式でエクスポートする:
docker scout sbom registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
--format spdx \
--output node-sbom-spdx.json
ライセンス配布の分析:
jq '.packages[].licenseConcluded' node-sbom-spdx.json | \
sort | uniq -c | sort -rn
アウトプット：
15 "MIT"
8 "Apache-2.0"
5 "GPL-2.0-or-later"
2 "BSD-3-Clause"
1 "OpenSSL"
1 "NOASSERTION"
この例では:
- ✅ MITとアパッチ2。0 は許容的(商業利用に安全)です。
- ⚠️ GPL-2。0-またはそれ以降レビューが必要(これはランタイム依存性ですか、それともビルドツールですか?)
- ⚠️ NOASERTIONは調査が必要だ
結論:あなたが証明したこと
Dockerがハードンドイメージについて主張する重要なセキュリティ主張を独自に検証しました:
- 真正性:暗号署名は画像が本物で改変されていないことを保証します
- 出所:SLSAの認証は公開リポジトリ内の特定のソースコミットまでビルドを追跡します
コンプライアンス:FIPS証明書、STIG管理に合格、CISベンチマークを達成 - 警備体制
検証したすべての請求(CISを除く)には対応する証明があり、自分で確認し、監査し、CI/CDパイプラインで検証できます。
Docker HubのUIを使って、あなたのニーズに合わせてDocker Hardened Image(DHI)をカスタマイズできます。これにより、ベースイメージの選択、パッケージの追加、OCIの成果物(カスタム証明書や追加ツールなど)の追加、設定の設定が可能になります。さらに、ビルドパイプラインはカスタマイズされたイメージが安全に構築され、証明も含まれていることを保証します。
パート 3では、先ほど説明した利点を維持しつつ、あなたのニーズに合わせてDockerの強化イメージをカスタマイズする方法を解説します。
DHIがセキュリティの約束を果たしていることを確認しましたね。次は稼働させる。
もし 1部を読んでいなければ、脆弱性の除去率 100%とパッケージ削減率 90%について話し合った内容を、 こちらのブログをご覧ください。
