Grype

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Canonical URL

https://heyclau.de/entry/tools/grype

Source URLs

https://oss.anchore.com/docs/guides/vulnerability/getting-started/, https://github.com/anchore/grype, https://anchore.com/opensource/

Brand

Grype

Brand domain

anchore.com

Brand asset source

brandfetch

Safety notes

Grype parses container images, archives, filesystems, SBOMs, package identifiers, and vulnerability data; run it from trusted automation with bounded filesystem access and resource limits for untrusted targets., The install script and binary update paths should be verified before use in production CI; pin versions and checksums where reproducible builds or regulated environments require it., Scanning private images can use registry credentials, client certificates, tokens, Docker or Podman daemon access, and local image metadata, so CI jobs should scope credentials and avoid broad registry permissions., Vulnerability findings are advisory and depend on package detection, vulnerability database freshness, distro context, CPE matching, fix-state metadata, EPSS, KEV, and risk-scoring inputs; high-impact findings still need human triage., Fail-on thresholds, only-fixed filters, only-notfixed filters, ignore rules, VEX documents, and suppressed-result settings can change pipeline outcomes, so policy changes should be reviewed like security code., The configuration reference includes options for insecure registry TLS behavior and HTTP registry access; these should be avoided outside tightly controlled test environments., Automatic database updates and application update checks make outbound network requests unless disabled or pinned by policy., Large images, archives, monorepos, or SBOMs can produce expensive scans and large JSON/SARIF artifacts; set timeouts, artifact limits, cache policy, and retention rules in CI.

Privacy notes

The Grype getting-started docs say Grype runs locally and does not send scan data to external services; it needs internet access for downloading container images and the vulnerability database., Pulling images from remote or private registries can disclose image names, tags, digests, registry hostnames, platform requests, authentication attempts, and network metadata to registry infrastructure., Scan output can reveal package names, package versions, ecosystems, distro names, image identifiers, file metadata, file digests, executable metadata, vulnerability identifiers, fix versions, EPSS, KEV, risk scores, and suppressed findings., JSON, SARIF, CycloneDX, and template outputs are useful for automation but can leak dependency inventory and security posture when uploaded to CI logs, code scanning tools, tickets, dashboards, or long-retention artifacts., Configuration files and environment variables can include registry usernames, passwords, tokens, client certificates, client keys, CA certificates, cache paths, update URLs, ignore rules, VEX documents, and output paths., SBOM inputs may contain full dependency inventories and build metadata; treat Grype reports and source SBOMs as security-sensitive artifacts.

Author

Anchore

Submitted by

oktofeesh1

Claim status

unclaimed

Last verified

2026-06-04

• The Grype getting-started docs say Grype runs locally and does not send scan data to external services; it needs internet access for downloading container images and the vulnerability database.
• Pulling images from remote or private registries can disclose image names, tags, digests, registry hostnames, platform requests, authentication attempts, and network metadata to registry infrastructure.
• Scan output can reveal package names, package versions, ecosystems, distro names, image identifiers, file metadata, file digests, executable metadata, vulnerability identifiers, fix versions, EPSS, KEV, risk scores, and suppressed findings.
• JSON, SARIF, CycloneDX, and template outputs are useful for automation but can leak dependency inventory and security posture when uploaded to CI logs, code scanning tools, tickets, dashboards, or long-retention artifacts.
• Configuration files and environment variables can include registry usernames, passwords, tokens, client certificates, client keys, CA certificates, cache paths, update URLs, ignore rules, VEX documents, and output paths.
• SBOM inputs may contain full dependency inventories and build metadata; treat Grype reports and source SBOMs as security-sensitive artifacts.

• Grype installed from an official or trusted package path such as the Anchore install script, Homebrew, Windows package manager, Docker image, or GitHub release.
• Target selection for container images, registries, Docker, Podman, containerd, OCI archives, Docker archives, Singularity images, directories, files, SBOMs, Package URLs, or CPEs.
• Vulnerability database update policy, cache directory, offline scanning expectations, database age policy, and network allowance for database downloads.
• CI policy for output formats, JSON/SARIF artifacts, fail-on severity thresholds, fix-state filters, VEX documents, ignore rules, and suppressed-result review.
• Registry access plan for private images, credentials, TLS policy, platform selection, image-pull source, and least-privilege authentication.
• SBOM and supply-chain workflow plan if pairing Grype with Syft, CycloneDX, SPDX, OpenVEX, GitHub code scanning, ticketing, or release gates.

Show that Grype is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

[![Listed on HeyClaude](https://heyclau.de/badge/tools/grype.svg)](https://heyclau.de/entry/tools/grype)

Grype side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field	Grype Apache-2.0 vulnerability scanner from Anchore for container images, filesystems, archives, SBOMs, PURLs, and CPEs, with risk scoring, VEX filtering, and CI-friendly output. Open dossier	Syft Apache-2.0 CLI and Go library from Anchore for generating SBOMs from container images, filesystems, directories, files, archives, and OCI layouts in SPDX, CycloneDX, and Syft JSON formats. Open dossier	Kubescape Apache-2.0 CNCF-incubating Kubernetes security platform and CLI for scanning clusters, manifests, Helm charts, Kustomize projects, Git repositories, and container images for misconfigurations, compliance gaps, and vulnerabilities. Open dossier	Cosign Apache-2.0 Sigstore CLI for signing, verifying, and attesting containers, blobs, binaries, SBOMs, and OCI artifacts with keyless OIDC, KMS keys, Fulcio, Rekor, bundles, and registry storage. Open dossier
Next steps	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing
Trust	Review first	Review first	Review first	Review first
Review status	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed
Package trust	Package not verified	Package not verified	Package not verified	Package not verified
Source provenance	Source-backed	Source-backed	Source-backed	Source-backed
Submitter	oktofeesh1	oktofeesh1	oktofeesh1	oktofeesh1
Install risk	Review first	Review first	Review first	Review first
Notes	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓
Brand	Grype	Syft	Kubernetes	Cosign
Category	tools	tools	tools	tools
Source	Source-backed	Source-backed	Source-backed	Source-backed
Author	Anchore	Anchore	Kubescape	Sigstore
Added	2026-06-04	2026-06-04	2026-06-04	2026-06-04
Platforms	CLI	CLI	CLI	CLI
Harness	CLI	CLI	CLI	CLI
Source repo	—	—	—	—
Safety notes	✓Grype parses container images, archives, filesystems, SBOMs, package identifiers, and vulnerability data; run it from trusted automation with bounded filesystem access and resource limits for untrusted targets. The install script and binary update paths should be verified before use in production CI; pin versions and checksums where reproducible builds or regulated environments require it. Scanning private images can use registry credentials, client certificates, tokens, Docker or Podman daemon access, and local image metadata, so CI jobs should scope credentials and avoid broad registry permissions. Vulnerability findings are advisory and depend on package detection, vulnerability database freshness, distro context, CPE matching, fix-state metadata, EPSS, KEV, and risk-scoring inputs; high-impact findings still need human triage. Fail-on thresholds, only-fixed filters, only-notfixed filters, ignore rules, VEX documents, and suppressed-result settings can change pipeline outcomes, so policy changes should be reviewed like security code. The configuration reference includes options for insecure registry TLS behavior and HTTP registry access; these should be avoided outside tightly controlled test environments. Automatic database updates and application update checks make outbound network requests unless disabled or pinned by policy. Large images, archives, monorepos, or SBOMs can produce expensive scans and large JSON/SARIF artifacts; set timeouts, artifact limits, cache policy, and retention rules in CI.	✓Syft parses container images, archives, filesystems, directories, individual files, package manifests, binaries, and metadata; scan untrusted targets with bounded filesystem access, timeouts, and resource limits. The install script and binary update paths should be verified before production use; pin versions and checksums where reproducibility or regulated environments require it. Container daemon access, Docker credentials, Podman sockets, containerd sockets, direct registry access, SSH-based Podman connections, and private-registry credentials should be scoped tightly in CI. Syft can recursively scan directories and archives; exclude build caches, virtual environments, node_modules trees, generated artifacts, secrets directories, and mounted filesystems that do not belong in the SBOM. Syft's native JSON contains the most complete information, while SPDX and CycloneDX may transform or omit some Syft-specific metadata; downstream policy should account for format differences. Enrichment is disabled by default, but when enabled it can query online package services for supplemental package or license data, so teams should review network policy before enabling it. Attestation workflows can involve signing keys, passwords, Cosign-compatible environment variables, and release provenance; protect keys and test attestation verification before relying on signed SBOMs. SBOMs are evidence artifacts, not proof that software is secure; pair generated inventories with vulnerability scanning, license review, source verification, and human triage.	✓Cluster scans use kubeconfig and Kubernetes API access; run Kubescape with the narrowest practical permissions and avoid broad production credentials in untrusted automation. Manifest and repository scans can reveal sensitive workload structure, names, images, RBAC bindings, network policy gaps, and security posture; treat reports as security-sensitive evidence. Auto-fix commands can modify Kubernetes manifests, so use dry-run output, review diffs, and keep version-controlled rollback paths before applying generated changes. Image patching can require BuildKit and elevated local privileges, and the push option can publish patched images back to a registry; test tags and registry scope before enabling it. Validating Admission Policy generation and Deny bindings can block deploys cluster-wide if policy scope, namespace selectors, or control IDs are wrong. Exceptions, suppressed findings, severity thresholds, compliance thresholds, and baseline configuration can hide meaningful risk when used without review. Image scanning and vulnerability matching depend on image access, vulnerability database freshness, package detection, distro context, and Grype database behavior; high-impact results still need human triage. The MCP server exposes vulnerability and configuration scan data to AI assistants using the same Kubernetes access context, so connect it only to trusted clients and service accounts.	✓Sign container images by immutable digest rather than mutable tag so the signature is attached to the intended artifact. Keyless workflows depend on OIDC issuer and subject claims; overly broad certificate identity, issuer, or regular-expression verification can approve artifacts from the wrong workflow or account. Public-key, KMS, Vault, Kubernetes secret, environment-variable, and hardware-backed signing flows can expose high-value signing material if CI permissions or logs are too broad. Disabling Cosign claim checks or bypassing transparency-log and timestamp expectations weakens the connection between the verified signature and the artifact being consumed. Attestation and policy workflows can gate releases, deploys, or promotion decisions; review predicate schemas, policy rules, and failure behavior before enforcing them in production. Cosign can upload signatures, certificates, attestations, and bundles to registries or transparency infrastructure; test registry support and cleanup behavior before relying on it. Registry cleanup or deletion commands can remove signatures where the registry supports deletion, so keep release evidence retention and recovery requirements explicit. Offline and air-gapped verification requires current trusted roots, bundles or signed-entry evidence, local artifacts, and a process for refreshing trust data safely.
Privacy notes	✓The Grype getting-started docs say Grype runs locally and does not send scan data to external services; it needs internet access for downloading container images and the vulnerability database. Pulling images from remote or private registries can disclose image names, tags, digests, registry hostnames, platform requests, authentication attempts, and network metadata to registry infrastructure. Scan output can reveal package names, package versions, ecosystems, distro names, image identifiers, file metadata, file digests, executable metadata, vulnerability identifiers, fix versions, EPSS, KEV, risk scores, and suppressed findings. JSON, SARIF, CycloneDX, and template outputs are useful for automation but can leak dependency inventory and security posture when uploaded to CI logs, code scanning tools, tickets, dashboards, or long-retention artifacts. Configuration files and environment variables can include registry usernames, passwords, tokens, client certificates, client keys, CA certificates, cache paths, update URLs, ignore rules, VEX documents, and output paths. SBOM inputs may contain full dependency inventories and build metadata; treat Grype reports and source SBOMs as security-sensitive artifacts.	✓The Syft getting-started docs say Syft runs locally and does not send scan data to external services; it needs internet access for downloading container images, and enrichment can use online sources when enabled. Pulling images from remote or private registries can disclose image names, tags, digests, registry hostnames, platform requests, authentication attempts, and network metadata to registry infrastructure. SBOM outputs can reveal package names, versions, package types, file paths, file metadata, file digests, executable metadata, license information, package relationships, dependency inventories, image identifiers, source names, source versions, and supplier metadata. Syft can use Docker, Podman, and containerd environment variables, registry credentials, client certificates, client keys, CA certificates, SSH keys, passphrases, and local Docker config files. Configuration options can cause Syft to search local Go module caches, vendor folders, Maven repositories, Python packages, JavaScript registries, package indexes, or remote enrichment sources depending on language settings. Generated SPDX, CycloneDX, Syft JSON, GitHub dependency snapshot JSON, template output, logs, and CI artifacts should be treated as security-sensitive inventory data with retention and access controls.	✓Kubescape reports can include cluster names, namespaces, workload names, RBAC subjects, users with administrative rights, image names, tags, digests, CVEs, control failures, file paths, and compliance scores. Pulling private images or scanning registries can disclose image references, registry hosts, authentication attempts, platform requests, and network metadata to registry infrastructure. CLI configuration can include account IDs, access keys, backend URLs, kubeconfig paths, registry usernames, registry passwords, output paths, cache directories, and exception files. SaaS submission, backend discovery, operator telemetry, Prometheus export, code-scanning uploads, and CI artifacts can move scan metadata outside the local machine or cluster when enabled. SARIF, JSON, JUnit, HTML, PDF, Prometheus, and MCP outputs can expose detailed security posture and should have retention, access control, and redaction policies. The Kubescape MCP server can make vulnerability manifests and configuration scan results available to AI tools, which may have their own logging, retention, and data-handling behavior.	✓Keyless signing can publish email addresses, OIDC identities, certificate metadata, timestamps, and transparency-log records that are intentionally public and may be permanent. Registry-stored signatures, certificates, attestations, OCI referrers, annotations, and bundles can reveal image names, digests, artifact relationships, workflow identity, and release metadata. Sigstore bundles can include signatures, certificates, timestamps, transparency-log inclusion proofs, and issuer or subject details that should be reviewed before publishing. CI logs and artifacts can expose image references, registry hosts, certificate identities, issuer URLs, workflow paths, annotations, KMS URIs, bundle paths, and verification payloads. Cloud KMS, Vault, registry, GitHub Actions, GitLab CI, and other identity providers may receive authentication, authorization, and audit metadata when Cosign signs or verifies artifacts. Private keys, KMS credentials, registry tokens, client certificates, OIDC tokens, and signing environment variables should be scoped, rotated, masked, and excluded from generated artifacts.
Prerequisites	Grype installed from an official or trusted package path such as the Anchore install script, Homebrew, Windows package manager, Docker image, or GitHub release. Target selection for container images, registries, Docker, Podman, containerd, OCI archives, Docker archives, Singularity images, directories, files, SBOMs, Package URLs, or CPEs. Vulnerability database update policy, cache directory, offline scanning expectations, database age policy, and network allowance for database downloads. CI policy for output formats, JSON/SARIF artifacts, fail-on severity thresholds, fix-state filters, VEX documents, ignore rules, and suppressed-result review.	Syft installed from an official or trusted package path such as the Anchore install script, Homebrew, Windows package manager, Docker image, or GitHub release. Target selection for container images, Docker, Podman, containerd, direct registry access, OCI archives, Docker archives, OCI layout directories, Singularity images, directories, files, and compressed archives. SBOM format plan for table, Syft JSON, SPDX JSON, SPDX tag-value, CycloneDX JSON, CycloneDX XML, GitHub dependency snapshot JSON, PURLs, templates, and downstream compatibility requirements. File-selection, cataloger, archive, layer-scope, platform, output-path, source-name, source-version, source-supplier, and base-path policy for the target being scanned.	Kubescape installed from an official or trusted path such as the install script, GitHub releases, Homebrew, Krew, package manager, or source build after reviewing the installer. Target plan for scanning the current Kubernetes cluster, an alternate kubeconfig or context, namespaces, YAML manifests, Helm charts, Kustomize directories, Git repositories, or container images. Framework and policy plan for NSA-CISA, MITRE ATT&CK, CIS, SOC 2, PCI DSS, HIPAA, individual controls, exceptions, severity thresholds, compliance thresholds, and baseline drift. Kubernetes access plan with least-privilege kubeconfig, RBAC, namespace boundaries, operator permissions, and safe handling for production clusters.	Cosign installed from an official or trusted path such as GitHub releases, Homebrew, Go install, a Linux package, the official container image, or a CI installer action. Artifact target plan for container images by digest, local blobs, binaries, SBOMs, WASM modules, Tekton bundles, OCI artifacts, or release files. Signing identity or key plan covering keyless OIDC, expected certificate identity and issuer, self-managed keys, hardware keys, KMS, Vault, Kubernetes secrets, PKCS11, or custom PKI. Registry and artifact-storage plan for OCI referrers, signature artifacts, private registry authentication, local bundles, offline verification, and later upload workflows.
Install	—	—	—	—
Config	—	—	—	—
Citations	Source repositorygithub.com 2026-07-19T13:50:19+00:00 Documentationoss.anchore.com Websiteanchore.com Submitted by oktofeesh12026-06-04 Source methodology →	Source repositorygithub.com 2026-07-19T13:50:19+00:00 Documentationoss.anchore.com Submitted by oktofeesh12026-06-04 Source methodology →	Source repositorygithub.com 2026-07-19T13:50:19+00:00 Documentationkubescape.io Submitted by oktofeesh12026-06-04 Source methodology →	Source repositorygithub.com 2026-07-19T13:50:19+00:00 Documentationdocs.sigstore.dev Submitted by oktofeesh12026-06-04 Source methodology →
Claim	Unclaimed	Unclaimed	Unclaimed	Unclaimed

Source-backed guides for putting this to work.

• Best list: Best AI & LLM security toolsOpen 4 picks in the interactive comparison tool
• Comparison: Semgrep vs Gitleaks vs Grype vs KubescapeOpen 4 picks in the interactive comparison tool