格賴佩
0.83.0
針對容器鏡像和檔案系統的漏洞掃描器。輕鬆安裝二進位檔案來試用。與 Syft 配合使用，Syft 是用於容器映像和檔案系統的強大 SBOM（軟體物料清單）工具。
日曆：https://calendar.google.com/calendar/u/0/r?cid=Y182OTM4dGt0MjRtajI0NnNzOThiaGtnM29qNEBncm91cC5jYWxlbmRhci5nb29GUuY29tGUuY29t
議程：https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing（加入此群組以取得寫入權限）
歡迎大家！
如需 Syft 或 Grype 的商業支援選項，請聯絡 Anchore
掃描容器映像或檔案系統的內容以尋找已知漏洞。
尋找主要作業系統軟體包的漏洞：
阿爾卑斯山
亞馬遜Linux
忙碌盒
中央作業系統
CBL-水手
德班
無發行版
甲骨文Linux
紅帽 (RHEL)
烏班圖
沃爾菲
尋找特定語言包的漏洞：
紅寶石（寶石）
Java（JAR、WAR、EAR、JPI、HPI）
JavaScript（NPM、紗線）
Python（Egg、Wheel、Poetry、requirements.txt/setup.py 檔案）
點網 (deps.json)
Go 語言 (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 ）
grrype 的巧克力分發是社區維護的，而不是由anchore 團隊分發的。
choco 安裝 grype -y
釀造龍頭錨 釀造安裝 grype
在 macOS 上，也可以透過 MacPorts 從社群維護的連接埠安裝 Grype：
sudo 連接埠安裝 grype
注意：目前，Grype 僅適用於 macOS 和 Linux。
有關從原始程式碼建置和運行的說明，請參閱 DEVELOPING.md。
如果您使用 GitHub Actions，則可以在 CI 工作流程期間使用我們基於 Grype 的操作對您的程式碼或容器映像執行漏洞掃描。
校驗和應用於所有工件，並使用 cosign 對產生的校驗和檔案進行簽署。
您需要以下工具來驗證簽名：
聯合簽名
驗證步驟如下：
從發布頁面下載所需的檔案以及 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 Grypeanche/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配置選項覆寫此預設行為（有關更多詳細信息，請參閱配置）。
使用 SBOM 在 Grype 中進行更快的漏洞掃描：
# 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 匹配更加成功的兩件事是包含 CPE 和 Linux 發行版資訊。如果 SBOM 不包含任何 CPE 訊息，則可以使用--add-cpes-if-none標誌根據套件資訊產生這些資訊。若要指定發行版，請使用--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
{「漏洞」：{ ...
}, "相關漏洞": [ ...
], "比賽詳情": [ ...
]， 「人工製品」： { ...
}
}漏洞：有關直接匹配的特定漏洞的所有資訊（例如 ID、嚴重性、CVSS 評分、修復資訊、更多資訊的連結）
相關漏洞：與已發現的與主要報告的漏洞相關的漏洞的資訊。也許我們匹配的漏洞是一個 GitHub 安全公告，它有一個上游 CVE（在權威的國家漏洞資料庫中）。在這些情況下，我們在此處列出了上游漏洞。
MatchDetails ：本節試圖解釋我們在尋找匹配項時搜尋的內容以及導致匹配的套件和漏洞的詳細資訊。
Artifact ：這是我們所了解的有關套件的資訊的子集（與 Syft json 輸出相比，我們總結了元資料部分）。其中包含有關我們在容器映像或目錄中找到包的位置、包的類型、許可資訊、pURL、CPE 等的資訊。
Grype 可以透過使用具有一個或多個--exclude參數的 glob 表達式來排除來源中掃描的檔案和路徑：
grype--exclude './out/**/*.json' --exclude /etc
注意：在影像掃描的情況下，由於掃描整個檔案系統，因此可以使用絕對路徑，例如/etc或/usr/**/*.txt而目錄掃描則排除相對於指定目錄的檔案。例如：使用--exclude ./package.json掃描/usr/foo將排除/usr/foo/package.json ，而--exclude '**/package.json'將排除/usr/foo下的所有package.json文件/usr/foo 。對於目錄掃描，需要以./或**/開始路徑表達式，所有這些都將相對於指定的掃描目錄*/解析。請記住，您的 shell 可能會嘗試擴展通配符，因此請將這些參數放在單引號中，例如： '**/*.json' 。
Grype 可以配置為合併外部資料來源，以提高漏洞匹配的保真度。目前此功能預設為停用狀態。若要啟用此功能，請將以下內容新增至 grype 設定中：
外部來源：啟用：true maven：search-upstream-by-sha1：true 基本網址：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 來源的 templates 目錄中有幾個範例模板，可以作為自訂輸出格式的起點。例如，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"
...您也可以在同一位置找到預設「表格」輸出格式的範本。
除了預設的 golang 文字/範本之外，Grype 還包括來自 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 修復狀態：未知# 當Grype 讀取vex 資料時套用VEX 欄位：vex-status：not_affected vex-justification：vulnerable_code_not_present package：name：libcurl version：1.5.1 字：npm lotype：npm. / usr/local/lib/node_modules/**" # 我們可以製定規則僅透過漏洞 ID 進行比對： - 漏洞：CVE-2014-54321 # ...或僅透過單一套件欄位： - 包裝：類型：寶石
如果任何規則適用於匹配，則漏洞匹配將被忽略。僅當規則中指定的所有欄位都適用於漏洞匹配時，該規則才被視為適用於給定漏洞匹配。
當您在指定忽略規則時執行 Grype 時，「忽略」的漏洞匹配會發生以下情況：
忽略的匹配項在 Grype 的輸出中完全隱藏，除非使用json或template輸出格式；但是，在這兩種格式中，忽略的符合項目將從現有的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（漏洞利用交換）資料來過濾誤報或提供額外的上下文，從而增強匹配。掃描容器鏡像時，您可以使用--vex標誌指向一個或多個 OpenVEX 文件。
VEX 語句將產品（容器映像）、漏洞和 VEX 狀態關聯起來，以表達漏洞影響的斷言。 VEX 狀態有四種： not_affected 、 affected 、 fixed和under_investigation 。
這是一個簡單的 OpenVEX 文件的範例。 （提示：使用vexctl產生您自己的文件）。
{“@context”：“https://openvex.dev/ns/v0.2.0”，“@id”：“https://openvex.dev/docs/public/vex-d4e9020b6d0d26f131d535e055902dd6ccf3e2088bce307984507 Grype 使用者", "timestamp": "2023-07-17T18:28:47.696004345-06:00", "version": 1, "statements": [
{“漏洞”：{“名稱”：“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)
只有在使用GRYPE_VEX_ADD環境變數或在設定檔中明確要求時，才會考慮使用affected或under_investigation狀態的語句來擴充結果集。
可以寫忽略規則來控制 Grype 如何遵守 VEX 語句。例如，要將 Grype 配置為僅在理由為vulnerable_code_not_present時對 VEX 語句執行操作，您可以編寫以下規則：
- -忽略： - vex-status：not_affected vex-justification：vulnerable_code_not_present
有關詳細信息，請參閱理由列表。您可以將vex-status和vex-justification與其他忽略規則參數混合使用。
當 Grype 執行漏洞掃描時，它會使用儲存在本機檔案系統上的漏洞資料庫來執行此操作，該資料庫是透過從各種公開可用的漏洞資料來源提取資料而建構的。這些來源包括：
Alpine Linux SecDB：https://secdb.alpinelinux.org/
亞馬遜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/
紅帽 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的漏洞資料庫是一個SQLite文件，名為vulnerability.db 。對資料庫的更新是原子的：整個資料庫被替換，然後被 Grype 視為「只讀」。
Grype 資料庫更新的第一步是發現可檢索的資料庫。 Grype 透過從公共端點請求「清單檔案」來實現此目的：
https://toolbox-data.anchore.io/grype/databases/listing.json
清單檔案包含每個可供下載的資料庫的條目。
以下是清單檔案中的條目範例：
{“構建”：“2021-10-21T08：13：41Z”，“版本”：3，“url”：“https://toolbox-data.anchore.io/grype/databases/vulnerability-db_v3_2021-10- 21T08:13:41Z.tar.gz","校驗和":"sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a911"有了這些信息，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天內沒有建置本機資料庫，則會執行失敗。資料過時檢查可透過環境變數GRYPE_DB_MAX_ALLOWED_BUILT_AGE和GRYPE_DB_VALIDATE_AGE或db下的欄位max-allowed-built-age和validate-age進行設定。它使用 golang 的持續時間語法。將GRYPE_DB_VALIDATE_AGE或validate-age設為false以停用過時檢查。
預設情況下，Grype 在每次運行時都會透過 Internet 進行網路呼叫來檢查新資料庫。您可以將環境變數GRYPE_DB_AUTO_UPDATE設為false來告訴 Grype 不要執行此檢查。
只要將Grype的vulnerability.db和metadata.json檔案放置在預期schema版本的快取目錄中，Grype就不需要存取網路。此外，您可以在線上環境中透過grype db list命令取得可供下載的資料庫存檔列表，下載資料庫存檔，將其傳輸到離線環境，然後使用grype db import 以離線方式使用給定的資料庫。
如果您想在內部分發自己的 Grype 資料庫而不需要手動使用db import ，您可以利用 Grype 的資料庫更新機制。為此，您可以製作自己的listing.json文件，類似於公開找到的文件（請參閱grype db list -o raw以獲取我們的公開listing.json文件的範例），並將下載URL 更改為指向內部端點（例如私人 S3 儲存桶、內部檔案伺服器等）。 Grype 的任何內部安裝都可以透過設定db.update-url （與GRYPE_DB_UPDATE_URL環境變數相同）指向您製作的託管listing.json檔案來自動接收資料庫更新。
Grype 為想要從命令列控制資料庫的使用者提供特定於資料庫的 CLI 命令。以下是提供的一些有用指令：
grype db status — 報告 Grype 資料庫的目前狀態（例如其位置、建置日期和校驗和）
grype db check — 查看資料庫是否有可用更新
grype db update — 確保最新的資料庫已下載到快取目錄（Grype 預設在每次掃描開始時執行此操作）
grype db list — 下載在db.update-url設定的清單檔案並顯示可供下載的資料庫
grype db import — 為 grype 提供資料庫存檔以供明確使用（對於離線資料庫更新很有用）
grype db providers - 提供資料庫提供者的詳細列表
透過執行grype db --help來尋找有關 Grype 資料庫指令的完整資訊。
Grype 透過其 CLI 實作 (cobra) 提供 shell 補全。透過執行以下命令之一來產生 shell 的完成程式碼：
grype completion
go run ./cmd/grype completion
這會將 shell 腳本輸出到 STDOUT，然後可以將其用作 Grype 的完成腳本。使用-h或--help標誌執行上述命令之一將提供有關如何為您選擇的 shell 執行此操作的說明。
當容器執行時不存在時，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的值很重要。它指的是此處詳細說明的規範。此部分下方是 pod 配置將作為磁碟區使用的secret.yaml檔案。關鍵的config.json很重要。當安裝到 Pod 中時，它最終將成為檔案的名稱。
apiVersion: v1
kind: Secret
metadata:
name: registry-config
namespace: grype
data:
config.json:
```
`kubectl apply -f secret.yaml` 建立運行 grype 的 pod。 env DOCKER_CONFIG很重要，因為它通告在哪裡查找憑證檔案。在下面的範例中，設定DOCKER_CONFIG=/config通知 grype 可以在/config/config.json找到憑證。這就是為什麼我們使用config.json作為我們的秘密的金鑰。當安裝到容器中時，秘密的密鑰將用作檔案名稱。 volumeMounts部分將我們的金鑰安裝到/config 。 volumes部分命名我們的磁碟區並利用我們在第一步中創建的秘密。
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 。日誌應顯示 pod 配置中提供的
使用上述信息，使用者應該能夠配置私有註冊表訪問，而無需在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_IMAGEPAGE相同env vardefault-image-pull-source: ""# 與--name 相同；設定正在分析的目標的名稱name: ""# 掃描時，如果發現嚴重性等於或高於給定嚴重性，則傳回代碼將為1# 預設未設置，這將跳過此驗證（選項：可忽略、低、中） , 高, 關鍵)# 與 --fail-on 相同; GRYPE_FAIL_ON_SEVERITY env varfail-on-severity: ""#漏洞報告的輸出格式（選項：table、template、json、cyclonedx）#當使用template作為輸出類型時，也必須為'output-template-提供一個值file'#與-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: ""# 從掃描中排除的 glob 列表，例如：# except:# - '/etc/**'# - './out/**/*.json'# 與 -- 相同排除 ; GRYPE_EXCLUDE env varexinclude: []# 包含與上游核心套件相符的核心頭包上的匹配項# 如果為'false'，則任何此類匹配項都會標記為被忽略match-upstream-kernel-headers: false # 時使用的作業系統和/或體系結構引用容器映像（例如「windows/armv6」或「arm64」）#與--platform相同； GRYPE_PLATFORM env varplatform: ""# 如果使用SBOM 輸入，則當軟體包沒有時自動產生CPEadd-cpes-if-none: false# 明確指定用作: 的linux 發行版，如alpine: 3.10distro:external -sources: enable: false maven: search-upstream-by-sha1: true base-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: "://toolbox-data.chmore. databases/listing.json" # 確保資料庫建置不早於max-allowed-built-age # 設定為false 以停用檢查validate-age: true # 漏洞資料庫允許的最大年齡， # 年齡是從那時起的時間它已建置# 預設最大期限為120 小時（或五天） max-allowed-built-age: "120h" # 下載GRYPE_DB_UPDATE_URL 逾時以查看是否需要下載資料庫# 截至2024 年4 月，該檔案約為156KiB -17 所以下載應該很快；根據需要調整 update-available-timeout: "30s" # 下載實際漏洞資料庫的逾時 # 截至 2024 年 4 月 17 日，資料庫約為 156MB，因此較慢的連線可能會超過預設逾時；依需求調整 update-download-timeout: "120s"search: # 尋找包的搜尋空間（選項：全層、壓縮） # 與 -s 相同； GRYPE_SEARCH_SCOPE env var range: "squashed" # 在包含要搜尋的檔案索引 (zip) 的檔案中搜尋 # 注意：目前這只適用於 java 套件編目器 # 與 GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES 相同 env var包含要搜尋的檔案索引的檔案中（tar、tar.gz、tar.bz2 等） # 注意：啟用此功能可能會導致效能影響，因為所有發現的壓縮tar 都將被解壓縮# 注意：目前此功能僅適用於java 套件編目器# 與GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES 相同env var unindexed-archives: false# 透過「registry:」直接從登錄檔拉取時的選項schemaregistry: # 與註冊表通訊時跳過TINSLS 驗證#TINSLS 驗證相同編號var insecure -skip-tls-verify: false # 連接到登錄檔時使用http 而非https # 與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 環境變數 - Authority: "" # GRYPE_REGISTRY_AUTH_USERNAME env var username: "" # GRYPE_REGISTRY_AUTH_PASSWORD env var password: "" # 注意：令牌和使用者名稱/密碼是互斥的# GRYPE_REGISTRY_ken_REREGIST 的用於驗證用戶端憑證的檔案路徑到登錄機碼# GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # 用於對登錄機碼進行TLS 驗證的客戶端金鑰的檔案路徑# GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" .. # 注意，可以透過以下方式提供更多憑證僅設定檔（不是環境變數）log: # 抑制所有輸出（漏洞清單除外） # 與 -q 相同； GRYPE_LOG_QUIET env var Quiet: false # 增加詳細程度 # 與 GRYPE_LOG_VERBOSITY 相同 env var verbosity: 0 # 日誌等級；注意：詳細日誌記錄抑制ETUI # 與GRYPE_LOG_LEVEL 相同env var # 使用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: false # 停用匹配掃描“stdlib”時例外。 always-use-cpe-for-stdlib: true # 允許主模組偽版本（可能只是 Syft「猜測」）用於漏洞匹配allow-main-module-pseudo-version-comparison: false stock : 使用 cpes: true
目前正在研究以下潛在發展領域：
支援白名單、包映射
