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.
by Anchore · submitted by oktofeesh1·added 2026-06-04·
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.
Privacy notes
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.
Author
Anchore
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-04
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
8 safety and 6 privacy notes across 5 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
5 areas
SafetyLocal filesSyft parses container images, archives, filesystems, directories, individual files, package manifests, binaries, and metadata; scan untrusted targets with bounded filesystem access, timeouts, and resource limits.
SafetyLocal filesThe install script and binary update paths should be verified before production use; pin versions and checksums where reproducibility or regulated environments require it.
SafetyCredentials & tokensContainer 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.
SafetyCredentials & tokensSyft 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.
SafetyGeneralSyft'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.
SafetyNetwork accessEnrichment 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.
SafetyCredentials & tokensAttestation workflows can involve signing keys, passwords, Cosign-compatible environment variables, and release provenance; protect keys and test attestation verification before relying on signed SBOMs.
SafetyGeneralSBOMs are evidence artifacts, not proof that software is secure; pair generated inventories with vulnerability scanning, license review, source verification, and human triage.
PrivacyNetwork accessThe 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.
PrivacyNetwork accessPulling images from remote or private registries can disclose image names, tags, digests, registry hostnames, platform requests, authentication attempts, and network metadata to registry infrastructure.
PrivacyCredentials & tokensSyft can use Docker, Podman, and containerd environment variables, registry credentials, client certificates, client keys, CA certificates, SSH keys, passphrases, and local Docker config files.
PrivacyNetwork accessConfiguration 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.
PrivacyPermissions & scopesGenerated 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.
Disclosure: editorial
Safety notes
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.
Privacy notes
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.
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.
Prerequisites
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.
Registry access plan for private images, Docker credentials, direct registry credentials, TLS policy, platform selection, image-pull source, and least-privilege authentication.
Supply-chain workflow plan if pairing Syft with Grype, attestations, vulnerability scanners, license checks, release gates, artifact storage, GitHub dependency submission, or compliance evidence.
## Editorial notes
Syft is useful when Claude-adjacent teams need reproducible package inventories for container builds, release gates, dependency review, vulnerability scanning, license checks, attestation workflows, and compliance handoffs. It gives agents and developers a concrete SBOM artifact that can be inspected directly, converted between formats, checked by Grype, uploaded to dependency tools, attached to releases, or stored as build evidence.
This entry covers Anchore's open-source Syft SBOM generator. It is distinct from Grype: Syft generates Software Bill of Materials documents, while Grype scans images, filesystems, archives, SBOMs, PURLs, and CPEs for known vulnerabilities. It is also distinct from generic package vulnerability hooks because this entry documents Syft itself as a standalone CLI and Go library for SBOM generation.
## Source notes
- The official repository describes Syft as a CLI tool and Go library for generating a Software Bill of Materials from container images and filesystems.
- The README says Syft is useful for vulnerability detection when paired with a scanner like Grype.
- The README lists support for container images, filesystems, archives, many package ecosystems, OCI, Docker, Singularity, CycloneDX, SPDX, Syft JSON, format conversion, and signed SBOM attestations.
- The README shows basic usage for container images and directories, plus CycloneDX JSON output and multiple SBOM outputs written to files.
- The getting-started docs define an SBOM as a detailed list of all libraries and components that make up software.
- The getting-started docs describe Syft as a CLI tool for generating SBOMs from container images and filesystems.
- The getting-started docs show Linux/macOS install script usage, Homebrew installation, and Windows installation through `winget install Anchore.Syft`.
- The getting-started docs show generating SPDX JSON and CycloneDX JSON in one run, inspecting package names with `jq`, and using `--scope all-layers` to include packages from all image layers.
- The getting-started FAQ says Syft needs internet access only for downloading container images by default, and that online supplemental enrichment is available when enabled.
- The scan-targets docs say Syft supports container images, directories, files, archives, Docker, Podman, containerd, registries, Docker archives, OCI archives, OCI directories, Singularity images, and explicit `--from` hints.
- The scan-targets docs describe default image resolution order through Docker, Podman, containerd, and direct registry access, plus default Docker Hub registry handling and linux/amd64 platform behavior for unspecific multi-architecture images.
- The scan-targets docs describe recursive directory scans, skipped virtual filesystems, excluded special file types, archive extraction, OCI archive/layout workflows, container runtime environment variables, and private registry authentication behavior.
- The output formats docs list table, JSON, PURLs, GitHub dependency snapshot JSON, template output, CycloneDX JSON/XML, SPDX JSON, and SPDX tag-value formats.
- The output formats docs say Syft's native JSON contains the most complete information, while standard formats may omit or transform some Syft-specific metadata.
- The configuration reference describes `.syft.yaml` lookup, environment-backed configuration, output settings, cataloger selection, file metadata/digest settings, layer scope, parallelism, relationships, enrichment, registry authentication, source metadata, excludes, cache settings, and attestation options.
- The repository is `anchore/syft`, is Apache-2.0 licensed, active, and maintained by Anchore.
## Duplicate check
Checked current `content/tools/`, `content/mcp/`, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for `Syft`, `anchore/syft`, `github.com/anchore/syft`, `oss.anchore.com/docs/guides/sbom`, `get.anchore.io/syft`, `SBOM Generation`, `Software Bill of Materials`, `CycloneDX`, and `SPDX`. Existing content contains generic SBOM mentions and the Grype tools entry distinguishes Syft from Grype; no dedicated Syft tools entry, target file, exact source URL duplicate, issue duplicate, semantic duplicate, or open duplicate PR was found.
## Disclosure
Editorial listing. No paid placement or affiliate link is used. Syft is Apache-2.0 open-source software sponsored by Anchore; Anchore Enterprise, commercial support, private registries, CI platforms, vulnerability scanners, license scanners, dependency-submission systems, SBOM consumers, attestation tooling, Cosign-compatible signing infrastructure, and artifact stores may have separate licenses, billing, terms, privacy obligations, and access controls.
About this resource
Editorial notes
Syft is useful when Claude-adjacent teams need reproducible package inventories for container builds, release gates, dependency review, vulnerability scanning, license checks, attestation workflows, and compliance handoffs. It gives agents and developers a concrete SBOM artifact that can be inspected directly, converted between formats, checked by Grype, uploaded to dependency tools, attached to releases, or stored as build evidence.
This entry covers Anchore's open-source Syft SBOM generator. It is distinct from Grype: Syft generates Software Bill of Materials documents, while Grype scans images, filesystems, archives, SBOMs, PURLs, and CPEs for known vulnerabilities. It is also distinct from generic package vulnerability hooks because this entry documents Syft itself as a standalone CLI and Go library for SBOM generation.
Source notes
The official repository describes Syft as a CLI tool and Go library for generating a Software Bill of Materials from container images and filesystems.
The README says Syft is useful for vulnerability detection when paired with a scanner like Grype.
The README lists support for container images, filesystems, archives, many package ecosystems, OCI, Docker, Singularity, CycloneDX, SPDX, Syft JSON, format conversion, and signed SBOM attestations.
The README shows basic usage for container images and directories, plus CycloneDX JSON output and multiple SBOM outputs written to files.
The getting-started docs define an SBOM as a detailed list of all libraries and components that make up software.
The getting-started docs describe Syft as a CLI tool for generating SBOMs from container images and filesystems.
The getting-started docs show Linux/macOS install script usage, Homebrew installation, and Windows installation through winget install Anchore.Syft.
The getting-started docs show generating SPDX JSON and CycloneDX JSON in one run, inspecting package names with jq, and using --scope all-layers to include packages from all image layers.
The getting-started FAQ says Syft needs internet access only for downloading container images by default, and that online supplemental enrichment is available when enabled.
The scan-targets docs say Syft supports container images, directories, files, archives, Docker, Podman, containerd, registries, Docker archives, OCI archives, OCI directories, Singularity images, and explicit --from hints.
The scan-targets docs describe default image resolution order through Docker, Podman, containerd, and direct registry access, plus default Docker Hub registry handling and linux/amd64 platform behavior for unspecific multi-architecture images.
The scan-targets docs describe recursive directory scans, skipped virtual filesystems, excluded special file types, archive extraction, OCI archive/layout workflows, container runtime environment variables, and private registry authentication behavior.
The output formats docs list table, JSON, PURLs, GitHub dependency snapshot JSON, template output, CycloneDX JSON/XML, SPDX JSON, and SPDX tag-value formats.
The output formats docs say Syft's native JSON contains the most complete information, while standard formats may omit or transform some Syft-specific metadata.
The repository is anchore/syft, is Apache-2.0 licensed, active, and maintained by Anchore.
Duplicate check
Checked current content/tools/, content/mcp/, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for Syft, anchore/syft, github.com/anchore/syft, oss.anchore.com/docs/guides/sbom, get.anchore.io/syft, SBOM Generation, Software Bill of Materials, CycloneDX, and SPDX. Existing content contains generic SBOM mentions and the Grype tools entry distinguishes Syft from Grype; no dedicated Syft tools entry, target file, exact source URL duplicate, issue duplicate, semantic duplicate, or open duplicate PR was found.
Disclosure
Editorial listing. No paid placement or affiliate link is used. Syft is Apache-2.0 open-source software sponsored by Anchore; Anchore Enterprise, commercial support, private registries, CI platforms, vulnerability scanners, license scanners, dependency-submission systems, SBOM consumers, attestation tooling, Cosign-compatible signing infrastructure, and artifact stores may have separate licenses, billing, terms, privacy obligations, and access controls.
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.
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.
✓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.
✓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.
✓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.
✓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.
Privacy notes
✓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.
✓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.
✓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.
✓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.
Prerequisites
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.
Grype installed from an official or trusted package path such as the Anchore install script, Homebrew, Windows package manager, Docker image, or GitHub release.
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.
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.
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.