Container & Supply-Chain Security in 2026 — Trivy / Grype / Snyk / Sysdig / Tetragon / Falco / Cosign / Sigstore Deep Dive

"Supply-chain security is no longer a checkbox-compliance exercise. xz taught us that even the most trusted open-source maintainer can be the target of a two-year social-engineering operation." — Filippo Valsorda, Go security lead, GopherCon 2025 keynote

On March 29, 2024, Andres Freund was debugging slow PostgreSQL builds when he discovered a backdoor hidden in xz-utils 5.6.0/5.6.1 (CVE-2024-3094). The incident, which nearly made it into every major Linux distribution, single-handedly raised the bar on SBOM traceability, signing and provenance requirements across the entire container base-image ecosystem. A year later, in December 2025, the EU's Cyber Resilience Act (CRA) entered into force, obligating SBOM submissions and vulnerability disclosure for every digital product sold in the EU. The United States is on the same path through EO 14028 and NIST SSDF (SP 800-218).

As of May 2026, "container security" is no longer a single tool category. You need a five-layer defense — image scanning at build time, registry policies at push time, admission control at deploy time, runtime security at execution time, and signing & provenance throughout. This post brings together Trivy, Grype, Snyk, Sysdig, Anchore, Twistlock, Tetragon, Falco, Cosign/Sigstore, Notary v2, in-toto, SLSA, CycloneDX, SPDX, distroless, gVisor, Kata Containers, OPA Gatekeeper, and Kyverno in one place.

1. The 2026 Container Security Map — Five Defense Layers

Let us first be precise about categories.

The lesson from xz is one line — never depend on a single layer. Build-time CVE scans cannot catch undisclosed backdoors, signature verification waves through malicious code signed by the actual maintainer, and runtime security misses backdoors that mimic legitimate syscalls. Defense in depth is the answer.

2. Image Scanner Comparison — Trivy / Grype / Snyk / Anchore / Docker Scout

Trivy (Aqua Security, Apache 2.0) is the de facto standard as of May 2026. Over 22k GitHub stars, recommended by the Kubernetes Security SIG, cited in EKS/GKE/AKS security guides. The strength is a single binary that covers eight scan categories in one tool — OS package CVEs, language dependencies, secrets, misconfiguration, licenses, Kubernetes manifests, Terraform, and Helm charts.

Grype (Anchore, Apache 2.0) competes head-on with Trivy. It is strong when paired with its sibling tool Syft (SBOM generator). It is the OSS successor to Anchore Engine and consults NVD + GitHub Advisory + its own curated DB.

Snyk Container (commercial) is strong on developer-workflow integration — automatic PR comments, JIRA integration, automated fix suggestions, and automatic base-image recommendations (to a lower-CVE variant). The downside is licensing cost — over 100 containers will typically run into tens of millions of KRW per year.

Sysdig Secure (commercial) is the full-stack platform from the company that birthed Falco. Image scan + runtime + compliance + IaC integration. AWS Marketplace Tier-1 ISV and popular in the Fortune 500.

Anchore Enterprise (commercial) is strong in the government / financial market. SBOM-centric architecture, FedRAMP / DISA STIG certifications, and gatekeeper of the U.S. Department of Defense Iron Bank container registry.

Docker Scout is the free (partially) tool integrated into Docker Hub and Docker Desktop. A light entry point but limited on enterprise features.

3. Trivy in Practice — From Image to SBOM in One Binary

Look at the most common scenario. Scan an official nginx image for CVEs, generate an SBOM, and fail the CI when a threshold is exceeded.

# 1) Image CVE scan (CRITICAL/HIGH only, fixable only)
trivy image \
  --severity CRITICAL,HIGH \
  --ignore-unfixed \
  --format table \
  nginx:1.27-alpine

# 2) SBOM generation (CycloneDX 1.5 format)
trivy image \
  --format cyclonedx \
  --output nginx-sbom.cdx.json \
  nginx:1.27-alpine

# 3) Rescan from the SBOM (no need to repull the image)
trivy sbom nginx-sbom.cdx.json

# 4) CI gate — exit 1 on a single CRITICAL
trivy image \
  --severity CRITICAL \
  --exit-code 1 \
  --ignore-unfixed \
  myapp:${GIT_SHA}

# 5) Secret scan (.git, .env, AWS keys, etc.)
trivy fs --scanners secret,misconfig ./

# 6) Kubernetes manifest scan
trivy config --severity HIGH,CRITICAL ./k8s/

The key option is --ignore-unfixed. If a CVE has no patch yet, there is nothing you can do about it, so it is operationally sane to gate only on fixable issues. That said, CVEs older than six months without fixes must be tracked separately.

4. CVE Matching Databases — NVD vs OSV vs GitHub Advisory

When a scanner says "vulnerable," accuracy depends on which database it consults. As of 2026 there are three major sources.

NVD (National Vulnerability Database) is NIST-operated, the CVE canonical source. The problem is the backlog. In 2024-2025, NIST staffing shortages pushed enrichment (CPE matching, CVSS scoring) more than six months behind, leaving a substantial information gap on new CVEs.

OSV (Open Source Vulnerabilities) was launched by Google in 2021. Package-to-CVE mapping is precise (native to NPM, PyPI, Go, Rust, and other package managers). Free API, clean JSON schema. Both Trivy and Grype use OSV as a secondary source.

GitHub Advisory Database is curated by GitHub Security Lab + Dependabot. For NPM/PyPI/RubyGems it gets updates faster than NVD.

An operational tip — Trivy consults all three combined. Run trivy image --vuln-type os,library --db-repository ghcr.io/aquasecurity/trivy-db and mirror the DB internally so it works in air-gapped environments.

5. SBOM Standards — CycloneDX vs SPDX

Two standards for the era of SBOM mandates.

CycloneDX (OWASP) is security-focused. You can inline a VEX (Vulnerability Exploitability eXchange) in the same document. JSON/XML/protobuf are all supported. Recommended in CISA's 2024 guidance. U.S. FDA medical devices and the EU CRA both treat CycloneDX as the primary choice.

SPDX (Linux Foundation) started focused on license compliance. Internationally standardized as ISO/IEC 5962:2021. Richer license metadata, and Kubernetes / CNCF projects have adopted SPDX.

The two formats are interconvertible — cyclonedx-cli convert --input-format spdxjson --output-format json or the reverse. Syft emits both.

# Generate SBOM with Syft
syft nginx:1.27 -o cyclonedx-json=nginx.cdx.json
syft nginx:1.27 -o spdx-json=nginx.spdx.json

# Directory SBOM
syft dir:./myapp -o cyclonedx-json

# Scan the same SBOM with Grype
grype sbom:nginx.cdx.json --fail-on high

6. SLSA — Four Levels of Build Provenance Assurance

SLSA (Supply-chain Levels for Software Artifacts) is a build-integrity framework started by Google and now governed by OpenSSF. The core question is "was this artifact really built from that source on that build system?" SLSA v1.0 was broadly adopted by 2026.

GitHub Actions shipped a SLSA L3 builder in 2023 (slsa-framework/slsa-github-generator). Google Cloud Build and AWS CodeBuild also support L3. SLSA Provenance is emitted in the in-toto attestation format.

Would SLSA have stopped the xz backdoor? Only partially. The xz build system itself was not compromised, so a SLSA L3 attestation would still have been issued. However, two-person review (L4) would have prevented sole maintainer Jia Tan from merging unilaterally. SLSA L4 remains unattained by nearly every OSS project.

7. Cosign / Sigstore — The Keyless Signing Revolution

Cosign (the Sigstore project) changed the game for OCI image signing in 2022. Traditional PKI has miserable key management — keys get lost, stolen, and must be rotated. Cosign's keyless signing uses an OIDC ID token to issue a short-lived (10-minute) certificate that performs the signing.

Three components:

• Fulcio: a CA that issues short-lived X.509 certificates. Verifies an OIDC ID token (GitHub OIDC, Google, Okta, etc.) and issues a certificate
• Rekor: an append-only transparency log (Tile-Based Merkle Tree). Every signature is publicly recorded so post-hoc tampering is detectable
• Cosign CLI: the client tool

# 1) Keyless signing (using GitHub Actions OIDC)
COSIGN_EXPERIMENTAL=1 cosign sign \
  ghcr.io/myorg/myapp@sha256:abc...

# 2) Verify — who signed (certificate identity), from where (issuer)
cosign verify \
  --certificate-identity-regexp="^https://github.com/myorg/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc...

# 3) Sign an attestation (SLSA provenance, etc.)
cosign attest \
  --predicate provenance.json \
  --type slsaprovenance \
  ghcr.io/myorg/myapp@sha256:abc...

# 4) Push the SBOM as an OCI artifact alongside the image
cosign attach sbom \
  --sbom nginx-sbom.cdx.json \
  ghcr.io/myorg/myapp@sha256:abc...

As of 2026, the public Sigstore Rekor log holds more than 150 million entries. Kubernetes, most CNCF projects, and PyPI/RubyGems are progressively adopting Sigstore signing.

8. Notary v2 vs Cosign — The Two Big Schools

Notary v2 is the successor to the image-signing standard that Docker originally launched. Hit 1.0 in 2024. CNCF Incubating. Built directly on top of the OCI 1.1 Artifact spec, so it runs on any OCI-compliant registry.

Cosign vs Notary v2 comparison:

In practice, the split is solidifying — Cosign for the Kubernetes / CNCF ecosystem, Notary v2 for enterprise / financial PKI-based shops. A single organization can run both — Cosign for dev, Notary v2 for prod release.

9. in-toto Attestation — The Provenance Standard Format

in-toto is a CMU-originating supply-chain integrity framework (2016). The idea is to leave signed attestation metadata at each build step and verify the chain. By 2026, SLSA Provenance, SBOM attestations, and VEX are all standardized as in-toto envelopes.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/myorg/myapp",
    "digest": { "sha256": "abc123..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/heads/main",
          "repository": "https://github.com/myorg/myapp",
          "path": ".github/workflows/release.yml"
        }
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner" },
      "metadata": {
        "invocationId": "https://github.com/myorg/myapp/actions/runs/123"
      }
    }
  }
}

Wrap this statement with DSSE (Dead Simple Signing Envelope) signing and you have a complete attestation. Cosign's cosign attest builds this automatically.

10. Distroless Images — Shrinking the Attack Surface Toward Zero

Distroless is the base-image philosophy started by Google. The core idea: "no shell, no package manager, no libc-adjacent utilities in production images". You remove the toolchain that an attacker would use after a container escape.

# Multi-stage build — full toolset in the build stage, distroless in the runtime stage
FROM golang:1.23 AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/app ./cmd/server

# distroless static (built-in nonroot user)
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /out/app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]

Distroless variants — static (for static binaries like Go), base (glibc + certificates), cc (C/C++ libstdc++), java21-debian12, python3-debian12, nodejs20-debian12.

Alternative: Wolfi (Chainguard) is a "security-first OS" that adds a package manager (apk) to the distroless philosophy. A promise of zero-CVE images patched within 24 hours. Chainguard Images is commercial but popularity is exploding.

The 2026 trend is chiseled containers — Microsoft introduced these starting with .NET 8. From an Ubuntu base they trim to only the necessary files, shrinking 100MB to 30MB.

11. gVisor / Kata Containers — Sandbox Runtimes

Default OCI runtimes (runc, containerd) share the Linux kernel with the host. A kernel vulnerability is a container escape. Sandbox runtimes add an isolation layer in between.

gVisor (Google, Apache 2.0) is a user-space kernel written in Go. It intercepts container syscalls and handles them in a self-implemented kernel. Fast start, mid-tier isolation. Used by GKE Sandbox and the App Engine standard environment.

Kata Containers (OpenStack Foundation) are lightweight VMs. Every container runs in a KVM micro-VM. Boots in around 0.5 seconds with VM-grade isolation. The successor to Intel Clear Containers + Hyper.sh. Used by Azure Confidential Containers and the Alibaba Cloud Sandboxed Container.

# Kubernetes RuntimeClass — choose a sandbox per pod
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: untrusted-workload
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: ghcr.io/myorg/user-code:latest

12. Falco — eBPF-Based Runtime Threat Detection

Falco (CNCF Graduated in 2024) is the de facto standard for container runtime security. Built by Sysdig and donated to the CNCF. The core is a syscall-level rule engine — read of /etc/shadow, execution of nsenter, running a package manager inside a container — these suspicious behaviors fire instantly.

In 2026, Falco defaults to the modern eBPF probe (libbpf-based). Requires kernel 5.8+. The legacy kernel module / kprobe path is deprecated.

Example Falco rules:

- rule: Shell Spawned in Container
  desc: A shell was spawned in a container — likely interactive intrusion
  condition: >
    spawned_process and container
    and shell_procs
    and proc.tty != 0
    and not user_known_shell_spawn_activities
  output: >
    Shell spawned in container (user=%user.name container_id=%container.id
    container_name=%container.name shell=%proc.name parent=%proc.pname
    cmdline=%proc.cmdline image=%container.image.repository)
  priority: WARNING
  tags: [container, shell, mitre_execution]

- rule: Write Below Etc
  desc: Write to /etc directory — possible persistence attempt
  condition: >
    write_etc and not proc.name in (allowed_etc_writers)
  output: >
    File below /etc opened for writing (user=%user.name
    command=%proc.cmdline file=%fd.name container=%container.id)
  priority: ERROR
  tags: [filesystem, mitre_persistence]

Falco evaluates at the moment of the syscall, so it is near real-time (microseconds). Outputs include stdout, syslog, gRPC, HTTP (SOC integration), Slack/PagerDuty.

13. Tetragon — Next-Generation eBPF Runtime Security

Tetragon (Isovalent / Cilium family, Apache 2.0) is a powerful alternative to Falco. Launched in 2023 and stabilized in v1.3 in 2025. The differences are two-fold.

First, full use of eBPF. Falco is syscall-hook-centric; Tetragon also uses LSM hooks, kprobes, and uprobes. Second, real-time prevention. Falco mostly detects-and-alerts, while Tetragon can enforce in eBPF directly — sigkill, modifying syscall return values, and so on.

# TracingPolicy CRD — a Tetragon rule
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-cryptominer
spec:
  kprobes:
  - call: "fd_install"
    syscall: false
    args:
    - index: 0
      type: int
    - index: 1
      type: "file"
    selectors:
    - matchArgs:
      - index: 1
        operator: "Postfix"
        values:
        - "xmrig"
        - "minerd"
      matchActions:
      - action: Sigkill

This policy sends an immediate SIGKILL if a binary named xmrig or minerd is opened. With Falco, you would detect and rely on an external tool to kill; Tetragon finishes the work inside the kernel — zero latency.

14. OPA Gatekeeper vs Kyverno — The Admission Controller Duopoly

At the Kubernetes admission phase — the last gate before a pod is stored in etcd — policy enforcement is split between two tools.

OPA Gatekeeper (CNCF Graduated) integrates the OPA policy engine into Kubernetes. Policies are written in Rego. Rich expressiveness, works on any Kubernetes resource, and can reference external data (LDAP, Vault, etc.).

Kyverno (CNCF Graduated, graduated in 2025) is a Kubernetes-native policy engine. Policies are YAML (no need to learn Rego). Mutate / Validate / Generate / Cleanup are the four operation types. As of 2026, Kyverno is winning the new-adoption race.

# Kyverno — block unsigned images
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  webhookTimeoutSeconds: 30
  rules:
  - name: check-image-signature
    match:
      any:
      - resources:
          kinds:
          - Pod
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/myorg/*"
            issuer: "https://token.actions.githubusercontent.com"
            rekor:
              url: https://rekor.sigstore.dev

The equivalent policy in OPA Gatekeeper requires Rego:

package kubernetes.admission

import future.keywords.if

deny contains msg if {
  input.request.kind.kind == "Pod"
  image := input.request.object.spec.containers[_].image
  not signature_valid(image)
  msg := sprintf("image %v lacks valid signature", [image])
}

signature_valid(image) if {
  startswith(image, "ghcr.io/myorg/")
  # ... external-data call or Sigstore verification
}

15. Policy in Practice — Pod Security Standards + Kyverno

After Pod Security Policy (PSP) was removed in Kubernetes 1.25, Pod Security Standards (PSS) + Pod Security Admission is the standard. But PSS only offers three presets (privileged / baseline / restricted); the 2026 best practice is to backfill fine-grained customization with Kyverno.

# Kyverno — enforce five core baselines
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: pod-security-baseline
spec:
  validationFailureAction: Enforce
  rules:
  - name: disallow-privileged
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "privileged containers are forbidden"
      pattern:
        spec:
          =(securityContext):
            =(privileged): "false"
          containers:
          - name: "*"
            =(securityContext):
              =(privileged): "false"
  - name: disallow-host-namespaces
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "hostNetwork / hostPID / hostIPC are forbidden"
      pattern:
        spec:
          =(hostNetwork): "false"
          =(hostPID): "false"
          =(hostIPC): "false"
  - name: require-non-root
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "containers must run as non-root"
      pattern:
        spec:
          =(securityContext):
            =(runAsNonRoot): true
          containers:
          - name: "*"
            =(securityContext):
              =(runAsNonRoot): true
  - name: disallow-hostpath
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "hostPath volumes are forbidden"
      pattern:
        spec:
          =(volumes):
          - X(hostPath): "null"

16. xz Backdoor 2024 — What Could Have Stopped It

Replay CVE-2024-3094 in chronological order.

• 2021: "Jia Tan" appears in the xz-utils project, builds trust over two years
• Late 2023: maintainer Lasse Collin, burnt out, grants commit access to Jia Tan
• 2024-02: the 5.6.0 release includes a backdoor hidden inside test files
• 2024-03-29: Andres Freund discovers it while debugging slow SSH logins

Evaluating each defense layer:

The conclusion — any automation breaks once social engineering produces a maintainer. The answer is code-review culture + identity verification + post-build behavior analysis (Falco/Tetragon) in combination.

17. npm Typosquatting / Dependency Confusion

Separate from xz, the most frequent supply-chain attacks are npm/PyPI typosquatting and dependency confusion. In 2024 alone Sonatype detected over 510,000 malicious packages.

Common patterns:

• Typosquatting: loadash (legitimate is lodash), colorz (legitimate is colors)
• Dependency confusion: pushing a package with the same name as one in your private NPM registry to public npm at a higher version, causing your internal build to pull from public (Alex Birsan, 2021)
• Account takeover: stealing a maintainer's npm credentials and pushing a malicious version of a legitimate package
• Postinstall hooks: malicious code executed automatically via postinstall scripts at npm install time

Defenses:

# 1) Trust the lock file (package-lock.json / pnpm-lock.yaml)
npm ci  # instead of npm install

# 2) Disable postinstall scripts
npm config set ignore-scripts true

# 3) Use scopes for internal packages (@myorg/foo)
# 4) npm audit signatures — signature verification
npm audit signatures

# 5) Behavioral pre-analysis with Socket / Snyk / Phylum

PyPI started Sigstore integration in 2024 and made attestations mandatory for popular packages in 2025. npm is approaching OIDC trusted publishing as the 2026 standard.

18. South Korea — SBOM Mandate Momentum

Korea is joining the global trend. In 2024 the Ministry of Science and ICT issued the Software Supply-Chain Security Guidelines, sketching a roadmap from recommendation toward gradual obligation for SBOM. With the 2025 amendment to the Information Protection Industry Promotion Act, SBOM submission for public-sector procurement software began phased mandatory status.

Local cases:

• LINE: per the LINE Engineering Blog (2024), the internal container registry integrates Trivy with auto-scan on push and CRITICAL/HIGH blocking. Image signing is handled by a self-operated Notary v2.
• Kakao: introduced Falco in KakaoTalk infrastructure containers in 2023. Adopted Sysdig Secure in 2024 for multi-cluster centralized management.
• Coupang: runs primarily on AWS Fargate (Firecracker-based), with SBOM auto-generation in the in-house build system and Snyk Container as the PR gate.
• Toss: announced Tetragon adoption in 2025 (at if(kakao)). Used to enforce PCI-DSS container isolation.

A Korea-specific factor is KISA's CSAP (Cloud Security Assurance Program) container-security checklist, which is the gate for public-cloud entry.

19. Japan — IPA Guidelines + Mercari / Rakuten

Japan's IPA (Information-technology Promotion Agency) published Container Security Guidelines v2.0 in 2024. The core is a Japanese localization of NIST SP 800-190 aligned with the Financial Services Agency FISC guidelines. SBOM moved from recommendation in the 2025 METI guidelines toward phased mandates in some 2026 public procurements.

Corporate cases:

• Mercari: runs Trivy + Cosign keyless signing + Kyverno policy verification as a standard pipeline across multi-cluster GKE. See Mercari Engineering Blog's 2025 "Container Security at Scale" series.
• Rakuten: hybrid of own data centers and public cloud. Anchore Enterprise + Sysdig. Financial subsidiaries use Notary v2 to meet FIPS 140-3 compliance.
• DeNA: introduced Falco for game containers and applies it to cheat / bot detection (2024 SRE Lounge).
• SmartHR: an HR SaaS on GKE with Tetragon since 2025. Strong isolation is essential for containers handling employee PII.

A Japan specialty is the FSA FISC safety-controls standard. Container isolation grade, log retention (typically 7 years), and external audit obligations are stricter than in Korea, which is why strong-isolation runtimes like Kata Containers / gVisor see higher adoption.

20. EU CRA (Cyber Resilience Act) — The 2025 Entry-Into-Force Shock

Passed by the EU Parliament in October 2024 and fully applicable in December 2027 (as of May 2026, some clauses — including SBOM submission — are already in effect). Key requirements:

• Applies to every digital product sold in the EU (SaaS possibly excluded — under discussion)
• Vulnerability handling obligations: disclose immediately on discovery — report to ENISA within 24 hours, patch or provide mitigation within 72 hours
• SBOM provision obligation: from market release for 5 years or product lifetime, whichever is longer
• Tamper prevention: digital signatures, secure boot, etc.
• Fines up to 15 million EUR or 2.5% of global revenue for violations

The impact of the CRA on container security is direct — if you sell container images into the EU market, SBOM submission is not optional. Free OSS gets exemptions under certain conditions (e.g., a single individual operator), but if a company embeds OSS into a product, the responsibility lies with the company.

In practice, push the SBOM alongside the image with cosign attach sbom or as an OCI artifact and EU auditors can verify it in one line: cosign download sbom.

21. CI/CD Integration — A Full-Stack GitHub Actions Example

End-to-end pipeline — build → SBOM → scan → sign → admission policy check.

name: secure-build
on:
  push:
    tags: ['v*']

permissions:
  contents: read
  id-token: write   # Sigstore OIDC
  packages: write   # GHCR push
  attestations: write

jobs:
  build-and-sign:
    runs-on: ubuntu-24.04
    steps:
    - uses: actions/checkout@v4
    - uses: docker/setup-buildx-action@v3
    - uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

    # 1) Build + push
    - id: build
      uses: docker/build-push-action@v6
      with:
        context: .
        push: true
        tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}
        provenance: mode=max
        sbom: true

    # 2) Trivy scan — fail on a single CRITICAL
    - uses: aquasecurity/trivy-action@master
      with:
        image-ref: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        format: sarif
        output: trivy-results.sarif
        severity: CRITICAL
        exit-code: 1
        ignore-unfixed: true

    # 3) Separate SBOM generation (Syft)
    - uses: anchore/sbom-action@v0
      with:
        image: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        format: cyclonedx-json
        output-file: sbom.cdx.json

    # 4) Cosign keyless signing + SBOM attestation
    - uses: sigstore/cosign-installer@v3
    - run: |
        cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        cosign attest --yes \
          --predicate sbom.cdx.json \
          --type cyclonedx \
          ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

    # 5) SLSA L3 provenance (GitHub OIDC + slsa-github-generator)
    - uses: actions/attest-build-provenance@v1
      with:
        subject-name: ghcr.io/${{ github.repository }}
        subject-digest: ${{ steps.build.outputs.digest }}
        push-to-registry: true

At the end of this pipeline, the GHCR holds the image + Cosign signature + SBOM attestation + SLSA provenance, all together as OCI artifacts.

22. Monitoring — Where Should Falco / Tetragon Alerts Land

Detection without a human reading the alerts is pointless. An alert-routing strategy:

• stdout/syslog to Loki/Elastic: durable storage of every event (compliance). Required for finance with a 7-year retention obligation.
• High severity to PagerDuty/Opsgenie: immediate page. ERROR and above.
• Medium severity to Slack #security-alerts: triage. Beyond ~50 events/hour you have alert fatigue — tune the rules.
• Low severity to SIEM (Splunk/Datadog): rule learning and pattern detection.

Falcosidekick (a Falco companion) routes alerts to over 50 external destinations — Slack, Teams, PagerDuty, OpenSearch, Splunk, Loki, S3, GCS, AWS SQS, Kafka, and more.

To prevent alert fatigue, use the user_known_* macros in Falco's rules-tuning.yaml aggressively to whitelist legitimate operational behavior. The textbook approach is to tolerate the first month of noisy alerts while growing those macros.

23. Confidential Containers — TEE-Backed Memory Encryption

The 2026 trend is Confidential Computing. With TEEs like AMD SEV-SNP, Intel TDX, and ARM CCA, container memory is invisible even to the host OS at runtime — even CSP staff cannot access the workload memory.

The Confidential Containers (CoCo) project moved from CNCF Sandbox to Incubating in 2025. It combines Kata Containers + TEEs. Azure Confidential Containers, Google Cloud Confidential Space, and IBM Cloud HPVS share the same foundation.

Use cases — healthcare PHI, financial PCI data, and AI model-weight protection. Korea's NICE Information Service announced adoption in 2025; in Japan, Nomura Securities applies it to some workloads.

Overhead is in the 5-15% range, but confidential-aware GPUs like H100/MI300X are emerging — well suited to AI-inference containers.

24. Anti-Patterns — Eight Common Mistakes

Repeatedly seen mistakes in the field.

1. Using latest tags: non-reproducible + defeats signature verification. Always pin by digest (@sha256:...).
2. Containers as root user: use USER nonroot or distroless. Enforce runAsNonRoot: true at admission.
3. Container images with : as an empty password: a blank-password account on the base image is a social-engineering target.
4. Injecting secrets through env vars: extractable with docker inspect. Use Vault / AWS Secrets Manager + sidecar, or SPIFFE.
5. Ad-hoc --privileged: equivalent to host root. Add only the truly required capabilities (--cap-add NET_ADMIN, etc.).
6. Mounting docker.sock into CI runners: compromising a runner takes over every host container. Replace with Sysbox / kaniko / rootless buildah.
7. Operating CVE gates only: without SBOM tracking, signature verification, and runtime security, you are defenseless against undisclosed backdoors. The xz lesson.
8. Ignoring alerts: ignore Falco / Tetragon alerts for a week and nobody will look again. Without a triage SLA the security infrastructure is meaningless.

25. The 6-12 Month Outlook

• 2026 Q3-Q4: meaningful impact from partial CRA enforcement. Every SW vendor with EU revenue accelerates SBOM standardization.
• NIST SP 800-218 SSDF obligation: U.S. federal SW procurement begins materially requiring SLSA L3-equivalent assurance.
• Rust-based images: the cargo-chef + scratch pattern that further shrinks glibc/musl dependencies spreads.
• Kyverno > OPA Gatekeeper: the gap in new adoption widens further.
• eBPF LSM standardization: Tetragon-style inline enforcement may be backported to Falco.
• AI-workload security: model-weight integrity, inference-container isolation, and prompt-injection detection extend the scope of container security tooling.
• Sigstore Trusted Publishing: PyPI/npm/RubyGems all moving toward OIDC-based publishing — expect a steep drop in token-leak incidents.

26. Conclusion — Automation Is a Tool, Not the Culture

The biggest lesson from xz is not about tools, but about operational culture. When a single maintainer holds concentrated authority, every automated defense collapses the moment that person is socially engineered. The answer is:

1. Operate all five defense layers — drop scan/SBOM/sign/admission/runtime and you are exposed to the next xz
2. Humans must read alerts — for the parts that cannot be auto-blocked, humans triage within 24 hours
3. Institutionalize two-person review — the essence of SLSA L4. A security layer you cannot build with automation
4. Regularly retire legacy dependencies — dormant OSS is the next xz candidate
5. Do not use compliance as the goal — CRA and SBOM mandates are the floor. Real security and compliance are different problems

Tools change every year. We do not know whether 2026's Trivy/Tetragon/Cosign will still be #1 in 2030. But the five operational principles above are tool-independent.

References

• Trivy official docs — https://trivy.dev/
• Aqua Security Trivy on GitHub — https://github.com/aquasecurity/trivy
• Anchore Grype — https://github.com/anchore/grype
• Anchore Syft (SBOM) — https://github.com/anchore/syft
• Snyk Container — https://snyk.io/product/container-vulnerability-management/
• Sysdig Secure — https://sysdig.com/products/secure/
• Anchore Enterprise — https://anchore.com/enterprise/
• Sigstore official — https://www.sigstore.dev/
• Cosign on GitHub — https://github.com/sigstore/cosign
• SLSA official — https://slsa.dev/
• in-toto attestation — https://in-toto.io/
• CycloneDX specification — https://cyclonedx.org/
• SPDX specification — https://spdx.dev/
• Falco official — https://falco.org/
• Falco docs — https://falco.org/docs/
• Tetragon — https://tetragon.io/
• Isovalent Tetragon blog — https://isovalent.com/blog/post/tetragon-release-1/
• gVisor — https://gvisor.dev/
• Kata Containers — https://katacontainers.io/
• Confidential Containers — https://confidentialcontainers.org/
• OPA Gatekeeper — https://open-policy-agent.github.io/gatekeeper/website/docs/
• Kyverno — https://kyverno.io/
• Distroless images — https://github.com/GoogleContainerTools/distroless
• Chainguard Wolfi — https://github.com/wolfi-dev/
• xz-utils backdoor analysis (Andres Freund) — https://www.openwall.com/lists/oss-security/2024/03/29/4
• NIST SP 800-190 container guidelines — https://csrc.nist.gov/publications/detail/sp/800-190/final
• EU Cyber Resilience Act — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CISA SBOM resources — https://www.cisa.gov/sbom
• Standard Webhooks (for reference comparison) — https://www.standardwebhooks.com/
• Notary v2 / Notation CLI — https://notaryproject.dev/
• IPA Container Security Guidelines — https://www.ipa.go.jp/security/
• Ministry of Science and ICT (Korea) SW supply-chain — https://www.msit.go.kr/