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

Amazon Inspector Dockerfile チェック

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

トピック

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

Dockerfile Sbomgen チェックの使用

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

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

Docker チェックコマンドの例

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


# 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 ウェブサイトの「ユーザー」を参照してください。ユースケースで 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 ウェブサイトのスクリプトの使用状況と他のAPTツールとの違いを参照してください。

ハードコードされたシークレット

注記

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

Dockerfile の機密情報はハードコードされたシークレットと見なされます。Sbomgen Docker ファイルチェックでは、次のハードコードされたシークレットを特定できます。

AWS アクセスキー IDs – AKIAIOSFODNN7EXAMPLE
DockerHub 個人用アクセストークン – dckr_pat_thisisa27charexample1234567
GitHub 個人用アクセストークン – ghp_examplev61wY7Pj1YnotrealUoY123456789
GitLab 個人用アクセストークン – glpat-12345example12345678

ルートコンテナ

注記

このチェックの重要度マーカーは情報です。

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

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

注記

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

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

NODE_TLSREJECT__UNAUTHORIZED=0

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

GIT_SSL_NO_VERIFY=*

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

PIP_TRUSTED_HOST=*

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

NPM_CONFIG_STRICT_SSL=false

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

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

注記

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

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

`npm ––strict-ssl=false`

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

`apk ––allow-untrusted`

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

`apt-get ––allow-unauthenticated`

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

`pip ––trusted-host`

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

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

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

`yum-config-manager ––setopt=sslverify false`

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

`yum ––nogpgcheck`

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

`curl ––insecure, curl –k`

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

`wget ––no-check-certificate`

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

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

以前のバージョン

カスタム CI/CD 統合の作成

Amazon Inspector Dockerfile チェック

トピック

Dockerfile Sbomgen チェックの使用

Docker チェックコマンドの例

ファイルコンポーネントの例

脆弱性レスポンスコンポーネントの例

注記

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

注記

Sudo バイナリパッケージ

注記

Debian APT ユーティリティ

注記

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

注記

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

ハードコードされたシークレット

注記

ルートコンテナ

注記

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

注記

NODE_TLSREJECT__UNAUTHORIZED=0

GIT_SSL_NO_VERIFY=*

PIP_TRUSTED_HOST=*

NPM_CONFIG_STRICT_SSL=false

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

注記

npm ––strict-ssl=false

apk ––allow-untrusted

apt-get ––allow-unauthenticated

pip ––trusted-host

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

yum-config-manager ––setopt=sslverify false

yum ––nogpgcheck

curl ––insecure, curl –k

wget ––no-check-certificate

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

`npm ––strict-ssl=false`

`apk ––allow-untrusted`

`apt-get ––allow-unauthenticated`

`pip ––trusted-host`

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

`yum-config-manager ––setopt=sslverify false`

`yum ––nogpgcheck`

`curl ––insecure, curl –k`

`wget ––no-check-certificate`