Supply Chain Security Tools for Kubernetes: What to Use and When

Supply chain security became a mainstream concern after SolarWinds in 2020 and Log4Shell in 2021. Since then, the tooling landscape has exploded — SBOMs, image signing, policy engines, vulnerability scanners, provenance attestations. For a platform engineer trying to build a defensible Kubernetes environment, the question isn't whether to invest in supply chain security, it's which tools solve which problems and in what order.

This post maps the tooling landscape, explains what each layer does, and gives you a practical starting point based on what actually prevents incidents rather than what looks good in a compliance checklist.

The Supply Chain Attack Surface

A Kubernetes workload's supply chain spans everything that touches your code before it runs in production:

1. Source code — your code and its dependencies
2. Build process — the CI pipeline that compiles, tests, and packages
3. Container images — base images, packages installed at build time
4. Image registry — where images are stored and pulled from
5. Deployment manifests — Helm charts, Kustomize overlays, raw YAML
6. Runtime — what actually runs in the cluster

An attacker who compromises any of these layers can deliver malicious code to production without ever touching your application source. The tools in this post address each layer.

Layer 1: Vulnerability Scanning

Trivy

Trivy (Aqua Security, Apache 2.0) is the most widely adopted open source vulnerability scanner for containers. It scans container images, filesystems, Git repositories, Kubernetes manifests, and Terraform configs for:

• OS package vulnerabilities (CVE database)
• Language-specific dependency vulnerabilities (Go, Python, Node.js, Java, Ruby, .NET)
• Misconfigurations (Dockerfile, Kubernetes YAML, Helm charts)
• Secrets accidentally embedded in images or code
• License compliance

1# Scan an image
2trivy image nginx:1.25
3
4# Scan a running cluster
5trivy k8s --report summary cluster
6
7# Scan a Kubernetes manifest
8trivy config ./kubernetes/

Run Trivy in CI on every image build. Fail the build on CRITICAL and HIGH severity CVEs without a known fix. Don't fail on MEDIUM and lower by default — the noise-to-signal ratio is too high and teams learn to ignore the scanner.

Trivy also supports SBOM generation (trivy image --format cyclonedx) which feeds into the next layer.

Grype

Grype (Anchore, Apache 2.0) is a strong alternative to Trivy for vulnerability scanning, with particularly good Go module and Python package coverage. It pairs naturally with Syft (same vendor) for SBOM-driven scanning.

For most teams, pick one: Trivy or Grype. Running both adds operational overhead without proportional security gain. Trivy's broader scope (manifests, secrets, IaC) makes it the default choice unless you have specific reasons to prefer Grype's output format.

Layer 2: SBOMs

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in a software artifact — packages, libraries, versions, licenses. Think of it as a manifest for your container image.

Why SBOMs Matter

Without an SBOM, when a new CVE is published (e.g., another Log4Shell-class vulnerability), you have to scan every running image to find out if you're affected. With SBOMs, you query the SBOM index: "which of our images contain log4j version X?"

SBOMs are also increasingly required for compliance. US Executive Order 14028 (2021) mandated SBOMs for software sold to the federal government. Industry frameworks (SLSA, SSDF) treat SBOMs as a baseline artifact.

Syft

Syft (Anchore, Apache 2.0) generates SBOMs from container images, directories, and OCI artifacts in CycloneDX, SPDX, and Syft JSON formats:

# Generate SBOM for an image
syft nginx:1.25 -o cyclonedx-json > nginx-sbom.json

# Generate SBOM for a directory
syft dir:./myapp -o spdx-json > myapp-sbom.json

Store the SBOM as an OCI artifact alongside the image in your registry using cosign attach sbom. This makes it retrievable wherever the image is used.

Generate SBOMs at build time, not on-demand. By the time you need the SBOM, the build environment may no longer be reproducible.

Layer 3: Image Signing and Verification

Cosign (Sigstore)

Cosign (Sigstore, Apache 2.0) signs container images and other OCI artifacts. It's part of the Sigstore project, a CNCF project backed by Google, Red Hat, and Purdue University.

Cosign signs by attaching a cryptographic signature to the image in the registry — the image digest is signed, not the image tag (tags are mutable). The signature proves:

• This image was built by this key
• It hasn't been tampered with since signing

1# Generate a key pair
2cosign generate-key-pair
3
4# Sign an image (after pushing to registry)
5cosign sign --key cosign.key registry.example.com/myapp:v1.2.3@sha256:abc123
6
7# Verify a signature
8cosign verify --key cosign.pub registry.example.com/myapp:v1.2.3

For keyless signing (using short-lived OIDC tokens from your CI provider instead of long-lived keys), Cosign integrates with GitHub Actions, GitLab CI, and other OIDC-capable systems:

cosign sign --identity-token=$(gcloud auth print-identity-token) \
  registry.example.com/myapp:v1.2.3@sha256:abc123

Signing alone is useless without verification at admission time — see the policy enforcement layer below.

Layer 4: Provenance and SLSA

SLSA (Supply chain Levels for Software Artifacts, pronounced "salsa") is a security framework that defines four levels of supply chain integrity:

• SLSA 1 — build process is documented, provenance exists
• SLSA 2 — build is scripted, provenance is signed by the build service
• SLSA 3 — source and build are hardened, provenance is unforgeable
• SLSA 4 — hermetic, reproducible builds with two-party review

For most teams, SLSA 2 is the practical target: your CI pipeline generates signed provenance (build metadata — who built what, when, from which source) attached to each image.

GitHub Actions supports SLSA provenance generation natively via the slsa-github-generator action. The generated provenance is an in-toto attestation attached to the image in the registry via Cosign.

SLSA is a framework, not a tool. The tools that implement it are Cosign (for attestation), slsa-github-generator (for GitHub Actions), and Witness (for more complex pipelines).

Layer 5: Admission Control and Policy Enforcement

Scanning images in CI is necessary but not sufficient. Images that pass CI scanning can be replaced in the registry (tag mutation), and workloads can be deployed without going through your CI pipeline. Admission control enforces policy at the cluster boundary — no unsigned, unscanned, or non-compliant image runs.

Kyverno (Recommended for Most Teams)

Kyverno can verify image signatures and attestations as part of admission control:

1apiVersion: kyverno.io/v1
2kind: ClusterPolicy
3metadata:
4  name: verify-image-signature
5spec:
6  validationFailureAction: Enforce
7  rules:
8    - name: check-signature
9      match:
10        any:
11          - resources:
12              kinds: ["Pod"]
13      verifyImages:
14        - imageReferences:
15            - "registry.example.com/*"
16          attestors:
17            - entries:
18                - keys:
19                    publicKeys: |-
20                      -----BEGIN PUBLIC KEY-----
21                      ...
22                      -----END PUBLIC KEY-----

This blocks any Pod from running if its image isn't signed with the specified key. Combined with a ClusterPolicy requiring images come only from your approved registry, you've closed the "pull random image from Docker Hub" risk.

OPA/Gatekeeper

For teams already running OPA/Gatekeeper, image signature verification can be done via the Ratify project (Microsoft, CNCF sandbox), which acts as an external data provider for Gatekeeper. More complex to set up than Kyverno's native verifyImages support.

Layer 6: Runtime Security

Supply chain security prevents malicious artifacts from entering your cluster. Runtime security detects if something malicious is executing despite those controls.

Falco

Falco (CNCF graduated) monitors kernel system calls and detects anomalous behaviour at runtime: unexpected network connections, privilege escalation, sensitive file reads, container escapes.

Falco uses eBPF probes (or kernel modules) to hook into syscalls. Rules define what's suspicious:

1- rule: Unexpected outbound connection
2  desc: Detect outbound connections from containers
3  condition: >
4    outbound and container and not trusted_container
5  output: >
6    Outbound network connection (user=%user.name container=%container.name
7    image=%container.image.repository:%container.image.tag
8    connection=%fd.name)
9  priority: WARNING

Falco doesn't prevent attacks — it detects them. Pair it with alerting (PagerDuty, Slack, SIEM) for incident response.

What to Implement First

If you're starting from zero, here's the order that gives the most security per unit of effort:

Week 1: Trivy in CI Block CRITICAL CVEs with known fixes on every image build. This stops the most obviously exploitable vulnerabilities from shipping. Cost: low. Impact: high.

Week 2: Restrict image sources with Kyverno Add a ClusterPolicy that only allows images from your private registry (ECR, GCR, ACR). This prevents image: redis (pulling from Docker Hub) and image: attacker.example.com/backdoored-app. Cost: low. Impact: high.

Week 3: Cosign signing in CI + Kyverno verification at admission Sign images as part of your build pipeline. Enforce signature verification at admission. This closes the gap between "image was scanned at build time" and "image running in cluster is the same image that was scanned." Cost: medium. Impact: high.

Month 2: SBOM generation Add Syft to your build pipeline, store SBOMs alongside images. This enables rapid response to new CVEs — you can query which workloads are affected without re-scanning everything. Cost: low. Impact: medium.

Month 3: Runtime security with Falco Deploy Falco with alert routing. Cost: medium (tuning rules takes time). Impact: medium (detection, not prevention).

Ongoing: Work toward SLSA 2 Add provenance generation to your CI pipeline. This is the compliance layer — required for federal contracts, increasingly required by enterprise customers.

Tools at a Glance

Every tool in this list is open source and Apache 2.0 licensed. Supply chain security at the tool level is free — the cost is operational time to configure, maintain, and respond to findings.

Frequently Asked Questions

Do I need both Trivy and Grype?

No. Pick one. Trivy has broader scope (IaC, manifests, secrets detection in addition to CVE scanning) and is more widely adopted. Grype has better coverage for some language ecosystems. If you have no strong reason to prefer Grype, use Trivy.

Is an SBOM the same as a vulnerability scan?

No. An SBOM is an inventory of components. A vulnerability scan cross-references that inventory against CVE databases. You can generate an SBOM once and scan it against CVE databases repeatedly as new vulnerabilities are disclosed — which is more efficient than re-scanning the image each time.

What's the difference between Cosign keyful and keyless signing?

Keyful signing uses a long-lived asymmetric key pair you manage. Keyless signing uses short-lived OIDC tokens from your CI provider (GitHub, GitLab) — no key management required, and the signature is verifiable using the Sigstore transparency log (Rekor). Keyless is simpler to operate for most teams but requires your CI provider to support OIDC token issuance.

Does Falco cause performance overhead?

Yes — eBPF-based Falco (recommended over the kernel module) typically adds 2–5% CPU overhead on heavily loaded nodes. For most production workloads this is acceptable. The overhead is on the node, not per-pod, so it doesn't scale linearly with the number of containers.

How does this relate to the broader zero-trust model?

Supply chain security addresses one quadrant of zero-trust: verifying that the software running in your environment is what you think it is and hasn't been tampered with. The other quadrants — network segmentation, workload identity, secrets management — are complementary. See Secrets Management in Kubernetes: Vault vs ESO vs SOPS for the secrets management layer.

For a real-world example of what happens when supply chain controls fail, see The Claude Code Source Leak: A Case Study in CI/CD Safety & Supply Chain Security.

Building a security program for your Kubernetes platform? Talk to us at Coding Protocols — we help platform teams implement security controls that are enforceable and operationally sustainable.