翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Inspector Dockerfile チェック
このセクションでは、Amazon Inspector SBOM Generator を使用して Dockerfiles および Docker コンテナイメージをスキャンし、セキュリティの脆弱性を引き起こす設定ミスがないかどうか確認する方法について説明します。
**Topics**
+ [Sbomgen Dockerfile チェックの使用](#w2aac39c13b7)
+ [サポートされている Dockerfile チェック](#w2aac39c13b9)
## 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](https://docs.docker.com/build/building/best-practices/#user)」を参照してください。ユースケースで Sudo バイナリパッケージと同様の機能が必要な場合は、[Gosu](https://github.com/tianon/gosu) を使用することをお勧めします。
### Debian APT ユーティリティ
**注記**
このチェックの重要度評価は、**高**です。
以下は、Debian APT ユーティリティを使用するためのベストプラクティスです。
**キャッシュの問題を回避するために 1 つの `Run` ステートメントに `apt-get` コマンドを組み合わせる**
Docker コンテナ内の単一の RUN ステートメントに `apt-get` コマンドを組み合わせることをお勧めします。単独で `apt-get update` を使用すると、キャッシュの問題が発生し、その後の `apt-get install` の手順が失敗します。詳細については、Docker Docs ウェブサイトの「[apt-get](https://docs.docker.com/build/building/best-practices/#apt-get)」を参照してください。
**注記**
Docker コンテナソフトウェアが古い場合、説明されているキャッシュ動作は Docker コンテナコンテナ内でも発生する可能性があります。
**非インタラクティブ方式での APT コマンドラインユーティリティの使用**
APT コマンドラインユーティリティをインタラクティブに使用することをお勧めします。APT コマンドラインユーティリティはエンドユーザーツールとして設計されており、その動作はバージョンごとに変わります。詳細については、Debian ウェブサイトの「[Script Usage and differences from other APT tools](https://manpages.debian.org/stretch/apt/apt.8.en.html#SCRIPT_USAGE_AND_DIFFERENCES_FROM_OTHER_APT_TOOLS)」を参照してください。
### ハードコーディングされたシークレット
**注記**
このチェックの重要度評価は、**緊急**です。
Dockerfile の機密情報はハードコーディングされたシークレットと見なされます。以下のハードコーディングされたシークレットは、Sbomgen Docker ファイルチェックを通じて識別できます。
+ AWS アクセスキー IDs – `AKIAIOSFODNN7EXAMPLE`
+ AWS シークレットキー – `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`
+ DockerHub 個人用のアクセストークン – `dckr_pat_thisisa27charexample1234567`
+ GitHub 個人用のアクセストークン – `ghp_examplev61wY7Pj1YnotrealUoY123456789`
+ GitLab 個人用のアクセストークン – `glpat-12345example12345678`
### ルートコンテナ
**注記**
このチェックの重要度マーカーは、**参考**です。
ルート権限なしで Docker コンテナを実行することをお勧めします。ルート権限なしでは実行できないコンテナ化されたワークロードの場合、最小限の権限の原則を使用してアプリケーションを構築することをお勧めします。詳細については、Docker Docs ウェブサイトの「[User](https://docs.docker.com/build/building/best-practices/#user)」を参照してください。
### ランタイムの弱体化環境変数
**注記**
このチェックの重要度評価は、**高**です。
いくつかのコマンドラインユーティリティまたはプログラミング言語ランタイムは、安全なデフォルト設定のバイパスをサポートしているため、安全でないメソッドを通じた実行が許可されます。
**NODE\_TLS\_REJECT\_UNAUTHORIZED=0**
`NODE_TLS_REJECT_UNAUTHORIZED` を `0` に設定して Node.js プロセスを実行すると、TLS 証明書の検証は無効になります。詳細については、Node.js ウェブサイトの「[NODE\_TLS\_REJECT\_UNAUTHORIZED=0](https://nodejs.org/api/cli.html#node_tls_reject_unauthorizedvalue)」を参照してください。
**GIT\_SSL\_NO\_VERIFY=\***
`GIT_SSL_NO_VERIFY` を設定して git コマンドラインプロセスを実行すると、Git は TLS 証明書の検証をスキップします。詳細については、Git ウェブサイトの「[Environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables)」を参照してください。
**PIP\_TRUSTED\_HOST=\***
`PIP_TRUSTED_HOST` を設定して Python pip コマンドラインプロセスを実行すると、Pip は指定されたドメインでの TLS 証明書の検証をスキップします。詳細については、Pip ウェブサイトの「[--trusted-host](https://pip.pypa.io/en/stable/cli/pip/#cmdoption-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](https://docs.npmjs.com/cli/v10/using-npm/config#strict-ssl)」を参照してください。
### ランタイムの弱体化コマンドフラグ
**注記**
このチェックの重要度評価は、**高**です。
ランタイムの弱体化環境変数と同様に、いくつかのコマンドラインユーティリティやプログラミング言語ランタイムは、安全なデフォルト設定をバイパスすることをサポートしているため、安全でないメソッドを通じた実行が許可されます。
**`npm ––strict-ssl=false`**
`--strict-ssl=false` フラグを使用して Node.js npm コマンドラインプロセスを実行すると、Node Package Manager (npm) ユーティリティは TLS 証明書を検証せずに NPM レジストリに接続します。詳細については、npm Docs ウェブサイトの「[strict-ssl](https://docs.npmjs.com/cli/v10/using-npm/config#strict-ssl)」を参照してください。
**`apk ––allow-untrusted`**
`--allow-untrusted` フラグを使用して Alpine Package Keeper ユーティリティを実行すると、`apk` は、署名がないか信頼できない署名を持つパッケージをインストールします。詳細については、Apline ウェブサイトで[以下のリポジトリ](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/f9eaeb6429325eeb5a17ed771fd477be9227fe15/doc/apk.8.scd#L114-115)を参照してください。
**`apt-get ––allow-unauthenticated`**
`--allow-unauthenticated` フラグを使用して Debian `apt-get` パッケージユーティリティを 実行した場合、`apt-get` はパッケージの有効性を確認しません。詳細については、Debian ウェブサイトの「[APT-Get(8)](https://manpages.debian.org/stretch/apt/apt-get.8.en.html)」を参照してください。
**`pip ––trusted-host`**
`--trusted-host` フラグを使用して Python pip ユーティリティを実行すると、指定されたホスト名は TLS 証明書の検証をバイパスします。詳細については、Pip ウェブサイトの「[--trusted-host](https://pip.pypa.io/en/stable/cli/pip/#cmdoption-trusted-host)」を参照してください。
**`rpm ––nodigest, ––nosignature, ––noverify, ––nofiledigest`**
`--nodigest`、`--nosignature`、`--noverify`、および `--nofiledigest` フラグを使用して RPM ベースのパッケージマネージャー `rpm` を実行すると、RPM パッケージマネージャーはパッケージのインストール時にパッケージヘッダー、署名、またはファイルを検証しません。詳細については、RPM ウェブサイトの「[RPM manual page](https://rpm-software-management.github.io/rpm/man/)」を参照してください。
**`yum-config-manager ––setopt=sslverify false`**
`--setopt=sslverify` フラグを false に設定して RPM ベースのパッケージマネージャー `yum-config-manager` を実行すると、YUM パッケージマネージャーは TLS 証明書を検証しません。詳細については、Man7 ウェブサイトの「[YUM manual page](https://man7.org/linux/man-pages/man5/yum.conf.5.html)」を参照してください。
**`yum ––nogpgcheck`**
`--nogpgcheck` フラグを使用して RPM ベースのパッケージマネージャー `yum` を実行すると、YUM パッケージマネージャーはパッケージの GPG 署名の確認をスキップします。詳細については、Man7 ウェブサイトの「[yum(8)](https://man7.org/linux/man-pages/man8/yum.8.html)」を参照してください。
**`curl ––insecure, curl –k`**
`--insecure` または `-k` フラグを使用して `curl` を実行すると、TLS 証明書の検証は無効になります。デフォルトでは、`curl` が行うすべての安全な接続は、転送が実行される前に安全であることが検証されます。このオプションでは、`curl` は検証ステップをスキップし、チェックせずに続行します。詳細については、Curl ウェブサイトの「[Curl manual page](https://curl.se/docs/manpage.html#-k)」を参照してください。
**`wget ––no-check-certificate`**
`--no-check-certificate` フラグを使用して `wget` を実行すると、TLS 証明書の検証は無効になります。詳細については、GNU ウェブサイトの「[Wget manual page](https://www.gnu.org/software/wget/manual/wget.html#index-SSL-certificate_002c-check)」を参照してください。
### コンテナ内の OS パッケージデータベースの削除チェック
**注記**
このチェックの重要度評価は、**参考**です。
オペレーティングシステムパッケージのデータベースを削除すると、コンテナイメージがソフトウェアの完全なインベントリをスキャンする機能が低下します。コンテナのビルドステップ中、これらのデータベースは削除しないでください。
OS パッケージデータベースの削除チェックは、次のパッケージマネージャーでサポートされています。
**Alpine Package Keeper (APK)**
インストールされたソフトウェアの APK パッケージマネージャーを使用するコンテナイメージは、ビルド中に APK システムファイルが削除されないようにする必要があります。詳細については、Arch Linux ウェブサイトの [APK manpages](https://man.archlinux.org/man/apk.8.en#System_files) システムファイルのドキュメントを参照してください。
**Debian Package Manager (DPKG)**
Debian、Ubuntu、Distroless ベースのイメージなど、DPKG パッケージマネージャーを使用するコンテナは、コンテナのビルド中に DPKG データベースが削除されないようにする必要があります。詳細については、Ubuntu ウェブサイトの [DPKG manpages](https://manpages.ubuntu.com/manpages/trusty/man1/dpkg.1.html#files) システムファイルのドキュメントを参照してください。
**RPM Package Manager (RPM)**
Amazon Linux や Red Hat Enterprise Linux など、RPM Package Manager (yum/dnf) を使用するコンテナは、コンテナのビルドに RPM データベースが削除されないようにする必要があります。詳細については、 RPM ウェブサイトの [RPM manpages](https://rpm-software-management.github.io/rpm/man/rpm-common.8#FILES) システムファイルのドキュメントを参照してください。