Security

What data StackRadar receives

The scanner runs inside your cluster. It sends three things to StackRadar, and the complete field list for each is on the architecture page:

• One CycloneDX SBOM per container image — syft's output, uploaded unmodified: package names, versions, PURLs, licences, hashes and in-image file paths. It also carries the image's own LABELs as syft records them, which for most images is OCI source and version metadata.
• A workload inventory — for every container it would scan: namespace, workload name and kind, container name, image reference and digest; an allowlisted set of well-known labels (app.kubernetes.io/*, helm.sh/chart and the Helm and ArgoCD attribution annotations — never arbitrary labels); running-pod count and first-started time; the Helm release name, chart and version that packaged the workload; and the ArgoCD application name, repository URL (credentials redacted), path and target revision that delivers it.
• A heartbeat with the scanner version, your cluster ID and the cluster's Kubernetes version.

StackRadar never receives:

• Source code, or any part of an image layer
• Secrets, environment variables, or ConfigMap and Secret contents
• Registry credentials — imagePullSecrets are read and used in-cluster only
• Workload specs, or any label or annotation outside the allowlist
• Application data, logs, or traffic

Where it is processed

Everything you upload is stored and processed exclusively on servers in the EU. There is no replication to a non-EU region.

Network posture

The scanner makes outbound HTTPS requests to two kinds of destination: api.stackradar.io on port 443, and the container registries that host your images, which it pulls from to generate each SBOM. Nothing else — in particular, syft's built-in check-in with Anchore for newer versions is disabled in both the image and the chart. The chart ships a NetworkPolicy that states this as an object you can read rather than a sentence you have to trust. It needs no inbound connectivity, no ingress, and no public endpoint. Against the Kubernetes API its access is read-only: it lists and watches pods, with optional read-only lookups of workload controllers and ArgoCD applications for attribution — it never creates, modifies, or deletes anything.

For clusters that cannot reach the public internet, see private registry & restricted-network installs.

Authentication

Each cluster gets its own cluster-scoped API key. SBOM upload rejects org-scoped keys outright, so a key taken from one cluster cannot be used to write data attributed to another. Keys are revocable per cluster from the dashboard. See API keys & cluster scoping.

Supply chain integrity of the scanner

The tool you install to audit your supply chain is itself auditable:

• Source published. The scanner and its Helm chart are public — you can read every line of what runs in your cluster on GitHub.
• Signed. Every release is signed with Sigstore Cosign.
• Digest-pinned. The chart ships the exact sha256 digest of the image, so tag mutation cannot swap what you install.
• Attested. Built in GitHub Actions with SLSA provenance and an SBOM attestation in the image index, readable with docker buildx imagetools inspect.

Vulnerability data

Findings are matched against a continuously synced mirror of OSV.dev, the open vulnerability database run by Google under the OpenSSF. Because the source is public, every finding StackRadar reports can be checked against its advisory independently of us. See how vulnerability matching works.

Reporting a vulnerability

Report suspected vulnerabilities in StackRadar or its scanner to security@stackradar.io. Please include enough detail to reproduce the issue. We will acknowledge your report and keep you updated while we investigate. Please do not disclose publicly until we have had a chance to respond.

Certifications and audits

StackRadar does not currently hold a SOC 2, ISO 27001 or equivalent third-party certification, and this page will not claim one before it exists. If your procurement process needs our current posture in writing, a DPA, or a subprocessor list, contact contact@stackradar.io and we will send what we have.