Aperta Scientia Crest
← Back to Tech Radar
📡 Aperta Intelligence Lab
Software Supply Chain Security on OpenShift: Tekton Chains, Sigstore (RHTAS) and SBOM/VEX

Software Supply Chain Security on OpenShift: Tekton Chains, Sigstore (RHTAS) and SBOM/VEX

📅 September 30, 2026
Tech Radar Cloud & DevOps Security

Briefing Summary

SolarWinds (2020), Log4Shell (CVE-2021-44228), the XZ Utils backdoor (CVE-2024-3094), and the steady stream of npm and PyPI typosquatting campaigns all converge on the same engineering conclusion: the artifact running in production is no longer the code you believe you wrote. The question is no longer “is my application vulnerable?” but “can I prove where this binary came from, who built it, from which dependencies, and that it stayed intact between commit and Pod?”.

That is exactly what an instrumented software supply chain is for. On OpenShift the assembly line is now mature: OpenShift Pipelines (Tekton) for declarative execution, Tekton Chains for signed SLSA provenance, Sigstore / Red Hat Trusted Artifact Signer (RHTAS) for keyless signing, Red Hat Trusted Profile Analyzer (TPA) for SBOM and VEX, and Enterprise Contract (now Conforma) as the release gate.

1. The Pipeline as the Trust Boundary: Pipelines-as-Code

The first break with legacy practice is to remove every image build from developer workstations:

  • Containerized execution by design: A Tekton Task runs in a dedicated Pod with its own ServiceAccount, Workspaces, and resource limits. There is no untraceable local docker build and no floating latest tag built on a laptop.
  • Pipelines-as-Code (PaC): PipelineRun definitions live in the application repository under .tekton/ and are triggered by Git webhooks (push, pull request) through the Repository CRD and CEL-based event filtering. The pipeline becomes an artifact reviewed in a pull request, exactly like application code.
  • Native traceability: every execution produces an immutable, timestamped TaskRun/PipelineRun referencing the exact builder image (buildah, git-clone), parameters, and commit SHA. That is the raw material for SLSA provenance.

Field caveat: without a pinning policy for taskRef (versioned OCI bundles, digests instead of tags), a “secured” pipeline can still execute an upstream-modified Task. That is a direct attack vector on the build chain.

2. SLSA Provenance Signed by Tekton Chains

Tekton Chains is a controller that watches the cluster’s TaskRun and PipelineRun objects and turns their results into in-toto provenance attestations in the SLSA v1.0 format:

  • Automatic attestation: Chains captures inputs (base images, sources, parameters) and outputs (image digests, artifacts) then produces a signed provenance document — with no developer intervention.
  • Signing backends: x509 keyless (OIDC → Fulcio, short-lived certificate), managed KMS (AWS KMS, GCP KMS, HashiCorp Vault), or a Kubernetes secret key. This choice determines the achievable SLSA level.
  • OCI publication: by default the attestation and its signature are pushed to the registry as OCI artifacts in the layout expected by cosign, alongside the corresponding transparency log entry. The image then carries the chains.tekton.dev/signed: "true" annotation.
  • Reading SLSA: L1 = provenance generated; L2 = hosted build + signed provenance; L3 = isolated build with non-falsifiable provenance. Tekton Chains on OpenShift supplies the L2/L3 building blocks, provided the builders are properly isolated and hardened.

3. Keyless Signing: Sigstore and Red Hat Trusted Artifact Signer

The Sigstore model solves the historical signing-key problem (issuance, rotation, revocation):

  • Fulcio issues a very short-lived x509 certificate bound to the OIDC identity of the operator or workload.
  • Rekor records every signature in an append-only Merkle-tree transparency log: proof of existence is publicly verifiable and compromise becomes detectable.
  • RHTAS is Red Hat’s supported enterprise distribution of Sigstore (Fulcio, Rekor, Trillian, TUF for trust-root distribution, cosign, gitsign, and the ec binary). gitsign lets developers sign Git commits through plain OIDC authentication, with no local key.

Command-line verification:

cosign verify ghcr.io/org/app@sha256:<digest> \
  --certificate-identity-regexp '^https://github.com/org/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Enforcement at admission: the Sigstore Policy Controller (ClusterImagePolicy CRD) rejects any deployment whose image is not signed by an approved identity and recorded in Rekor. RHACS also offers Cosign signature verification in its admission controller. Compliance stops being a report and becomes a deny.

4. SBOM and VEX: Red Hat Trusted Profile Analyzer

An SBOM is only useful if it is actionable:

  • Formats: SPDX 2.3 and CycloneDX 1.6 now cover virtually all generation tooling; the content must be attached to the image (attestation) rather than stored out-of-band.
  • TPA (Trustify) centralizes SBOMs produced by your builds and those supplied by vendors, then continuously correlates them with vulnerability databases and security advisories (including Red Hat’s).
  • VEX (Vulnerability Exploitability eXchange) is the missing piece: a component may be present in the image while being unreachable (vulnerable_code_not_in_execute_path) or not even compiled in (vulnerable_code_not_present). Without VEX, a team drowns its developers in non-exploitable CVEs; with VEX, it prioritizes what is genuinely in the attack surface and answers factually: “what is the blast radius of a new CVE?”.
  • PURL-based querying: correlation by pkg:npm/... or pkg:maven/[email protected] lets you list, in seconds, every affected image — including those in remote registries.

5. Enterprise Contract (Conforma): Policy as the Release Gate

Verification must be blocking and identical everywhere:

  • ec validate image / ec verify runs inside the pipeline before any promotion and fails the release when a rule breaks.
  • Typical rules: verified signature, SLSA provenance at a minimum level, SBOM present and attached, no critical-severity CVEs, and a whitelist of allowed Tekton task bundles.
  • Rego/OPA policies packaged as OCI bundles: versioned, reviewed, and rolled out incrementally — from the developer workstation (shift-left) to cluster admission and the registry. The same rules can be reused by Quay (immutability, Clair scanning, signing) to lock down the registry.

6. End-to-End Reference Chain

  1. Signed commit (gitsign, OIDC identity).
  2. PaC trigger on Git webhook → versioned PipelineRun.
  3. Image build (Buildah, rootless) + vulnerability scan.
  4. SBOM and attestation generation.
  5. Tekton Chains → signed SLSA provenance (Fulcio) + Rekor entry + OCI push to Quay.
  6. ec validate image: blocking release gate.
  7. ClusterImagePolicy admission: any unsigned or non-compliant artifact is rejected.
  8. Continuous SBOM/CVE/VEX correlation in TPA.

7. Curriculum Connections & Aperta Scientia Programs

  • AS200 Program (DevOps Platform Engineer — 399h): building containerized applications and CI/CD pipelines (module DO288), operating and hardening the platform at scale (module DO380), and securing containers and OpenShift including SCC, RBAC, image scanning, signing, and admission control (module DO430). Preparation for the EX188, EX280, and EX288 certifications.
  • AS300 Program (AI Platform Engineer — 399h): extending the approach to the AI chain — provenance of base images shipping CUDA/PyTorch, signing of model artifacts before deploying a KServe InferenceService or a vLLM ServingRuntime, and admission-time rejection of unverified models pulled from external registries. An AI-stack SBOM is also a license inventory and a map of GPU dependencies.

8. Technical References & Documentation

Apply these technologies in production

Explore our intensive 3-month AS200 (DevOps) and AS300 (AI Platform Engineer) curriculums.

View Curriculums →