Amazon Inspector Dockerfile チェック - Amazon Inspector
Sbomgen Dockerfile チェックの使用サポートされている Dockerfile チェック

Amazon Inspector Dockerfile チェック

このセクションでは、Amazon Inspector SBOM Generator を使用して Dockerfiles および Docker コンテナイメージをスキャンし、セキュリティの脆弱性を引き起こす設定ミスがないかどうか確認する方法について説明します。

Sbomgen Dockerfile チェックの使用

Dockerfile チェックは、Dockerfile または *.Dockerfile という名前のファイルが検出されたとき、および Docker イメージがスキャンされたときに自動的に実行されます。

--skip-scanners dockerfile 引数を使用して Dockerfile チェックを無効にすることができます。また、Dockerfile チェックを OS やサードパーティーパッケージなどの利用可能なスキャナーと組み合わせることもできます。

Docker チェックコマンドの例

次のコマンド例は、Dockerfiles と Docker コンテナイメージ、および OS とサードパーティーパッケージの SBOM を生成する方法を示しています。

# generate SBOM only containing Docker checks for Dockerfiles in a local directory
./inspector-sbomgen directory --path ./project/ --scanners dockerfile
            
# generate SBOM for container image will by default include Dockerfile checks
./inspector-sbomgen container --image image:tag

# generate SBOM only containing Docker checks for specific Dockerfiles and Alpine, Debian, and Rhel OS packages in a local directory
/inspector-sbomgen directory --path ./project/ --scanners dockerfile,dpkg,alpine-apk,rhel-rpm

# generate SBOM only containing Docker checks for specific Dockerfiles in a local directory
./inspector-sbomgen directory --path ./project/ --skip-scanners dockerfile
ファイルコンポーネントの例

以下は、ファイルコンポーネントの Dockerfile 検出結果の例です。

{
     "bom-ref": "comp-2",
      "name": "dockerfile:data/docker/Dockerfile",
      "properties": [
        {
          "name": "amazon:inspector:sbom_scanner:dockerfile_finding:IN-DOCKER-001",
          "value": "affected_lines:27-27"
        }
      ],
      "type": "file"
    },
脆弱性レスポンスコンポーネントの例

以下は、脆弱性レスポンスコンポーネントの Dockerfile 検出結果の例です。

{
      "advisories": [
        {
          "url": "https://docs.docker.com/develop/develop-images/instructions/"
        }
      ],
      "affects": [
        {
          "ref": "comp-2"
        }
      ],
      "analysis": {
        "state": "in_triage"
      },
      "bom-ref": "vuln-13",
      "created": "2024-03-27T14:36:39Z",
      "description": "apt-get layer caching: Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions to fail.",
      "id": "IN-DOCKER-001",
      "ratings": [
        {
          "method": "other",
          "severity": "info",
          "source": {
            "name": "AMAZON_INSPECTOR",
            "url": "https://aws.amazon.com/inspector/"
          }
        }
      ],
      "source": {
        "name": "AMAZON_INSPECTOR",
        "url": "https://aws.amazon.com/inspector/"
      },
      "updated": "2024-03-27T14:36:39Z"
    },
注記

--scan-sbom フラグなしで Sbomgen を呼び出すと、未加工の Dockerfile 検出結果のみを表示できます。

サポートされている Dockerfile チェック

Sbomgen Dockerfile チェックは、以下に対してサポートされています。

  • Sudo バイナリパッケージ

  • Debian APT ユーティリティ

  • ハードコーディングされたシークレット

  • ルートコンテナ

  • ランタイムの弱体化コマンドフラグ

  • ランタイムの弱体化環境変数

これらの各 Dockerfile チェックには、次のトピックの上部に記載されている、対応する重要度評価があります。

注記

以下のトピックで説明する推奨事項は、業界のベストプラクティスに基づいています。

Sudo バイナリパッケージ

注記

このチェックの重要度評価は、参考です。

Sudo バイナリパッケージには、予測不可能な TTY とシグナル転送動作があるため、これをインストールまたは使用することはお勧めしません。詳細については、Docker Docs ウェブサイトの「User」を参照してください。ユースケースで Sudo バイナリパッケージと同様の機能が必要な場合は、Gosu を使用することをお勧めします。

Debian APT ユーティリティ

注記

このチェックの重要度評価は、高です。

以下は、Debian APT ユーティリティを使用するためのベストプラクティスです。

キャッシュの問題を回避するために 1 つの Run ステートメントに apt-get コマンドを組み合わせる

Docker コンテナ内の単一の RUN ステートメントに apt-get コマンドを組み合わせることをお勧めします。単独で apt-get update を使用すると、キャッシュの問題が発生し、その後の apt-get install の手順が失敗します。詳細については、Docker Docs ウェブサイトの「apt-get」を参照してください。

注記

Docker コンテナソフトウェアが古い場合、説明されているキャッシュ動作は Docker コンテナコンテナ内でも発生する可能性があります。

非インタラクティブ方式での APT コマンドラインユーティリティの使用

APT コマンドラインユーティリティをインタラクティブに使用することをお勧めします。APT コマンドラインユーティリティはエンドユーザーツールとして設計されており、その動作はバージョンごとに変わります。詳細については、Debian ウェブサイトの「Script Usage and differences from other APT tools」を参照してください。

ハードコーディングされたシークレット

注記

このチェックの重要度評価は、緊急です。

Dockerfile の機密情報はハードコーディングされたシークレットと見なされます。以下のハードコーディングされたシークレットは、Sbomgen Docker ファイルチェックを通じて識別できます。

  • AWS アクセスキー ID – AKIAIOSFODNN7EXAMPLE

  • AWS シークレットキー - wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

  • DockerHub 個人用のアクセストークン – dckr_pat_thisisa27charexample1234567

  • GitHub 個人用のアクセストークン – ghp_examplev61wY7Pj1YnotrealUoY123456789

  • GitLab 個人用のアクセストークン – glpat-12345example12345678

ルートコンテナ

注記

このチェックの重要度マーカーは、参考です。

ルート権限なしで Docker コンテナを実行することをお勧めします。ルート権限なしでは実行できないコンテナ化されたワークロードの場合、最小限の権限の原則を使用してアプリケーションを構築することをお勧めします。詳細については、Docker Docs ウェブサイトの「User」を参照してください。

ランタイムの弱体化環境変数

注記

このチェックの重要度評価は、高です。

いくつかのコマンドラインユーティリティまたはプログラミング言語ランタイムは、安全なデフォルト設定のバイパスをサポートしているため、安全でないメソッドを通じた実行が許可されます。

NODE_TLS_REJECT_UNAUTHORIZED=0

NODE_TLS_REJECT_UNAUTHORIZED を 0 に設定して Node.js プロセスを実行すると、TLS 証明書の検証は無効になります。詳細については、Node.js ウェブサイトの「NODE_TLS_REJECT_UNAUTHORIZED=0」を参照してください。

GIT_SSL_NO_VERIFY=*

GIT_SSL_NO_VERIFY を設定して git コマンドラインプロセスを実行すると、Git は TLS 証明書の検証をスキップします。詳細については、Git ウェブサイトの「Environment variables」を参照してください。

PIP_TRUSTED_HOST=*

PIP_TRUSTED_HOST を設定して Python pip コマンドラインプロセスを実行すると、Pip は指定されたドメインでの TLS 証明書の検証をスキップします。詳細については、Pip ウェブサイトの「--trusted-host」を参照してください。

NPM_CONFIG_STRICT_SSL=false

NPM_CONFIG_STRICT_SSL を false に設定して Node.js npm コマンドラインプロセスを実行すると、Node Package Manager (npm) ユーティリティは TLS 証明書を検証せずに NPM レジストリに接続します。詳細については、npm Docs ウェブサイトの「strict-ssl」を参照してください。

ランタイムの弱体化コマンドフラグ

注記

このチェックの重要度評価は、高です。

ランタイムの弱体化環境変数と同様に、いくつかのコマンドラインユーティリティやプログラミング言語ランタイムは、安全なデフォルト設定をバイパスすることをサポートしているため、安全でないメソッドを通じた実行が許可されます。

npm ––strict-ssl=false

--strict-ssl=false フラグを使用して Node.js npm コマンドラインプロセスを実行すると、Node Package Manager (npm) ユーティリティは TLS 証明書を検証せずに NPM レジストリに接続します。詳細については、npm Docs ウェブサイトの「strict-ssl」を参照してください。

apk ––allow-untrusted

--allow-untrusted フラグを使用して Alpine Package Keeper ユーティリティを実行すると、apk は、署名がないか信頼できない署名を持つパッケージをインストールします。詳細については、Apline ウェブサイトで以下のリポジトリを参照してください。

apt-get ––allow-unauthenticated

--allow-unauthenticated フラグを使用して Debian apt-get パッケージユーティリティを 実行した場合、apt-get はパッケージの有効性を確認しません。詳細については、Debian ウェブサイトの「APT-Get(8)」を参照してください。

pip ––trusted-host

--trusted-host フラグを使用して Python pip ユーティリティを実行すると、指定されたホスト名は TLS 証明書の検証をバイパスします。詳細については、Pip ウェブサイトの「--trusted-host」を参照してください。

rpm ––nodigest, ––nosignature, ––noverify, ––nofiledigest

--nodigest、--nosignature、--noverify、および --nofiledigest フラグを使用して RPM ベースのパッケージマネージャー rpm を実行すると、RPM パッケージマネージャーはパッケージのインストール時にパッケージヘッダー、署名、またはファイルを検証しません。詳細については、RPM ウェブサイトの「RPM manual page」を参照してください。

yum-config-manager ––setopt=sslverify false

--setopt=sslverify フラグを false に設定して RPM ベースのパッケージマネージャー yum-config-manager を実行すると、YUM パッケージマネージャーは TLS 証明書を検証しません。詳細については、Man7 ウェブサイトの「YUM manual page」を参照してください。

yum ––nogpgcheck

--nogpgcheck フラグを使用して RPM ベースのパッケージマネージャー yum を実行すると、YUM パッケージマネージャーはパッケージの GPG 署名の確認をスキップします。詳細については、Man7 ウェブサイトの「yum(8)」を参照してください。

curl ––insecure, curl –k

--insecure または -k フラグを使用して curl を実行すると、TLS 証明書の検証は無効になります。デフォルトでは、curl が行うすべての安全な接続は、転送が実行される前に安全であることが検証されます。このオプションでは、curl は検証ステップをスキップし、チェックせずに続行します。詳細については、Curl ウェブサイトの「Curl manual page」を参照してください。

wget ––no-check-certificate

--no-check-certificate フラグを使用して wget を実行すると、TLS 証明書の検証は無効になります。詳細については、GNU ウェブサイトの「Wget manual page」を参照してください。

コンテナ内の OS パッケージデータベースの削除チェック

注記

このチェックの重要度評価は、参考です。

オペレーティングシステムパッケージのデータベースを削除すると、コンテナイメージがソフトウェアの完全なインベントリをスキャンする機能が低下します。コンテナのビルドステップ中、これらのデータベースは削除しないでください。

OS パッケージデータベースの削除チェックは、次のパッケージマネージャーでサポートされています。

Alpine Package Keeper (APK)

インストールされたソフトウェアの APK パッケージマネージャーを使用するコンテナイメージは、ビルド中に APK システムファイルが削除されないようにする必要があります。詳細については、 Arch Linux ウェブサイトの APK manpages システムファイルのドキュメントを参照してください。

Debian Package Manager (DPKG)

Debian、Ubuntu、Distroless ベースのイメージなど、DPKG パッケージマネージャーを使用するコンテナは、コンテナのビルド中に DPKG データベースが削除されないようにする必要があります。詳細については、 Ubuntu ウェブサイトの DPKG manpages システムファイルのドキュメントを参照してください。

RPM Package Manager (RPM)

Amazon Linux や Red Hat Enterprise Linux など、RPM Package Manager (yum/dnf) を使用するコンテナは、コンテナのビルドに RPM データベースが削除されないようにする必要があります。詳細については、 RPM ウェブサイトの RPM manpages システムファイルのドキュメントを参照してください。