서명이 유효한 것으로 확인되면 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:최신 $(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 매칭을 더욱 성공적으로 만드는 두 가지 요소는 CPE 및 Linux 배포 정보를 포함하는 것입니다. SBOM에 CPE 정보가 포함되어 있지 않은 경우 --add-cpes-if-none 플래그를 사용하여 패키지 정보를 기반으로 이를 생성할 수 있습니다. 배포판을 지정하려면 --distro : 플래그를 사용하세요. 전체 예는 다음과 같습니다.
v0.40.1 이전의 모든 Grype 버전은 지원되지 않습니다. 지원되지 않는 릴리스는 소프트웨어 업데이트나 취약성 데이터베이스 업데이트를 받지 못합니다. vunnel의 이전 릴리스를 사용하여 업스트림 데이터를 수집하고 grype-db를 사용하여 지원되지 않는 스키마에 대한 데이터베이스를 구축함으로써 지원되지 않는 Grype 릴리스에 대한 취약성 데이터베이스를 계속 구축할 수 있습니다.
증명 작업
Grype는 stdin을 통한 입력으로 SBOM 검색을 지원합니다. 사용자는 cosign을 사용하여 SBOM을 콘텐츠로 사용하여 이미지의 취약점을 스캔하는 증명을 확인할 수 있습니다.
취약점 : 직접적으로 일치된 특정 취약점에 대한 모든 정보(예: ID, 심각도, CVSS 점수, 수정 정보, 추가 정보 링크)
관련 취약점 : 보고된 주요 취약점과 관련이 있는 것으로 확인된 취약점에 대한 정보입니다. 아마도 우리가 일치시킨 취약성은 업스트림 CVE(권위 있는 국가 취약성 데이터베이스에 있음)가 있는 GitHub 보안 권고일 수도 있습니다. 이러한 경우 여기에 업스트림 취약점을 나열합니다.
MatchDetails : 이 섹션에서는 일치 항목을 찾는 동안 검색한 내용과 일치 항목으로 이어지는 패키지 및 취약점에 대한 정확한 세부 정보를 설명합니다.
아티팩트 : 이는 패키지에 대해 우리가 알고 있는 정보의 하위 집합입니다(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 . 디렉터리 검색 의 경우 ./ , */ 또는 **/ 로 경로 표현식을 시작해야 하며, 이들 모두는 지정된 검색 디렉터리를 기준으로 확인됩니다. 쉘이 와일드카드를 확장하려고 시도할 수 있으므로 '**/*.json' 과 같이 해당 매개변수를 작은따옴표로 묶으십시오.
외부 소스
취약성 일치의 충실도를 높이기 위해 외부 데이터 소스를 통합하도록 Grype를 구성할 수 있습니다. 이 기능은 현재 기본적으로 비활성화되어 있습니다. 이 기능을 활성화하려면 grype 구성에 다음을 추가하십시오.
외부 소스: 활성화: true maven: search-upstream-by-sha1: true 기본 URL: https://repo1.maven.org/maven2
다른 레지스트리를 Maven 엔드포인트로 사용하는 경우 기본 URL을 구성할 수도 있습니다.
무시: # 지원되는 규칙 필드의 전체 집합은 다음과 같습니다.
- 취약점: CVE-2008-4318 fix-state: 알 수 없음 # Grype가 vex 데이터를 읽을 때 VEX 필드가 적용됩니다: vex-status: not_affected vex-justification: 취약한_code_not_present 패키지: 이름: libcurl 버전: 1.5.1 유형: npm 위치: "/ usr/local/lib/node_modules/**" # 취약점 ID만으로 일치하는 규칙을 만들 수 있습니다:
- 취약점: CVE-2014-54321 # ...또는 단일 패키지 필드만으로:
- 패키지: 유형: 보석
일치에 규칙 이 적용되면 취약점 일치는 무시됩니다. 규칙에 지정된 모든 필드가 취약점 일치에 적용되는 경우에만 규칙이 특정 취약점 일치에 적용되는 것으로 간주됩니다.
무시 규칙을 지정하는 동안 Grype를 실행하면 "무시"된 취약점 일치에 다음이 발생합니다.
무시된 일치 항목은 json 또는 template 출력 형식을 사용하는 경우를 제외하고 Grype의 출력에서 완전히 숨겨집니다 . 그러나 이 두 가지 형식에서는 무시된 일치 항목이 기존 matches 배열 필드에서 제거 되고 새로운 ignoredMatches 배열 필드에 배치됩니다. 나열된 각 무시된 일치 항목에는 Grype가 이 취약성 일치 항목을 무시하게 만든 규칙의 배열인 appliedIgnoreRules 라는 추가 필드도 있습니다.
--fail-on 사용할 때 무시된 일치 항목은 Grype의 종료 상태 결정에 영향을 주지 않습니다 . 예를 들어, 사용자가 --fail-on critical 지정하고 "치명적" 심각도로 발견된 모든 취약점 일치가 무시 된 경우 Grype는 0으로 종료됩니다.
참고: 거짓 긍정이 발견되면 계속해서 신고 해 주세요! 무시 규칙을 사용하여 오탐지를 안정적으로 필터링할 수 있더라도 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의 구성에 무시 규칙을 자동으로 추가하여 수정되거나 수정되지 않을 취약점은 무시됩니다.
VEX 지원
Grype는 VEX(Vulnerability Exploitability Exchange) 데이터를 사용하여 오탐지를 필터링하거나 추가 컨텍스트를 제공하여 일치 항목을 늘릴 수 있습니다. 컨테이너 이미지를 스캔할 때 --vex 플래그를 사용하여 하나 이상의 OpenVEX 문서를 가리킬 수 있습니다.
VEX 문은 제품(컨테이너 이미지), 취약점, VEX 상태를 연결하여 취약점의 영향에 대한 주장을 표현합니다. VEX 상태에는 not_affected , affected , fixed 및 under_investigation 네 가지가 있습니다.
다음은 간단한 OpenVEX 문서의 예입니다. (팁: 자신만의 문서를 생성하려면 vexctl 사용하세요).
기본적으로 Grype는 이 데이터베이스를 자동으로 관리합니다. Grype는 모든 스캔이 최신 취약성 정보를 사용하는지 확인하기 위해 취약성 데이터베이스에 대한 새로운 업데이트를 확인합니다. 이 동작은 구성 가능합니다. 자세한 내용은 Grype의 데이터베이스 관리 섹션을 참조하세요.
데이터베이스 업데이트 작동 방식
Grype의 취약성 데이터베이스는 vulnerability.db 라는 이름의 SQLite 파일입니다. 데이터베이스에 대한 업데이트는 원자적입니다. 전체 데이터베이스가 교체된 다음 Grype에 의해 "읽기 전용"으로 처리됩니다.
Grype의 데이터베이스 업데이트 첫 번째 단계는 검색에 사용할 수 있는 데이터베이스를 검색하는 것입니다. Grype는 공개 엔드포인트에서 "목록 파일"을 요청하여 이를 수행합니다.
이 정보를 사용하여 Grype는 올바른 데이터베이스(현재 스키마 버전으로 가장 최근에 구축된 데이터베이스)를 선택하고, 데이터베이스를 다운로드하고, 나열된 checksum 값을 사용하여 데이터베이스의 무결성을 확인할 수 있습니다.
Grype의 데이터베이스 관리
참고: 일반적인 사용 중에는 사용자가 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-agefalse 로 설정하세요.
오프라인 및 에어갭 환경
기본적으로 Grype는 실행될 때마다 인터넷을 통해 네트워크 호출을 통해 새 데이터베이스를 확인합니다. 환경 변수 GRYPE_DB_AUTO_UPDATEfalse 로 설정하여 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 환경 변수와 동일)을 구성하여 자동으로 데이터베이스 업데이트를 받을 수 있습니다.
데이터베이스 관리를 위한 CLI 명령
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 플래그와 함께 위 명령 중 하나를 실행하면 선택한 쉘에 대해 이를 수행하는 방법에 대한 지침이 제공됩니다.
개인 레지스트리 인증
로컬 Docker 자격 증명
컨테이너 런타임이 없는 경우 grype는 일반 자격 증명 소스(예: ~/.docker/config.json )에 구성된 자격 증명을 계속 활용할 수 있습니다. 이러한 자격 증명을 사용하여 개인 레지스트리에서 이미지를 가져옵니다. 구성 파일은 docker login 과 같은 명령을 통해 개인 레지스트리로 인증할 때 자격 증명이 저장되는 곳입니다. 자세한 내용은 go-containerregistry 설명서를 참조하세요.
예시로 다음 명령을 실행할 수 있습니다. 컨테이너가 프라이빗 레지스트리에 액세스하는 데 필요한 마운트/환경 구성을 자세히 설명합니다.
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
Kubernetes의 Docker 자격 증명
아래 섹션에서는 이 구성 파일을 Kubernetes의 컨테이너에 비밀로 마운트하는 방법에 대한 간단한 작업 흐름을 보여줍니다.
비밀을 만드세요. config.json 의 값이 중요합니다. 여기에 자세히 설명된 사양을 참조합니다. 이 섹션 아래에는 포드 구성이 볼륨으로 사용할 secret.yaml 파일이 있습니다. config.json 키가 중요합니다. 이는 포드에 마운트될 때 파일 이름이 됩니다.
grype를 실행하는 포드를 만듭니다. env DOCKER_CONFIG 자격 증명 파일을 찾을 위치를 알려주기 때문에 중요합니다. 아래 예에서 DOCKER_CONFIG=/config 설정하면 /config/config.json 에서 자격 증명을 찾을 수 있음을 grype에 알립니다. 이것이 우리가 config.json 비밀의 키로 사용한 이유입니다. 컨테이너에 마운트되면 비밀의 키가 파일 이름으로 사용됩니다. volumeMounts 섹션은 비밀을 /config 에 마운트합니다. volumes 섹션에서는 볼륨 이름을 지정하고 1단계에서 생성한 비밀을 활용합니다.
이제 사용자는 kubectl logs grype-private-registry-demo 실행할 수 있습니다. 로그에는 포드 구성에 제공된 에 대한 grype 분석이 표시되어야 합니다.
위의 정보를 사용하여 사용자는 grype 또는 syft 구성 파일에서 그렇게 할 필요 없이 개인 레지스트리 액세스를 구성할 수 있어야 합니다. 또한 레지스트리 구성 및 액세스를 위해 docker 데몬(또는 다른 런타임 소프트웨어)에 의존하지 않습니다.
구성
기본 구성 검색 경로( grype config locations 와 함께 모두 참조):
.grype.yaml
.grype/config.yaml
~/.grype.yaml
/grype/config.yaml
샘플 구성 파일을 stdout으로 인쇄하려면 grype config 사용하십시오. 모든 값을 stdout에 로드한 후 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과 동일; 분석 중인 대상의 이름을 설정합니다. 이름: ""# 스캔 시 심각도가 지정된 심각도 이상으로 발견되면 반환 코드는 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: ""# 검사에서 제외할 glob 목록입니다. 예:# 제외:# - '/etc/**'# - './out/**/*.json'# 동일 -- 제외하다; GRYPE_EXCLUDE env varexclude: []# 업스트림 커널 패키지와 일치하는 커널 헤더 패키지에 일치 항목을 포함합니다.# 'false'인 경우 이러한 일치 항목은 무시됨으로 표시됩니다.upstream-kernel-headers: false# 다음 경우에 사용할 OS 및/또는 아키텍처 컨테이너 이미지 참조(예: "windows/armv6" 또는 "arm64")# --platform과 동일; GRYPE_PLATFORM env varplatform: ""# SBOM 입력을 사용하는 경우 패키지에 noneadd-cpes-if-none: false가 있으면 자동으로 CPE를 생성합니다. # alpine:3.10distro:external과 같이 :으로 사용할 Linux 배포판을 명시적으로 지정합니다. -sources: 활성화: 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 캐시-dir: "" # 취약점 데이터베이스의 URL # GRYPE_DB_UPDATE_URL과 동일 env var update-url: "https://toolbox-data.anchore.io/grype /databases/listing.json" # DB 빌드가 max-allowed-build-age보다 오래되지 않았는지 확인합니다. # 확인을 비활성화하려면 false로 설정합니다. verify-age: true # 취약성 데이터베이스에 허용되는 최대 수명, # age는 이후 시간입니다. # 기본 최대 기간은 120시간(또는 5일)입니다. max-allowed-build-age: "120h" # 데이터베이스를 다운로드해야 하는지 확인하기 위한 GRYPE_DB_UPDATE_URL 다운로드 시간 제한 # 이 파일은 2024-04 기준 ~156KiB입니다. -17 따라서 다운로드가 빨라야 합니다. 필요에 따라 조정 update-available-timeout: "30s" # 실제 취약점 DB 다운로드 시간 제한 # 2024-04-17 기준 DB는 ~156MB이므로 연결 속도가 느려지면 기본 시간 제한을 초과할 수 있습니다. 필요에 따라 조정 update-download-timeout: "120s"search: # 패키지를 찾을 검색 공간 (옵션: 모든 레이어, 압축) # -s 와 동일; GRYPE_SEARCH_SCOPE env var range: "squashed" # 검색할 파일 인덱스가 포함된 아카이브 내에서 검색(zip) # 참고: 현재 이것은 Java 패키지 카탈로그에만 적용됩니다 # GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES와 동일 env var indexed-archives: true # 검색 검색할 파일 인덱스가 포함되지 않은 아카이브 내(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 env var 사용자 이름: "" # GRYPE_REGISTRY_AUTH_PASSWORD env var 비밀번호: "" # 참고: 토큰과 사용자 이름/비밀번호는 상호 배타적입니다. # GRYPE_REGISTRY_AUTH_TOKEN env var token: "" # TLS 인증에 사용되는 클라이언트 인증서의 파일 경로 레지스트리에 # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # 레지스트리에 대한 TLS 인증에 사용되는 클라이언트 키의 파일 경로 # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" # - ... # 참고, 다음을 통해 더 많은 자격 증명을 제공할 수 있습니다. 구성 파일만(env vars 아님)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 일치가 비활성화된 경우에도 "stdlib"를 검색할 때 예외를 만듭니다. Always-use-cpe-for-stdlib: true # Syft에서 "추측"만 했을 수 있는 메인 모듈 의사 버전을 취약점 일치에 사용하도록 허용합니다.allow-main-module-pseudo-version-comparison: false stock : using-cpes: true
