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
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.
Author
Sigstore
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.
Current risk score 16/100. Use staged verification before broader rollout.
Risk 16
Pre-adoption checks
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Done
Confirm metadata review state
Listing has review metadata.
Done
Verify install payload
Install/config payload exists and can be inspected.
Done
Security checks
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Done
Review privacy notesRequired
Privacy notes are present.
Done
Verify package integrity metadata
No package verification/checksum metadata.
Pending
Rollout
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Pending
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Pending
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Pending
Evidence readiness
Evidence readiness matrix · balanced
Required evidence gates are covered (5/6 signals complete).
Risk 15
Source provenance
Present
Source repository/provenance is listed.
Required in this preset
Metadata review
Present
Review metadata is present.
Required in this preset
Safety notes
Present
Safety notes are present.
Required in this preset
Privacy notes
Present
Privacy notes are present.
Optional in this preset
Package integrity
Missing
Package integrity metadata is missing.
Optional in this preset
Install payload
Present
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
Decision timeline · balanced
5/6 steps complete with no blocking gaps for this preset.
Risk 14
triage
Confirm source provenanceRequired
Source/provenance metadata is available.
Done
triage
Check metadata review statusRequired
Review metadata is available.
Done
verify
Review safety notesRequired
Safety notes are available.
Done
verify
Review privacy notes
Privacy notes are available.
Done
verify
Validate package integrity metadata
Package integrity metadata is missing.
Pending
rollout
Verify install payload and commandsRequired
Install payload is available.
Done
No required blockers for this timeline preset.
Prerequisite readiness
Prerequisite readiness
6 prerequisites to line up before setup. Have accounts and credentials ready first.
0/6 ready
Account & credentials1Install & runtime3General2
Safety & privacy surface
Safety & privacy surface
8 safety and 6 privacy notes across 7 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
7 areas
SafetyGeneralSign container images by immutable digest rather than mutable tag so the signature is attached to the intended artifact.
SafetyGeneralKeyless 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.
SafetyCredentials & tokensPublic-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.
SafetyData retentionDisabling Cosign claim checks or bypassing transparency-log and timestamp expectations weakens the connection between the verified signature and the artifact being consumed.
SafetyGeneralAttestation and policy workflows can gate releases, deploys, or promotion decisions; review predicate schemas, policy rules, and failure behavior before enforcing them in production.
SafetyNetwork accessCosign can upload signatures, certificates, attestations, and bundles to registries or transparency infrastructure; test registry support and cleanup behavior before relying on it.
SafetyExecution & processesRegistry cleanup or deletion commands can remove signatures where the registry supports deletion, so keep release evidence retention and recovery requirements explicit.
SafetyExecution & processesOffline and air-gapped verification requires current trusted roots, bundles or signed-entry evidence, local artifacts, and a process for refreshing trust data safely.
PrivacyData retentionKeyless signing can publish email addresses, OIDC identities, certificate metadata, timestamps, and transparency-log records that are intentionally public and may be permanent.
PrivacyData retentionRegistry-stored signatures, certificates, attestations, OCI referrers, annotations, and bundles can reveal image names, digests, artifact relationships, workflow identity, and release metadata.
PrivacyData retentionSigstore bundles can include signatures, certificates, timestamps, transparency-log inclusion proofs, and issuer or subject details that should be reviewed before publishing.
PrivacyLocal filesCI logs and artifacts can expose image references, registry hosts, certificate identities, issuer URLs, workflow paths, annotations, KMS URIs, bundle paths, and verification payloads.
PrivacyPermissions & scopesCloud KMS, Vault, registry, GitHub Actions, GitLab CI, and other identity providers may receive authentication, authorization, and audit metadata when Cosign signs or verifies artifacts.
PrivacyCredentials & tokensPrivate keys, KMS credentials, registry tokens, client certificates, OIDC tokens, and signing environment variables should be scoped, rotated, masked, and excluded from generated artifacts.
Disclosure: editorial
Safety notes
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
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
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.
Verification policy for certificate identity, OIDC issuer, public keys, CA roots, intermediates, annotations, attestations, predicate types, policy checks, claim validation, timestamps, and transparency-log evidence.
CI and release workflow plan for digest pinning, protected refs, token permissions, OIDC trust boundaries, signing secrets, logs, artifact retention, and rollback behavior.
## Editorial notes
Cosign is useful when Claude-adjacent teams need concrete supply-chain controls around agents, CLI releases, containers, SBOMs, model-serving images, MCP servers, and automation artifacts. It gives developers and agents a scriptable way to sign build outputs, verify downloaded tools, attach attestations, prove CI identity, and make promotion gates depend on artifact identity instead of naming convention alone.
This entry covers the open-source Cosign CLI from the Sigstore project. It is distinct from Syft, which generates SBOMs, and Grype, which scans artifacts and SBOMs for vulnerabilities. Cosign can sign or verify SBOMs and attestations produced by other tools, but this listing focuses on Cosign itself as the artifact signing, verification, and attestation tool.
## Source notes
- The official repository describes Cosign as code signing and transparency for containers and binaries.
- The official repository says Cosign signs OCI containers and other artifacts using Sigstore.
- The README says Cosign supports keyless signing through Sigstore's Fulcio certificate authority and Rekor transparency log.
- The README lists support for hardware and KMS signing, encrypted key pairs, container signing, container verification, storage in OCI registries, and bring-your-own PKI.
- The README says users should sign images by digest rather than by tag to avoid signing something unintended.
- The README describes keyless signing with OIDC, a short-lived certificate from Fulcio, Rekor transparency-log storage, and signature upload beside the image in the OCI registry.
- The README shows verification with expected certificate identity and OIDC issuer arguments, including regular-expression variants.
- The Cosign installation docs describe release binaries, Go install, Homebrew, Linux package paths, the official container image, GitHub Actions installation, and GitLab CI installation.
- The signing docs say keyless signing can use OIDC providers such as Google, GitHub, and Microsoft, while key-based signing can use local keys, cloud KMS, Vault, OpenBao, Kubernetes secrets, and PKCS11.
- The signing docs describe signatures, attestations, annotations, saved bundles, later upload with ORAS, OCI 1.1 referrers, signature discovery with `cosign tree`, and cleanup behavior with `cosign clean`.
- The verification docs show public-key, KMS, keyless, blob, multiple-image, local-image, custom-CA, attestation, annotation, bundle, and transparency-log verification workflows.
- The verification docs explain that Cosign payloads include digests and that claim checking validates the digest unless explicitly disabled.
- The Sigstore quickstart says Cosign signs and verifies blobs and containers and that bundles include signature, certificate, timestamp, and transparency-log inclusion metadata.
- The Sigstore quickstart describes Fulcio issuing a short-lived certificate after OIDC identity verification and Rekor recording the signing activity.
- The repository is `sigstore/cosign`, is Apache-2.0 licensed, active, and maintained under the Sigstore project.
## 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 `Cosign`, `Sigstore`, `sigstore/cosign`, `github.com/sigstore/cosign`, `docs.sigstore.dev/cosign`, `Fulcio`, `Rekor`, `keyless signing`, `container signing`, `artifact signing`, and `supply chain signing`. Existing content contains only incidental Cosign-compatible signing mentions inside the Syft tools entry; no dedicated Cosign 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. Cosign is Apache-2.0 open-source software under the Sigstore project; public Sigstore services, OCI registries, cloud KMS providers, Vault providers, CI platforms, artifact stores, policy engines, and downstream deployment systems may have separate licenses, billing, terms, privacy obligations, and access controls.
About this resource
Editorial notes
Cosign is useful when Claude-adjacent teams need concrete supply-chain controls around agents, CLI releases, containers, SBOMs, model-serving images, MCP servers, and automation artifacts. It gives developers and agents a scriptable way to sign build outputs, verify downloaded tools, attach attestations, prove CI identity, and make promotion gates depend on artifact identity instead of naming convention alone.
This entry covers the open-source Cosign CLI from the Sigstore project. It is distinct from Syft, which generates SBOMs, and Grype, which scans artifacts and SBOMs for vulnerabilities. Cosign can sign or verify SBOMs and attestations produced by other tools, but this listing focuses on Cosign itself as the artifact signing, verification, and attestation tool.
Source notes
The official repository describes Cosign as code signing and transparency for containers and binaries.
The official repository says Cosign signs OCI containers and other artifacts using Sigstore.
The README says Cosign supports keyless signing through Sigstore's Fulcio certificate authority and Rekor transparency log.
The README lists support for hardware and KMS signing, encrypted key pairs, container signing, container verification, storage in OCI registries, and bring-your-own PKI.
The README says users should sign images by digest rather than by tag to avoid signing something unintended.
The README describes keyless signing with OIDC, a short-lived certificate from Fulcio, Rekor transparency-log storage, and signature upload beside the image in the OCI registry.
The README shows verification with expected certificate identity and OIDC issuer arguments, including regular-expression variants.
The Cosign installation docs describe release binaries, Go install, Homebrew, Linux package paths, the official container image, GitHub Actions installation, and GitLab CI installation.
The signing docs say keyless signing can use OIDC providers such as Google, GitHub, and Microsoft, while key-based signing can use local keys, cloud KMS, Vault, OpenBao, Kubernetes secrets, and PKCS11.
The signing docs describe signatures, attestations, annotations, saved bundles, later upload with ORAS, OCI 1.1 referrers, signature discovery with cosign tree, and cleanup behavior with cosign clean.
The verification docs show public-key, KMS, keyless, blob, multiple-image, local-image, custom-CA, attestation, annotation, bundle, and transparency-log verification workflows.
The verification docs explain that Cosign payloads include digests and that claim checking validates the digest unless explicitly disabled.
The Sigstore quickstart says Cosign signs and verifies blobs and containers and that bundles include signature, certificate, timestamp, and transparency-log inclusion metadata.
The Sigstore quickstart describes Fulcio issuing a short-lived certificate after OIDC identity verification and Rekor recording the signing activity.
The repository is sigstore/cosign, is Apache-2.0 licensed, active, and maintained under the Sigstore project.
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 Cosign, Sigstore, sigstore/cosign, github.com/sigstore/cosign, docs.sigstore.dev/cosign, Fulcio, Rekor, keyless signing, container signing, artifact signing, and supply chain signing. Existing content contains only incidental Cosign-compatible signing mentions inside the Syft tools entry; no dedicated Cosign 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. Cosign is Apache-2.0 open-source software under the Sigstore project; public Sigstore services, OCI registries, cloud KMS providers, Vault providers, CI platforms, artifact stores, policy engines, and downstream deployment systems may have separate licenses, billing, terms, privacy obligations, and access controls.
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.
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.
✓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.
✓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.
✓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.
✓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
✓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.
✓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.
✓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.
✓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.
Prerequisites
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.
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.
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.
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.