Every software supply chain rests on an act of faith: that the artifact running in production is the one your source and your pipeline actually produced, unaltered, from ingredients you trust. For years that faith went unexamined — we shipped what the build server handed us and moved on. A run of build-system and dependency compromises changed the conversation for good, and by 2026 the question customers, auditors, and regulators ask is blunt: can you prove it? For most teams the honest answer is still no. Closing that gap is what build provenance is for — cryptographically signed, machine-verifiable metadata that records how, where, and from which sources an artifact was built, backed by policy that refuses to run anything it cannot verify.
Provenance only becomes a control when three things click together: a framework to define what good looks like, a mechanism to sign and record the evidence, and an enforcement point that says no. In practice that is SLSA for grading build integrity, Sigstore for keyless signing and public transparency, and admission-time policy-as-code — OPA Gatekeeper or Kyverno — standing at the cluster door. Below is how the pieces fit, the trade-offs that matter, a hardening checklist you can start this week, and why this stack is becoming a commercial necessity for engineering teams across Tunisia and North Africa selling into the EU.
Why provenance beats trust
Traditional supply-chain security asked whether you trust a vendor or a registry. Provenance replaces that vague trust with verifiable claims. Instead of assuming an image is clean because it came from your registry, you check an attestation that binds the image digest to a specific source commit, builder identity, and build parameters — and you reject anything without one.
- ▸Tamper-evidence over tamper-hope: a signed provenance predicate lets a verifier detect whether an artifact was swapped or rebuilt outside your pipeline.
- ▸Identity, not secrets: modern signing binds artifacts to a workload identity via OIDC rather than a long-lived key that can leak.
- ▸Machine-checkable policy: because attestations are structured, using the in-toto format, a gate can evaluate them automatically at deploy time, closing the window between build and run.
- ▸Standards alignment: this is exactly the posture NIST SSDF (SP 800-218) and the OWASP Top 10 CI/CD Security Risks push toward — provenance, least privilege, and verified artifacts over implicit trust.
The SLSA build track, decoded
SLSA, Supply-chain Levels for Software Artifacts, is the common vocabulary for build integrity. Its build track defines escalating, achievable levels, deliberately practical rather than aspirational.
- ▸Build Level 1: the build is scripted and automated, and it produces provenance describing how the artifact was made. This alone kills the reproducibility black hole of manual builds.
- ▸Build Level 2: the build runs on a hosted platform that generates and signs provenance, so consumers can verify it was not produced on someone's laptop.
- ▸Build Level 3: the build platform is hardened and builds are isolated, making the provenance resistant to forgery even by a malicious pipeline job — the level that meaningfully resists insider and tenant-escape attacks.
The pragmatic move is to reach Level 1 everywhere first, generating provenance on every build, then push your highest-value artifacts to Level 2 and 3. Do not let perfect block the floor: universal Level 1 beats a single gold-plated Level 3 pipeline surrounded by unmeasured ones.
Signing and attestation with Sigstore
The tooling that made provenance approachable is Sigstore, now the de facto open standard for artifact signing.
- ▸Cosign signs and verifies container images and arbitrary artifacts, and attaches attestations such as provenance and SBOMs alongside them.
- ▸Fulcio issues short-lived signing certificates bound to an OIDC identity — your CI workload, a build job, a maintainer — so you sign with ephemeral keys and never manage a private key at rest.
- ▸Rekor is a public transparency log that records signatures immutably, so a signature cannot be quietly backdated or hidden.
This keyless model is why ecosystems adopted it fast: npm provenance and PyPI trusted publishers both lean on OIDC-federated Sigstore signing to prove a package came from the repository and workflow it claims. Pair signing with a software bill of materials in SPDX or CycloneDX, attach it as an attestation, and a downstream consumer can verify both what is in the artifact and how it was built, in one verification step.
Enforcing at the gate: Gatekeeper and Kyverno
Signatures and SBOMs are inert until something refuses to run the unverified. In Kubernetes that enforcement point is an admission controller, and two policy-as-code engines dominate.
- ▸OPA Gatekeeper uses Rego, a purpose-built policy language. It is extremely expressive and reaches well beyond Kubernetes, since Rego can evaluate any JSON, which suits organisations standardising one policy language across CI, infrastructure, and clusters. The cost is Rego's learning curve.
- ▸Kyverno expresses policy as Kubernetes-native YAML, with first-class image-verification rules that check cosign signatures and attestations directly. There is no new language to learn, which lowers adoption friction, at the price of being Kubernetes-scoped.
A typical bar: block any workload whose images are not signed by your trusted identity, lack a valid SLSA provenance attestation, run as root, or carry unresolved critical vulnerabilities. Whichever engine you choose, run it in audit mode first, publish violations, fix the noise, and only then flip to enforce — otherwise you teach developers to resent the gate.
A supply-chain hardening checklist
1. Pin everything by digest — base images and CI actions referenced by immutable digest, never by mutable tags like latest. 2. Generate provenance on every build to reach SLSA Build Level 1 across the board before chasing higher levels. 3. Adopt keyless signing with cosign and OIDC so no long-lived signing keys exist to steal. 4. Produce and attach an SBOM, in SPDX or CycloneDX, as a signed attestation for each artifact. 5. Scan continuously, not just at build — new vulnerabilities land against yesterday's clean image. 6. Enforce at admission with Kyverno or Gatekeeper: no signature, no valid provenance, no deploy. 7. Least-privilege the pipeline — scoped, short-lived tokens, isolated build jobs, and separated build and deploy identities. 8. Log to a transparency record so signatures are auditable and non-repudiable.
North Africa, the EU CRA, and SBOM obligations
For software teams in Tunisia and across North Africa, this is not an abstract hygiene exercise — it is market access. The EU Cyber Resilience Act is phasing in obligations for products with digital elements, including SBOM production, coordinated vulnerability handling, and secure-by-default configuration. Any Tunisian firm shipping software or components into the EU, or subcontracting for an EU vendor, will increasingly be asked for exactly the artifacts this stack produces: an SBOM, provenance, and evidence of a managed vulnerability process.
- ▸Provenance as a sales asset: EU clients performing vendor due diligence can verify a North African supplier's build integrity cryptographically, shrinking the trust gap that distance and unfamiliarity create.
- ▸Compliance you can inherit: bake SLSA provenance and SBOM generation into the golden pipeline once, and every team in Tunis or Sfax produces CRA-relevant evidence without extra process.
- ▸Cost advantage without governance risk: nearshoring to Tunisia stays attractive only if controls travel with the code — verifiable supply chains let cost-competitive teams meet EU expectations without a governance discount.
- ▸Regional resilience: for fintech and regulated workloads serving EU markets, signed, attested pipelines dovetail with frameworks like DORA that scrutinise third-party and supply-chain risk.
What to do this quarter
- ▸Turn on provenance generation in your most-used pipeline and verify one attestation end to end with cosign.
- ▸Add signature and SBOM attestation as a required step for one production service.
- ▸Deploy Kyverno or Gatekeeper in audit mode and publish, without blocking, every image that fails signature or provenance checks.
- ▸Replace one long-lived registry or signing credential with OIDC-federated identity.
- ▸Draft a one-page SBOM and vulnerability-handling statement you could hand to an EU client tomorrow.
The direction of travel is unmistakable. Provenance is moving from a differentiator to a default, the way transport-layer encryption did — first exotic, then expected, soon assumed. As Sigstore signing spreads through language ecosystems and the CRA turns SBOMs into table stakes for the EU market, the teams that treated verifiable builds as core infrastructure in 2026 will find compliance is something their pipeline already emits, not a scramble before every audit. For engineering hubs in Tunisia and the wider region, that is the whole game: build the attested, policy-guarded pipeline once, and turn a cost advantage into a trust advantage that EU customers can verify for themselves, one signature at a time.