不平不満
0.83.0
コンテナイメージとファイルシステムの脆弱性スキャナー。バイナリを簡単にインストールして試してください。コンテナイメージおよびファイルシステム用の強力な SBOM (ソフトウェア部品表) ツールである Syft と連携します。
カレンダー: https://calendar.google.com/calendar/u/0/r?cid=Y182OTM4dGt0MjRtajI0NnNzOThiaGtnM29qNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t
アジェンダ: https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing (書き込みアクセスするにはこのグループに参加してください)
どなたでも大歓迎です！
Syft または Grype の商用サポート オプションについては、Anchore にお問い合わせください。
コンテナ イメージまたはファイル システムの内容をスキャンして、既知の脆弱性を見つけます。
主要なオペレーティング システム パッケージの脆弱性を見つけます。
高山
アマゾン・リナックス
ビジーボックス
CentOS
CBL-マリナー
デビアン
ディストロレス
オラクル・リナックス
レッドハット (RHEL)
Ubuntu
ウォルフィ
言語固有のパッケージの脆弱性を見つけます。
ルビー (宝石)
Java (JAR、WAR、EAR、JPI、HPI)
JavaScript (NPM、Yarn)
Python (Egg、Wheel、Poetry、requirements.txt/setup.py ファイル)
ドットネット (deps.json)
Golang (go.mod)
PHP (コンポーザー)
錆び（貨物）
Docker、OCI、Singularity のイメージ形式をサポートします。
スキャン結果のフィルタリングと拡張のための OpenVEX サポート。
問題が発生した場合は、問題トラッカーを使用してお知らせください。
カール -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
インストール スクリプト オプション:
-b : カスタム インストール ディレクトリを指定します (デフォルトは./bin )。
-d : より詳細なログ レベル (デバッグの場合は-d 、トレースの場合は-dd )
-v : インストール前にダウンロードしたアーティファクトの署名を検証します ( cosignインストールする必要があります)
チョコレートのようなグライプの配布はコミュニティによって管理されており、アンカー チームによって配布されるものではありません。
チョコインストール grype -y
ブリュータップアンカレ/グリュプ 醸造インストールGrype
macOS では、コミュニティが管理するポートから MacPorts 経由で Grype を追加インストールできます。
sudoポートでGrypeをインストール
注: 現在、Grype は macOS と Linux 向けにのみ構築されています。
ソースからビルドして実行する手順については、DEVELOPING.md を参照してください。
GitHub Actions を使用している場合は、Grype ベースのアクションを使用して、CI ワークフロー中にコードまたはコンテナー イメージの脆弱性スキャンを実行できます。
チェックサムはすべてのアーティファクトに適用され、結果のチェックサム ファイルは余署名を使用して署名されます。
署名を検証するには次のツールが必要です。
連署
検証手順は次のとおりです。
必要なファイルと、checksums.txt、checksums.txt.pem、および checksums.txt.sig ファイルをリリース ページからダウンロードします。
署名を検証します。
cosign verify-blob--certificate --signature --certificate-identity-regexp 'https://github.com/anchore/grype/.github/workflows/.+' --certificate-oidc-issuer "https://token.actions.githubusercontent.com"
署名が有効であることが確認されたら、SHA256 合計がダウンロードされたアーティファクトと一致していることの検証に進むことができます。
sha256sum --ignore-missing -c checksums.txt
バイナリをインストールし、パスでgrypeが利用できることを確認してください。イメージ内の脆弱性をスキャンするには:
grype
上記のコマンドは、コンテナー内に表示される脆弱性 (つまり、イメージの潰れた表現) をスキャンします。最終イメージに存在するかどうかに関係なく、すべてのイメージ層のソフトウェアを脆弱性スキャンに含めるには、 --scope all-layers指定します。
grype--scope all-layers
Docker コンテナから grype を実行して、実行中のコンテナをスキャンできるようにするには、次のコマンドを使用します。
docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock --name Grype アンカー/grype:latest $(ImageName):$(ImageTag)
Grype は、Docker にあるもの以外のさまざまなソースをスキャンできます。
# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands) grype path/to/image.tar # scan a Singularity Image Format (SIF) container grype path/to/image.sif # scan a directory grype dir:path/to/dir
ソースはスキームを使用して明示的に提供できます。
podman:yourrepo/yourimage:tag use images from the Podman daemon docker:yourrepo/yourimage:tag use images from the Docker daemon docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save" oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise) oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise) singularity:path/to/yourimage.sif read directly from a Singularity Image Format (SIF) container on disk dir:path/to/yourproject read directly from a path on disk (any directory) file:path/to/yourfile read directly from a file on disk sbom:path/to/syft.json read Syft JSON from path on disk registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
イメージ ソースが提供されず、指定された参照から検出できない場合は、イメージを Docker デーモンからプルする必要があると想定されます。 docker が存在しない場合は、次に Podman デーモンが試行され、最後にイメージ レジストリに直接アクセスします。
このデフォルトの動作はdefault-image-pull-source構成オプションでオーバーライドできます (詳細については、「構成」を参照してください)。
Grype での脆弱性スキャンをさらに高速化するには、SBOM を使用します。
# Then scan for new vulnerabilities as frequently as needed grype sbom:./sbom.json # (You can also pipe the SBOM into Grype) cat ./sbom.json | grype
Grype は、Syft、SPDX、および CycloneDX SBOM 形式の入力をサポートしています。 Syft がこれらのファイル タイプのいずれかを生成した場合、Grype で適切に動作するための適切な情報が必要です。他のツールで生成された SBOM を使用することもでき、成功の度合いは異なります。 Grype マッチングをより成功させる 2 つの点は、CPE と Linux ディストリビューション情報を含めることです。 SBOM に CPE 情報が含まれていない場合は、 --add-cpes-if-noneフラグを使用してパッケージ情報に基づいて CPE 情報を生成できます。ディストリビューションを指定するには、 --distro フラグを使用します。完全な例は次のとおりです。
grype --add-cpes-if-none --distro alpine:3.10 sbom:some-alpine-3.10.spdx.json
v0.40.1 より前のバージョンの Grype はサポートされていません。サポートされていないリリースでは、ソフトウェアのアップデートや脆弱性データベースのアップデートは提供されません。以前のリリースの vunnel を使用してアップストリーム データを収集し、grype-db を使用してサポートされていないスキーマ用のデータベースを構築することで、サポートされていない Grype リリース用の脆弱性データベースを引き続き構築できます。
Grype は、stdin 経由の入力として SBOM のスキャンをサポートしています。ユーザーは、cosign を使用して、SBOM をコンテンツとして持つ証明書を検証し、イメージの脆弱性をスキャンできます。
COSIGN_EXPERIMENTAL=1 cosign verify-attestation caphill4/java-spdx-tools:latest | jq -r .payload | base64 --decode | jq -r .predicate.Data | grype
{ "脆弱性": { ...
}, "関連する脆弱性": [ ...
]、"matchDetails": [ ...
]、「アーティファクト」: { ...
}
}脆弱性: 直接一致した特定の脆弱性に関するすべての情報 (例: ID、重大度、CVSS スコア、修正情報、詳細情報へのリンク)
関連する脆弱性: 報告された主な脆弱性に関連することが判明した脆弱性に関する情報。おそらく、私たちが照合した脆弱性は、(権威ある国家脆弱性データベース内に) 上流の CVE を持つ GitHub セキュリティ アドバイザリでした。このような場合、上流の脆弱性をここにリストします。
MatchDetails : このセクションでは、一致を探すときに検索した内容と、一致につながるパッケージと脆弱性の正確な詳細について説明します。
Artifact : これは、パッケージについてわかっている情報のサブセットです (Syft json 出力と比較すると、メタデータ セクションが要約されます)。これには、コンテナ イメージまたはディレクトリ内のどこでパッケージが見つかったのか、パッケージの種類、ライセンス情報、pURL、CPE などに関する情報が含まれています。
Grype は、1 つ以上の--excludeパラメータを指定した glob 式を使用して、ソース内のファイルとパスをスキャンから除外できます。
grype--exclude './out/**/*.json' --exclude /etc
注:イメージ スキャンの場合、ファイル システム全体がスキャンされるため、 /etcまたは/usr/**/*.txtのような絶対パスを使用できますが、ディレクトリ スキャンでは、指定されたディレクトリに関連するファイルが除外されます。例: --exclude ./package.jsonを使用して/usr/fooスキャンすると、 /usr/foo/package.json package.json が除外され、 --exclude '**/package.json'では、 /usr/fooにあるすべてのpackage.jsonファイルが除外されます。 /usr/foo 。ディレクトリ スキャンの場合は、パス式を./ 、または**/で始める必要があります。これらはすべて、指定され*/スキャン ディレクトリを基準にして解決されます。シェルはワイルドカードを展開しようとする可能性があるため、それらのパラメータは'**/*.json'のように一重引用符で囲むようにしてください。
Grype は、脆弱性照合の忠実度を高めるために外部データ ソースを組み込むように構成できます。この機能は現在デフォルトで無効になっています。この機能を有効にするには、以下を grype 設定に追加します。
外部ソース: 有効: true maven: search-upstream-by-sha1: true ベース URL: https://repo1.maven.org/maven2
Maven エンドポイントとして別のレジストリを使用している場合は、base-url を構成することもできます。
Grype の出力形式も構成可能です。
grype-o
利用可能な形式は次のとおりです。
table : 縦棒形式の概要 (デフォルト)。
cyclonedx : CycloneDX 1.6 仕様に準拠した XML レポート。
cyclonedx-json : CycloneDX 1.6 仕様に準拠した JSON レポート。
json : これを使用して、Grype からできるだけ多くの情報を取得します。
sarif : SARIF レポート (静的解析結果交換形式) を取得するには、このオプションを使用します。
template : ユーザーが出力形式を指定できるようにします。以下の「テンプレートの使用」を参照してください。
Grype では、Go テンプレートを使用してカスタム出力形式を定義できます。仕組みは次のとおりです。
形式を Go テンプレートとして定義し、このテンプレートをファイルとして保存します。
出力形式を「テンプレート」( -o template )に設定します。
テンプレート ファイルへのパスを指定します ( -t ./path/to/custom.template )。
Grype のテンプレート処理では、 json出力形式と同じデータ モデルが使用されます。そのため、テンプレートを作成するときにどのようなデータが利用できるのか疑問に思っている場合は、 grype の出力を参照として使用できます。
注意:テンプレートは、環境変数など、テンプレートが実行されているシステムに関する情報にアクセスできます。信頼できないテンプレートは決して実行しないでください。
Grype ソースのテンプレート ディレクトリには、カスタム出力形式の開始点として機能するサンプル テンプレートがいくつかあります。たとえば、csv.tmpl は CSV (カンマ区切り値) 形式で脆弱性レポートを生成します。
"Package","Version Installed","Vulnerability ID","Severity"
"coreutils","8.30-3ubuntu2","CVE-2016-2781","Low"
"libc-bin","2.31-0ubuntu9","CVE-2016-10228","Negligible"
"libc-bin","2.31-0ubuntu9","CVE-2020-6096","Low"
...デフォルトの「テーブル」出力形式のテンプレートも同じ場所にあります。
Grype には、デフォルトの golang テキスト/テンプレートとは別に、sprig の膨大なユーティリティ テンプレート関数も含まれており、ユーザーが Grype からの出力をカスタマイズできるようになります。
指定した重大度レベル以上の脆弱性が報告された場合、Grype をエラーで終了させることができます。これは、スクリプトまたは CI パイプライン内で Grype を使用するときに便利です。これを行うには、 --fail-on CLI フラグを使用します。
たとえば、 ubuntu:latestイメージで重大度が「中」以上の脆弱性が見つかった場合に、CI パイプライン障害をトリガーする方法は次のとおりです。
grype ubuntu:latest --fail-on medium
Grype が誤検知を報告したり、見たくないその他の脆弱性の一致を確認した場合は、Grype 設定ファイル (例: ~/.grype.yaml )。これにより、Grype は無視ルールで指定された基準を満たす脆弱性の一致を報告しなくなります。
各ルールでは、次の基準を任意に組み合わせて指定できます。
脆弱性 ID (例: "CVE-2008-4318" )
名前空間 (例: "nvd" )
修正状態 (許可される値: "fixed" 、 "not-fixed" 、 "wont-fix" 、または"unknown" )
パッケージ名 (例: "libcurl" )
パッケージのバージョン (例: "1.5.1" )
パッケージ言語 (例: "python" ; これらの値はここで定義されます)
パッケージタイプ (例: "npm" ; これらの値はここで定義されています)
パッケージの場所 (例: "/usr/local/lib/node_modules/**" ; glob パターンをサポート)
以下に、無視ルールの予期される形式を示す~/.grype.yamlの例を示します。
ignore: # これは、サポートされているルール フィールドの完全なセットです。 - 脆弱性: CVE-2008-4318 fix-state: 不明 # Grype が vex データを読み取るときに VEX フィールドが適用されます: vex-status: not_affected vex-justification:vulnerable_code_not_present package: name: libcurl version: 1.5.1 type: npm location: "/ usr/local/lib/node_modules/**" # 脆弱性 ID だけで一致するルールを作成できます。 - 脆弱性: CVE-2014-54321 # ...または単一のパッケージ フィールドによって: - パッケージ: タイプ: gem
一致にルールが適用される場合、脆弱性の一致は無視されます。ルールで指定されたすべてのフィールドが脆弱性の一致に適用される場合にのみ、ルールは特定の脆弱性の一致に適用されると見なされます。
無視ルールを指定して Grype を実行すると、「無視」された脆弱性の一致に対して次のことが起こります。
無視された一致は、 jsonまたはtemplate出力形式を使用する場合を除き、Grype の出力から完全に隠されます。ただし、これら 2 つの形式では、無視された一致は既存のmatches配列フィールドから削除され、新しいignoredMatches配列フィールドに配置されます。リストされた各無視された一致には、追加フィールドappliedIgnoreRulesもあり、これは Grype がこの脆弱性の一致を無視する原因となったルールの配列です。
--fail-on を使用する場合、無視された一致は Grype の終了ステータスの決定に考慮されません。たとえば、ユーザーが--fail-on critical指定し、「クリティカル」重大度で見つかったすべての脆弱性の一致が無視された場合、Grype はゼロで終了します。
注:誤検知が見つかった場合は、引き続き報告してください。たとえ無視ルールを使用して誤検知を確実に除外できたとしても、Grype の誤検知についてできるだけ多くの知識があれば、Grype コミュニティにとって非常に役立ちます。これは、Grype を継続的に改善するのに役立ちます。
修正が確認されている脆弱性のみを Grype に報告させたい場合は、 --only-fixedフラグを使用できます。 (これにより、Grype の設定に無視ルールが自動的に追加され、修正されていない脆弱性は無視されます。)
たとえば、Alpine 3.10 のスキャンは次のとおりです。
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical libcrypto1.1 1.1.1k-r0 CVE-2021-3711 Critical libcrypto1.1 1.1.1k-r0 CVE-2021-3712 High libssl1.1 1.1.1k-r0 CVE-2021-3712 High libssl1.1 1.1.1k-r0 CVE-2021-3711 Critical
...そして、これは同じスキャンですが、 --only-fixedフラグを追加しています。
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
Grype に修正が確認されていない脆弱性のみを報告させたい場合は、 --only-notfixedフラグを使用できます。あるいは、 --ignore-statesフラグを使用して、 wont-fixなどの特定の状態の脆弱性の結果をフィルタリングすることもできます (有効な修正状態のリストについては、 --help参照してください)。これらのフラグは、修正された、または修正されない脆弱性が無視されるように、Grype の設定に無視ルールを自動的に追加します。
Grype は VEX (Vulnerability Exploitability Exchange) データを使用して誤検知をフィルタリングしたり、追加のコンテキストを提供して一致を強化したりできます。コンテナー イメージをスキャンする場合、 --vexフラグを使用して 1 つ以上の OpenVEX ドキュメントを指定できます。
VEX ステートメントは、製品 (コンテナー イメージ)、脆弱性、および VEX ステータスを関連付けて、脆弱性の影響の主張を表現します。 VEX ステータスには、 not_affected 、 affected 、 fixed 、 under_investigationの 4 つがあります。
以下は、単純な OpenVEX ドキュメントの例です。 (ヒント: vexctl使用して独自のドキュメントを生成します)。
{ "@context": "https://openvex.dev/ns/v0.2.0", "@id": "https://openvex.dev/docs/public/vex-d4e9020b6d0d26f131d535e055902dd6ccf3e2088bce3079a8cd3588a4b14c78", "作成者": " Grype ユーザー "、"タイムスタンプ": "2023-07-17T18:28:47.696004345-06:00"、"バージョン": 1、"ステートメント": [
{ "脆弱性": { "名前": "CVE-2023-1255"
}、 "製品"： [
{ "@id": "pkg:oci/alpine@sha256%3A124c7d2707904eea7431fffe91522a01e5a861a624ee31d03372cc1d138a3126", "サブコンポーネント": [
{ "@id": "pkg:apk/alpine/[email protected]" },
{ "@id": "pkg:apk/alpine/[email protected]" }
]
}
]、"ステータス": "修正済み"
}
]
} デフォルトでは、Grype は指定された VEX ドキュメント内のステータスがnot_affectedまたはfixedであるステートメントを使用して、一致を無視セットに移動します。
--show-suppressed使用すると、VEX ステートメントの結果として無視された一致にフラグが立てられます。
libcrypto3 3.0.8-r3 3.0.8-r4 apk CVE-2023-1255 Medium (suppressed by VEX)
affectedステータスまたはunder_investigationステータスを持つステートメントは、 GRYPE_VEX_ADD環境変数または構成ファイルを使用して特に要求された場合にのみ、結果セットを拡張するとみなされます。
無視ルールを記述して、Grype が VEX ステートメントをどのように尊重するかを制御できます。たとえば、理由がvulnerable_code_not_presentの場合にのみ VEX ステートメントに作用するように Grype を設定するには、次のようなルールを作成できます。
- -無視する： - vex-status: not_affected vex-justification: 脆弱性_コード_存在しない
詳細については、正当な理由のリストを参照してください。 vex-statusおよびvex-justification他の無視ルール パラメーターと組み合わせることができます。
Grype が脆弱性のスキャンを実行するときは、ローカル ファイル システムに保存されている脆弱性データベースを使用します。このデータベースは、公開されているさまざまな脆弱性データ ソースからデータを取得して構築されます。これらの情報源には次のものが含まれます。
Alpine Linux SecDB: https://secdb.alpinelinux.org/
Amazon Linux ALAS: https://alas.aws.amazon.com/AL2/alas.rss
Chainguard SecDB: https://packages.cgr.dev/chainguard/security.json
Debian Linux CVE トラッカー: https://security-tracker.debian.org/tracker/data/json
GitHub セキュリティ アドバイザリ (GHSA): https://github.com/advisories
全国脆弱性データベース (NVD): https://nvd.nist.gov/vuln/data-feeds
Oracle Linux OVAL: https://linux.oracle.com/security/oval/
RedHat Linux セキュリティ データ: https://access.redhat.com/hydra/rest/securitydata/
RedHat RHSA: https://www.redhat.com/security/data/oval/
SUSE Linux OVAL: https://ftp.suse.com/pub/projects/security/oval/
Ubuntu Linux セキュリティ: https://people.canonical.com/~ubuntu-security/
Wolfi SecDB: https://packages.wolfi.dev/os/security.json
デフォルトでは、Grype がこのデータベースを自動的に管理します。 Grype は脆弱性データベースの新しい更新をチェックして、すべてのスキャンで最新の脆弱性情報が使用されていることを確認します。この動作は構成可能です。詳細については、「Grype のデータベースの管理」セクションを参照してください。
Grype の脆弱性データベースは、 vulnerability.dbという名前の SQLite ファイルです。データベースへの更新はアトミックです。データベース全体が置き換えられ、Grype によって「読み取り専用」として扱われます。
Grype のデータベース更新の最初のステップは、取得可能なデータベースを検出することです。 Grype は、パブリック エンドポイントから「リスト ファイル」をリクエストすることでこれを行います。
https://toolbox-data.anchore.io/grype/databases/listing.json
リスト ファイルには、ダウンロード可能なすべてのデータベースのエントリが含まれています。
リスト ファイル内のエントリの例を次に示します。
{ "built": "2021-10-21T08:13:41Z"、"version": 3、"url": "https://toolbox-data.anchore.io/grype/databases/vulnerability-db_v3_2021-10- 21T08:13:41Z.tar.gz", "チェックサム": "sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a91"}この情報を使用して、Grype は正しいデータベース (現在のスキーマ バージョンで最近構築されたデータベース) を選択し、データベースをダウンロードし、リストされたchecksum値を使用してデータベースの整合性を検証できます。
注:通常の使用では、ユーザーが Grype のデータベースを管理する必要はありません。 Grype はデータベースを舞台裏で管理しています。ただし、より詳細な制御が必要なユーザーのために、Grype はデータベースをより明示的に管理するオプションを提供します。
デフォルトでは、データベースはローカル ファイルシステムのディレクトリ$XDG_CACHE_HOME/grype/db/にキャッシュされます。たとえば、macOS では、データベースは~/Library/Caches/grype/db/3/に保存されます。 (XDG パスの詳細については、XDG ベース ディレクトリ仕様を参照してください。)
環境変数GRYPE_DB_CACHE_DIRを使用して、キャッシュ ディレクトリのパスを設定できます。この変数を設定するだけでは機能しない場合は、 TMPDIR環境変数も設定する必要がある場合があります。
Grype は正確な一致を提供するために最新の脆弱性情報を必要としています。デフォルトでは、ローカル データベースが過去 5 日間に構築されていない場合、実行は失敗します。データの古さチェックはdbの下の環境変数GRYPE_DB_MAX_ALLOWED_BUILT_AGEおよびGRYPE_DB_VALIDATE_AGEまたはフィールドmax-allowed-built-ageおよびvalidate-ageを介して構成できます。 golang の期間構文を使用します。失効チェックを無効にするには、 GRYPE_DB_VALIDATE_AGEまたはvalidate-age falseに設定します。
デフォルトでは、Grype は実行のたびに、インターネット経由でネットワーク呼び出しを行うことにより、新しいデータベースをチェックします。環境変数GRYPE_DB_AUTO_UPDATEをfalseに設定することで、Grype にこのチェックを実行しないように指示できます。
Grype のvulnerability.dbとmetadata.jsonファイルを、予想されるスキーマ バージョンのキャッシュ ディレクトリに配置している限り、Grype はネットワークにアクセスする必要はありません。さらに、オンライン環境でgrype db listコマンドからダウンロード可能なデータベース アーカイブのリストを取得し、データベース アーカイブをダウンロードしてオフライン環境に転送し、 grype db import を使用して指定されたデータベースをオフライン容量で使用します。
db import手動で使用せずに、独自の Grype データベースを内部で配布したい場合は、Grype の DB 更新メカニズムを利用できます。これを行うには、公開されているものと同様の独自のlisting.jsonファイルを作成し(公開されたlisting.jsonファイルの例については、 grype db list -o raw参照)、内部エンドポイントを指すようにダウンロードURLを変更します(例:プライベート S3 バケット、内部ファイル サーバーなど)。 Grype の内部インストールは、作成したホストされたlisting.jsonファイルを指すようにdb.update-url ( GRYPE_DB_UPDATE_URL環境変数と同じ) を構成することで、データベースの更新を自動的に受信できます。
Grype は、コマンド ラインからデータベースを制御したいユーザーのために、データベース固有の CLI コマンドを提供します。提供されている便利なコマンドの一部を次に示します。
grype db status — Grype データベースの現在のステータス (場所、構築日、チェックサムなど) を報告します。
grype db check — データベースに更新が利用可能かどうかを確認します
grype db update — 最新のデータベースがキャッシュ ディレクトリにダウンロードされていることを確認します (Grype はデフォルトで各スキャンの開始時にこの操作を実行します)。
grype db list — db.update-urlで設定されたリスト ファイルをダウンロードし、ダウンロード可能なデータベースを表示します
grype db import — 明示的に使用するデータベース アーカイブを grype に提供します (オフライン DB 更新に役立ちます)
grype db providers - データベース プロバイダーの詳細なリストを提供します。
grype db --helpを実行すると、Grype のデータベース コマンドに関する完全な情報が表示されます。
Grype は、CLI 実装 (cobra) を通じてシェル補完を提供します。次のコマンドのいずれかを実行して、シェルの完了コードを生成します。
grype completion
go run ./cmd/grype completion
これにより、シェル スクリプトが STDOUT に出力され、Grype の完了スクリプトとして使用できます。 -hまたは--helpフラグを指定して上記のコマンドのいずれかを実行すると、選択したシェルでそれを実行する方法の手順が表示されます。
コンテナー ランタイムが存在しない場合でも、grype は共通の資格情報ソース ( ~/.docker/config.jsonなど) で構成された資格情報を利用できます。これらの資格情報を使用してプライベート レジストリからイメージをプルします。構成ファイルは、 docker loginなどのコマンドを介してプライベート レジストリで認証するときに資格情報が保存される場所です。詳細については、 go-containerregistryドキュメントを参照してください。
config.json例は次のようになります。
// config.json
{
"auths": {
"registry.example.com": {
"username": "AzureDiamond",
"password": "hunter2"
}
}
}例として次のコマンドを実行できます。コンテナーがプライベート レジストリにアクセスするために必要なマウント/環境構成について詳しく説明します。
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
以下のセクションでは、この構成ファイルをシークレットとして Kubernetes 上のコンテナーにマウントする方法の簡単なワークフローを示します。
シークレットを作成します。 config.jsonの値は重要です。ここで詳細に説明されている仕様を指します。このセクションの下には、ポッド構成がボリュームとして使用するsecret.yamlファイルがあります。 config.jsonキーは重要です。これは、ポッドにマウントされるときのファイルの名前になります。
apiVersion: v1
kind: Secret
metadata:
name: registry-config
namespace: grype
data:
config.json:
```
`kubectl apply -f secret.yaml` grype を実行するポッドを作成します。 env DOCKER_CONFIG 、認証情報ファイルを探す場所を通知するため重要です。以下の例では、 DOCKER_CONFIG=/configを設定すると、資格情報が/config/config.jsonにあることが grype に通知されます。これが、シークレットのキーとしてconfig.json使用した理由です。コンテナにマウントされると、シークレットのキーがファイル名として使用されます。 volumeMountsセクションは、シークレットを/configにマウントします。 volumesセクションではボリュームに名前を付け、ステップ 1 で作成したシークレットを利用します。
apiVersion: v1
kind: Pod
spec:
containers:
- image: anchore/grype:latest
name: grype-private-registry-demo
env:
- name: DOCKER_CONFIG
value: /config
volumeMounts:
- mountPath: /config
name: registry-config
readOnly: true
args:
-
volumes:
- name: registry-config
secret:
secretName: registry-config
```
`kubectl apply -f pod.yaml` これで、ユーザーはkubectl logs grype-private-registry-demo実行できるようになります。ログには、ポッド設定で提供された
上記の情報を使用すると、ユーザーはgrypeまたはsyft構成ファイルでプライベート レジストリ アクセスを構成する必要がなくなります。また、レジストリの構成とアクセスに関して Docker デーモン (またはその他のランタイム ソフトウェア) に依存しません。
デフォルトの設定検索パス ( grype config locationsですべてを参照):
.grype.yaml
.grype/config.yaml
~/.grype.yaml
grype config使用して、サンプル構成ファイルを標準出力に出力します。すべての値を標準出力にロードした後、 grype config --load使用して現在の設定を出力します。
--config / -cフラグを使用してファイルを直接指定し、独自の構成ファイル/パスを指定できます。
grype-c /path/to/config.yaml
構成オプション (例の値はデフォルトです):
# 起動時のアプリケーション更新のチェックを有効/無効にします# GRYPE_CHECK_FOR_APP_UPDATE と同じ env varcheck-for-app-update: true# ユーザーは sbom の生成に使用するイメージ ソースを指定できます# 有効な値は次のとおりです: registry、docker、podman# GRYPE_DEFAULT_IMAGE_PULL_SOURCE と同じ env vardefault-image-pull-source: ""# --name と同じ;分析対象のターゲットの名前を設定しますname: ""# スキャン時に、指定された重大度以上の重大度が見つかった場合、戻りコードは 1 になります# デフォルトは未設定で、この検証をスキップします (オプション: 無視可能、低、中) 、高、クリティカル)# --fail-on と同じ。 GRYPE_FAIL_ON_SEVERITY env varfail-on-severity: ""# 脆弱性レポートの出力形式 (オプション: table、template、json、cyclonedx)# 出力タイプとしてテンプレートを使用する場合、「output-template-」の値も指定する必要があります。ファイル'# -o と同じ; GRYPE_OUTPUT env varoutput: "table"# テンプレート出力を使用する場合は、Go テンプレート ファイルへのパスを指定する必要があります# テンプレート出力の詳細については、https://github.com/anchore/grype#using-templates を参照してください# デフォルトのパステンプレート ファイルへのパスは、現在の作業ディレクトリです# Output-template-file: .grype/html.tmpl# 出力レポートをファイルに書き込みます (デフォルトは stdout に書き込みます)# --file と同じです。 GRYPE_FILE env varfile: ""# スキャンから除外するグロブのリスト。例:# exclude:# - '/etc/**'# - './out/**/*.json'# 同じ --除外します。 GRYPE_EXCLUDE env varexclude: []# アップストリーム カーネル パッケージと一致するカーネル ヘッダー パッケージの一致を含めます# if 'false' の場合、そのような一致は無視としてマークされますmatch-upstream-kernel-headers: false# 使用する OS および/またはアーキテクチャコンテナイメージの参照 (例: "windows/armv6" または "arm64")# --platform と同じ。 GRYPE_PLATFORM env varplatform: ""# SBOM 入力を使用する場合、パッケージに none がある場合に CPE を自動的に生成しますadd-cpes-if-none: false# alpine:3.10distro:external のように、: として使用する Linux ディストリビューションを明示的に指定します-sources:enable:falsemaven:search-upstream-by-sha1:truebase-url:https://repo1.maven.org/maven2db:#実行時にデータベースの更新をチェック#GRYPE_DB_AUTO_UPDATEと同じ env var auto-update: true # 脆弱性データベース キャッシュを書き込む場所。デフォルトは $XDG_CACHE_HOME/grype/db # GRYPE_DB_CACHE_DIR と同じ env var cache-dir: "" # 脆弱性データベースの URL # GRYPE_DB_UPDATE_URL と同じ env var update-url: "https://toolbox-data.anchore.io/grype /databases/listing.json" # データベースのビルドが max-allowed-built-age よりも古くないことを保証します # チェックを無効にするには false に設定します validate-age: true # 脆弱性データベースの最大許容経過時間、 # age は経過時間です構築されました # デフォルトの最大経過時間は 120 時間 (または 5 日) max-allowed-built-age: "120h" # データベースをダウンロードする必要があるかどうかを確認するため、GRYPE_DB_UPDATE_URL のダウンロードのタイムアウト # このファイルは 2024 年 4 月時点で ~156KiB です-17 なので、ダウンロードは速くなります。必要に応じて調整します update-available-timeout: "30s" # 実際の脆弱性 DB をダウンロードするためのタイムアウト # DB は 2024 年 4 月 17 日時点で ~156MB であるため、接続が遅い場合はデフォルトのタイムアウトを超える可能性があります。必要に応じて調整します update-download-timeout: "120s"search: # パッケージを検索するための検索スペース (オプション: すべてのレイヤー、圧縮) # -s と同じ; GRYPE_SEARCH_SCOPE env varscope: "squashed" # 検索対象のファイル インデックスを含むアーカイブ内を検索します (zip) # 注: 今のところ、これは Java パッケージ カタロガにのみ適用されます # GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES と同じ env varindexed-archives: true # search検索対象のファイル インデックスを含まないアーカイブ内 (tar、tar.gz、tar.bz2 など) # 注: これを有効にすると、検出されたすべての圧縮 tar が解凍されるため、パフォーマンスに影響が出る可能性があります # 注: 現時点ではこれですJava パッケージ カタロガにのみ適用されます # GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES と同じ env var unindexed-archives: false# 「registry:」スキームを介してレジストリから直接取得する場合のオプションregistry: # レジストリと通信するときに TLS 検証をスキップ # GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY と同じ env var insecure -skip-tls-verify: false # レジストリに接続するときに https の代わりに http を使用します # GRYPE_REGISTRY_INSECURE_USE_HTTP と同じ env var insecure-use-http: false # CA 証明書へのファイルパス (または *.crt、*.cert、 *.pem) はクライアント証明書の生成に使用されます # GRYPE_REGISTRY_CA_CERT env var ca-cert: "" # 特定のレジストリの認証情報 auth: # レジストリへの URL (例: "docker.io"、"localhost:5000" など) # GRYPE_REGISTRY_AUTH_AUTHORITY 環境変数 - 権限: "" # GRYPE_REGISTRY_AUTH_USERNAME 環境変数ユーザー名: "" # GRYPE_REGISTRY_AUTH_PASSWORD 環境変数パスワード: "" # 注: トークンとユーザー名/パスワードは相互に排他的です # GRYPE_REGISTRY_AUTH_TOKEN 環境変数トークン: "" # TLS 認証に使用されるクライアント証明書へのファイルパスレジストリへの # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # レジストリへの TLS 認証に使用されるクライアント キーへのファイルパス # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" # - ... # 注、より多くの認証情報は次の方法で提供できます。 config ファイルのみ (env vars ではありません)log: # すべての出力を抑制します (脆弱性リストを除く) # -q と同じです。 GRYPE_LOG_QUIET env var quit: false # 詳細度を増やす # GRYPE_LOG_VERBOSITY と同じ env var verbosity: 0 # ログ レベル。注: 詳細なログは ETUI を抑制します # GRYPE_LOG_LEVEL と同じ環境変数 # logrus ログ レベルを使用します: https://github.com/sirupsen/logrus#level-logging level: "error" # ログ ファイルを書き込む場所 (デフォルトはログファイルを持つため) # GRYPE_LOG_FILE env var fileと同じ: ""match: # 脆弱性の一致を見つけようとするときに # CPES を使用するように以下のマッチャーを設定します。 # プライマリ マッチャーを識別できない場合、ストック マッチャーがデフォルトになります。 java: using-cpes: false python: using-cpes: false javascript: using-cpes: false Ruby: using-cpes: false dotnet: using-cpes: false golang: using-cpes: false # CPE マッチングが無効になっている場合でも、 「stdlib」をスキャンするときに例外を発生させます。 always-use-cpe-for-stdlib: true # Syft によって「推測」されただけである可能性のあるメイン モジュールの疑似バージョンを、脆弱性に一致するもので使用できるようにします。 : using-cpes: true
以下の潜在的な開発分野が現在調査中です。
ホワイトリスト、パッケージマッピングのサポート
