SLSA-buildherkomst en -ondertekening in CI/CD-pipelines

De meeste beveiligingsteams beschikken tegenwoordig over een softwarelijst (Software Bill of Materials, SBOM) . Maar een lijst met softwarecomponenten vertelt slechts de helft van het verhaal. Het laat zien wat er in je software zit, maar zegt niets over hoe die software is gebouwd of of er tussen de broncode en de productieserver aan is geknoeid.

Het bewijzen van de integriteit van de build, en niet alleen het catalogiseren van componenten, is de lacune die buildprovenance en artifactsigning moeten dichten. Kort gezegd is buildprovenance een ondertekend, verifieerbaar document dat vastlegt hoe, waar en vanuit welke bron een software-artefact is gebouwd, en artifactsigning is het cryptografische zegel dat ervoor zorgt dat dit document niet kan worden gemanipuleerd.

Deze blog legt uit wat buildprovenance nu precies inhoudt, hoe de Supply-chain Levels for Software Artifacts (SLSA) frameworkniveaus in de praktijk werken en hoe het ondertekenen van software-artefacten in een CI/CD-pipeline past.

SLSA build provenance, defined: a signed in-toto attestation, generated by the build platform itself rather than a user-controlled script, that records the exact source commit, build system, and inputs behind an artifact, so a verifier can cryptographically confirm what was built and how, rather than trusting a developer’s or a CI log’s unverified claim.

Key Takeaways

An SBOM lists components; provenance proves how the build itself happened. The 2020 SolarWinds SUNBURST breach, the 2024 XZ Utils backdoor, and the 2025 Shai-Hulud npm worm all passed component-level checks because the compromise was in the build or publishing path, not a listed dependency.
SLSA v1.2 (November 2025) is the current stable release; its Build Track defines three levels (a fourth, hermetic reproducible builds, is planned but not yet part of the specification).
This page covers what provenance is and how the SLSA levels compare. For the detailed CI/CD implementation, OIDC service identity, dual signing, approval gates, sample workflow, see Versterking van de beveiliging van de toeleveringsketen met SLSA Level 3 en codeondertekening.
Signed provenance that nothing verifies at deployment provides no protection; verification has to be an enforced gate, not an optional check.

Waarom SBOM's alleen niet langer voldoende zijn

Een SBOM is in feite een onderdelenlijst. Het laat zien welke bibliotheken, pakketten en afhankelijkheden in je software zijn opgenomen. Dat is handig voor het traceren van bekende kwetsbaarheden en het beheren van licentieverplichtingen. Maar het zegt niets over de integriteit van je buildproces zelf.

Aanvallers zijn zich al jaren bewust van deze beperking. Bij de SolarWinds SUNBURST-aanval waren alle softwarecomponenten in de getroffen build legitiem. De aanvaller had de build-pipeline gecompromitteerd en kwaadaardige code in de gecompileerde output geïnjecteerd. Een SBOM (Software-Based Operations Monitor) zou schone, vertrouwde componenten hebben weergegeven. Het zou de inbreuk niet hebben gedetecteerd, omdat de aanval plaatsvond binnen de build zelf, niet binnen een afhankelijkheid.

Recentere incidenten volgen hetzelfde patroon. De XZ Utils-backdoor uit 2024 (CVE-2024-3094) en de Shai-Hulud npm-worm uit 2025 wisten beide componentniveau-controles te omzeilen. De Shai-Hulud-worm deed dit door vertrouwde pakketpublicatie- en CI/CD-workflows te compromitteren. In beide gevallen werd het build- of releasepad zelf gekaapt, niet een vermelde afhankelijkheid.

Daarom vragen toezichthouders, beveiligingsteams van bedrijven en DevSecOps-engineers nu om iets specifiekers. Ze willen cryptografisch, fraudebestendig bewijs dat een product afkomstig is van een bekende bron, met behulp van een gedefinieerd proces, op een geverifieerd buildsysteem. Dat bewijs wordt buildprovenance genoemd.

NIST SP 800-204D , gepubliceerd in februari 2024, behandelt dit direct. Het benadrukt cryptografisch ondertekende attestaties als een fundamenteel mechanisme voor het vaststellen van software-integriteit en -provenance in CI/CD-pipelines. De publicatie legt ook uit dat SBOM's alleen niet gebruikt kunnen worden voor kwetsbaarheidsbeheer, omdat ze een componenteninventaris bieden in plaats van cryptografisch bewijs van hoe software is gebouwd of of het bouwproces betrouwbaar was.

Dat cryptografische bewijs is precies wat de herkomstanalyse oplevert. De praktische vraag is dan wat het vastlegt en hoe die vastlegging is gestructureerd.

Wat is bouwprovenance?

Buildprovenance is een verifieerbaar document dat doorgaans cryptografisch is ondertekend en vier vragen over een software-artefact beantwoordt.

Wat: Het exacte artefact, geïdentificeerd door een cryptografische hash (SHA-256-digest).
Waar: De bronrepository en de specifieke commit die deze heeft gegenereerd.
Wanneer: Het tijdstip waarop de bouw werd uitgevoerd.
Hoe: Het buildsysteem, de workflowdefinitie, de runneromgeving en de gebruikte inputs.

Samen vormen deze details een traceerbare en verifieerbare keten van verantwoordelijkheid, van codecommit tot implementeerbaar artefact. Wanneer zich een incident voordoet, kunt u de oorzaak achterhalen via herkomstgegevens. Als er iets verdachts opvalt bij een implementatiepoort, kunt u de bewering cryptografisch verifiëren in plaats van te vertrouwen op een bewering van een ontwikkelaar of een CI-logboek dat iedereen met toegang tot de pipeline zou kunnen wijzigen.

De herkomst wordt vastgelegd met behulp van het in-toto attestatiekader. Een in-toto attestatie is een ondertekend document dat metadata koppelt aan een artefact. Het bestaat uit drie delen: het type verklaring (wat voor soort claim dit is), het onderwerp (het artefact, geïdentificeerd door de digest) en het predicaat (de feitelijke metadata, zoals de repository, workflow, build-inputs en builder-identiteit). SLSA Build Provenance is een gestandaardiseerd herkomstpredicaat dat is opgenomen in een in-toto attestatieverklaring.

Het vaststellen van herkomst is één ding; het bepalen van een meetbare norm voor de betrouwbaarheid ervan is de taak van het SLSA-raamwerk.

SLSA: Een raamwerk voor bouwintegriteit

SLSA is een open framework, beheerd door de Open Source Security Foundation (OpenSSF), dat steeds strengere eisen stelt aan de manier waarop software gebouwd moet worden en hoe herkomstgegevens gegenereerd en beschermd moeten worden. De huidige stabiele versie is SLSA v1.2 (november 2025), die een Source Track toevoegt aan de bestaande Build Track; de Build Track definieert drie verschillende niveaus van toenemende beveiliging.

SLSA Niveau 1: Er bestaat een herkomstbewijs.

Het bouwproces genereert een herkomstdocument dat beschrijft hoe het artefact is geproduceerd. Dit document wordt samen met het artefact verspreid. Op niveau 1 is de herkomst niet cryptografisch ondertekend. Iedereen die het bouwscript kan wijzigen, kan ook de herkomst wijzigen. Niveau 1 is een startpunt dat de traceerbaarheid verbetert en helpt bij incidentrespons, maar het voorkomt niet dat een vastberaden aanvaller claims vervalst.

SLSA-niveau 2: Ondertekend door het buildplatform.

De herkomstdocumentatie moet worden gegenereerd en ondertekend door het buildplatform zelf, niet door een door de gebruiker beheerd buildscript. De ondertekeningssleutel wordt beheerd door het platform en is niet toegankelijk voor de buildstappen. Dit onderscheid is cruciaal. Als een aanvaller een buildscript op niveau 2 compromitteert, kan hij geen geldig herkomstdocument vervalsen omdat hij geen toegang heeft tot de ondertekeningssleutel van het platform. Niveau 2 is voor de meeste teams het meest haalbare doel. Het is te bereiken met GitHub Actions of GitLab CI met een kleine aanpassing van de pipelineconfiguratie.

SLSA-niveau 3: Beveiligde en geïsoleerde bouwomgeving

De bouwomgeving is zodanig beveiligd dat de ondertekeningssleutel en het geheime materiaal nooit toegankelijk zijn voor de door de gebruiker gedefinieerde bouwstappen, zelfs niet als die stappen volledig gecompromitteerd zijn. Het bouwplatform dwingt isolatie af op infrastructuurniveau. Niveau 3 is het geschikte doelwit voor kritieke componenten, software die wordt geleverd aan gereguleerde omgevingen en alles met een groot aanvalsoppervlak.

Een eenvoudige manier om het te bekijken: Niveau 1 is een bon. Niveau 2 is een bon met een officiële platformstempel die de ontwikkelaar niet zelf had kunnen afdrukken. Niveau 3 is een bon die is geproduceerd in een afgesloten ruimte waar de operator geen toegang had tot het stempelmechanisme.

There is also a fourth level: covering hermetic, fully reproducible builds with two-party review. It exists in the original SLSA draft and is planned for a future release, but it is not part of the current v1.2 specification, so Level 3 is the highest level defined in the specification for a build platform to conform to today.

SLSA Build Track Levels, Side by Side

Niveau	Herkomstvereiste	Who Can Forge It	Typische inspanning
Niveau 1	Exists, distributed alongside the artifact	Anyone who can modify the build script	Low; add a provenance-generation step
Niveau 2	Generated and signed by the build platform, not the build script	No one without access to the platform’s own signing key	Moderate; achievable on GitHub Actions or GitLab CI with pipeline config
Niveau 3	Generated in a hardened, isolated build environment	No one, even with full build-step compromise	Higher; requires ephemeral, single-use build environments

Nu de niveaus duidelijk zijn, is de volgende stap om te bekijken hoe herkomst en ondertekening verlopen binnen een werkende CI/CD-pipeline.

Hoe de volledige workflow in CI/CD samenkomt

Hieronder wordt beschreven hoe het proces van buildprovenance en -ondertekening verloopt binnen een typische CI/CD-pipeline, van commit tot implementatie.

Het begint wanneer een ontwikkelaar code naar een branch pusht, en die push-gebeurtenis activeert de CI-pipeline.
Vervolgens wordt de build uitgevoerd, waarbij de broncode wordt gecompileerd of verpakt. Afhankelijkheden worden opgelost aan de hand van vastgelegde, op digests gebaseerde versies in plaats van veranderlijke tags.
De herkomstinformatie wordt gegenereerd door het platform zelf, niet door het buildscript. Dit produceert een volledige attestatie met de broncommit, workflow-identiteit, runner-omgeving en de SHA-256-hash van het uitvoerartefact.
Bij een sleutelloze ondertekeningsimplementatie wordt de attestatie ondertekend door een service die een kortstondig certificaat uitgeeft dat is gekoppeld aan de OIDC-identiteit (OpenID Connect) van het buildplatform. Deze service gebruikt het certificaat om de attestatie te ondertekenen en registreert de ondertekening in een openbaar, fraudebestendig transparantielogboek. Omdat het certificaat kortstondig is, zijn er geen permanente privésleutels die moeten worden opgeslagen, geroteerd of ingetrokken.
For production-tier releases, an approval gate requires sign-off from a defined quorum of approvers before the signing step proceeds, so no single compromised identity can push a release through on its own.
De ondertekende verklaring wordt vervolgens samen met het artefact bewaard in een containerregister of in een artefactenrepository, in een transparantielogboek, of in beide.
Tot slot vindt de verificatie plaats bij de implementatiepoort. Voordat een artefact naar de staging- of productieomgeving wordt gepromoveerd, controleert een beleidscontrole de handtekening, bevestigt dat de attestatie afkomstig is van de verwachte repository en workflow. Er wordt ook gecontroleerd of de artefactdigest overeenkomt met het herkomstrecord. Artefacten die de verificatie niet doorstaan, worden automatisch afgewezen.

GitLab CI biedt ingebouwde ondersteuning voor herkomstverificatie. Deze verificatie kan worden uitgevoerd met behulp van de GitHub CLI, een tool voor handtekeningverificatie of een Kubernetes admission controller die beleid afdwingt bij elke pod-implementatie.

Goedkeuringspoorten

Not every build needs a human approval step; internal or development builds can generate and sign provenance automatically. Production-tier releases are different: require M-of-N approval before the signing service acts on that provenance, enforced by the signing platform’s own policy engine rather than by pipeline logic a modified build step could route around. Decide in advance who the eligible approvers are for each release tier, and what happens if approval times out, whether the pipeline fails closed or falls back to a slower, explicitly manual path.

Foutafhandeling en terugdraaien

A provenance or signing failure should block the release, not degrade into a warning. If the platform can’t generate provenance, if approval isn’t granted, or if the signing service is unreachable, the artifact should not publish. Because keyless signing certificates are short-lived and don’t represent a standing credential, rollback here is narrower than a key-compromise scenario: if a signed, verified artifact later turns out to be built from a compromised source commit, the response is to revoke trust in that specific artifact at the verification policy (block that digest) and roll deployments back to the last known-good, independently verified artifact, not to touch the signing infrastructure itself.

Problemen oplossen

Symptoom	waarschijnlijke oorzaak	Wat te controleren?
Verification fails even though the artifact is legitimate	The attestation was generated by a build step instead of the platform’s trusted control plane	Confirm the CI platform’s native provenance feature is enabled, not a custom script generating the attestation
Attestation present but signature check fails	Verifier is checking against the wrong OIDC issuer or an expired transparency log entry	Confirm the expected certificate identity and issuer match the build platform actually used
Digest mismatch between artifact and provenance record	The artifact was rebuilt or repackaged after provenance was generated	Ensure signing happens on the exact artifact that will be published, with no post-provenance modification step
Third-party dependency has no provenance to check	The upstream package doesn’t publish SLSA provenance	Treat as a known gap; assess the risk based on that component’s role rather than assuming equivalence to a verified one

Het integreren hiervan in één enkele pipeline is eenvoudig; de uitrol ervan over de hele organisatie vereist een meer doordachte aanpak.

Overwegingen bij implementatie binnen de onderneming

Begin met de belangrijkste artefacten, niet met alles.

Niet elk onderdeel van een grote organisatie hoeft vanaf dag één aan SLSA Level 3 te voldoen. Begin met het identificeren van de softwarecomponenten die direct met klanten te maken hebben, die in gereguleerde omgevingen worden gebruikt of die deel uitmaken van kritieke infrastructuur. Pas SLSA Level 2 eerst toe op deze componenten, stel de verificatiepoorten in die de naleving afdwingen en rol het vervolgens breder uit. Deze gefaseerde aanpak houdt de inspanning beheersbaar en levert snel waarde op het gebied van compliance.

Verificatie is net zo belangrijk als ondertekening.

Veel teams implementeren digitale handtekeningen en gaan ervan uit dat het werk daarmee gedaan is. Provenance biedt pas echte beveiligingswaarde wanneer deze actief wordt geverifieerd op het moment van implementatie. Voeg een verificatiestap toe aan elke implementatiepipeline. Configureer uw Kubernetes admission controller of deployment gate om artefacten te weigeren die geen geldige, beleidsconforme attestatie hebben. Een artefact waarvan de provenance niet overeenkomt met de verwachte bronrepository, branch of workflow-identiteit, mag nooit in productie worden genomen.

Koppel afhankelijkheden aan samenvattingen

De herkomst van je build beschrijft de input voor je build alleen nauwkeurig als die input stabiel is. Als je pipeline afhankelijkheden dynamisch oplost op basis van veranderlijke versie-tags, kan een kwaadwillige update van een pakket in een openbaar register de inhoud van je artefact wijzigen zonder dat je broncode hoeft te worden aangepast. Koppel afhankelijkheden aan specifieke SHA-256-hashes in plaats van versie-tags. Dit maakt je builds reproduceerbaar en je herkomst betekenisvol.

Langdurig geldige digitale handtekeningen vereisen tijdstempels.

Certificaten met een korte geldigheidsduur zijn zeer geschikt voor ondertekening tijdens de build, waarbij verificatie kort na de ondertekening plaatsvindt. Als u release-artefacten jaren na de ondertekening moet verifiëren, zijn certificaten met een korte geldigheidsduur alleen niet voldoende, omdat het certificaat dan al lang is verlopen. In die gevallen hebt u ook een RFC 3161-tijdstempel nodig van een vertrouwde tijdstempelautoriteit. Deze koppelt de handtekening aan een specifiek tijdstip dat onafhankelijk van de geldigheid van het certificaat kan worden geverifieerd. Voor de hoogste mate van zekerheid kunt u uw ondertekeningssleutels verankeren in een HSM (hardware security module) om sleutelextractie te voorkomen en de fysieke beveiliging van uw ondertekeningsinfrastructuur te waarborgen.

Zelfs teams die deze werkwijzen nauwgezet volgen, kunnen nog steeds fouten maken. Daarom is het de moeite waard om de fouten te benoemen die in de praktijk het vaakst de herkomst van een build ondermijnen.

Waar de herkomstbepaling misgaat

Het genereren van herkomstinformatie binnen het buildscript: Als het buildscript de herkomstgenerator aanstuurt, kan een aanvaller die het script manipuleert de beweringen in de herkomstinformatie vervalsen. De herkomstinformatie moet door het buildplatform worden gegenereerd, buiten de door de gebruiker gecontroleerde stappen. Deze grens is wat SLSA Level 2 van Level 1 scheidt.
Ondertekenen zonder verificatiestappen: Het produceren van ondertekende verklaringen zonder deze tijdens de implementatie af te dwingen, schept een vals gevoel van veiligheid. Elk traject naar productie moet een verificatiestap bevatten die niet-conforme artefacten afwijst.
Het gebruik van langlevende sleutels zonder HSM-beveiliging of rotatieplannen: een gecompromitteerde ondertekeningssleutel maakt uw gehele vertrouwensketen ongeldig. Statische, in software opgeslagen sleutels moeten worden beschermd door HSM's en ondersteund door gedocumenteerde rotatie- en intrekkingsprocedures.
Het beschouwen van herkomstgegevens als een documentatieoefening: Herkomstgegevens bieden alleen waarde wanneer ze leidend zijn voor toegangscontrole en incidentresponsbeslissingen. Als uw verificatiebeleid niet automatisch wordt afgedwongen, is het slechts schijn van naleving, geen daadwerkelijke beveiliging.
Het negeren van de herkomst van afhankelijkheden van derden: Uw eigen broncode is misschien schoon, maar uw afhankelijkheden van derden mogelijk niet. Controleer de herkomst van SLSA-bestanden wanneer deze door een upstream-pakket worden gepubliceerd. En als dit niet het geval is, beoordeel dan of dit risico acceptabel is gezien de rol van het component in uw software.

Het vermijden van deze valkuilen maakt het verschil tussen een herkomstprogramma dat daadwerkelijk risico's vermindert en een programma dat alleen op papier bestaat.

Het consequent correct uitvoeren van deze details is waar specialistische begeleiding zijn vruchten afwerpt, vooral nu de cryptografie achter de beveiliging van gebouwen aan verandering onderhevig is.

Hoe encryptieconsultancy kan helpen

CodeSign Secure is het codeondertekeningsbeheerplatform van Encryption Consulting, geschikt voor grote bedrijven, en is ontworpen om de infrastructuurcontrole te bieden die diverse sectoren nodig hebben.

Sleutelbeheer ondersteund door HSM

CodeSign Secure slaat alle privésleutels voor ondertekening op in FIPS 140-2 Level 3 gecertificeerde hardwarebeveiligingsmodules (HSM's), en integreert met Thales Luna, Entrust nCipher, Utimaco, Securosys en cloud-HSM's van AWS en Azure. Sleutelisolatie per product wordt afgedwongen op HSM-partitieniveau: elke productlijn ontvangt een eigen, specifieke sleutel die in de hardware wordt gegenereerd en nooit wordt geëxporteerd.

M-of-N ondertekeningsquorum en RBAC

Het op rollen gebaseerde toegangscontrolemodel van het platform dwingt M-van-N-goedkeuringsvereisten af voor het ondertekenen van productiefirmware. Geen enkele persoon kan een ondertekeningsbewerking initiëren en goedkeuren. Ondertekeningsverzoeken, goedkeuringen en afwijzingen worden allemaal geregistreerd. De RBAC-configuratie zelf is controleerbaar en versiebeheerd, waardoor het gedocumenteerde ondertekeningsbeleid wordt geboden dat CRA-conformiteitsbeoordelingen vereisen.

Onveranderlijke auditlogboekregistratie

Elke ondertekeningsgebeurtenis in CodeSign Secure genereert een onveranderlijke logboekvermelding met de hash van het artefact, de sleutelidentificatie, het gebruikte certificaat, de goedkeurende identiteit en de RFC 3161-tijdstempel. De logboeken worden centraal opgeslagen, los van de infrastructuur voor ondertekening.

Ondersteuning voor platformonafhankelijke firmwareformaten

CodeSign Secure ondersteunt het ondertekenen van firmware-artefacten in alle formaten die een divers productportfolio vereist: .bin, .img, .hex, .fw, .dfu en .efi. Hiermee wordt voldaan aan de CRA-vereiste voor consistente controles over productlijnen heen, zonder dat de ondertekeningsinfrastructuur voor elk platform opnieuw hoeft te worden opgebouwd.

Ondersteuning voor post-kwantumcryptografie

CodeSign Secure v3.02 ondersteunt ML-DSA (FIPS 204, op beveiligingsniveaus ML-DSA-44, ML-DSA-65 en ML-DSA-87) en SLH-DSA (FIPS 205) van productiekwaliteit als afneembare handtekeningen naast klassieke algoritmen. Voor fabrikanten die producten bouwen met een CRA- ondersteuningsverplichting van vijf jaar of langer, is PQC-ondertekening vandaag de dag de architectuur die bescherming biedt tegen de HNDL-dreiging voordat een CRQC arriveert.

Integratie van CI/CD-pijplijn

CodeSign Secure integreert met Azure DevOps , Jenkins , GitLab CI en andere belangrijke pipelineplatformen via API's en commandoregelinterfaces. Het ondertekenen van firmware is een gecontroleerde, door beleid afgedwongen fase in de buildpipeline, geen handmatige stap.

Veelgestelde Vragen / FAQ

Does an SBOM already give me build provenance?

No. An SBOM lists the components inside an artifact; it says nothing about how the build itself was performed or whether the build process was tampered with. SolarWinds SUNBURST is the clearest example: every listed component was legitimate, but the build pipeline itself was compromised.

What’s the practical difference between SLSA Level 1 and Level 2?

Who can forge the provenance. At Level 1, anyone who can modify the build script can also modify the provenance record. At Level 2, provenance is generated and signed by the build platform itself, outside the user-controlled build steps, so a compromised script cannot forge it.

Is there a SLSA Level 4?

Not in the current v1.2 specification. A fourth level covering hermetic, fully reproducible builds with two-party review exists in the original SLSA draft and is planned for a future release, but Level 3 is the highest level defined in the current specification.

What happens if a third-party dependency doesn’t publish SLSA provenance?

That’s a known gap, not something to paper over. Assess the risk based on that component’s role in your software rather than assuming it’s equivalent to a dependency you can verify.

Conclusie

SBOM's geven beveiligingsteams inzicht in wat er in hun software terechtkomt. Buildprovenance en artifactsigning vormen de volgende stap. Ze bieden cryptografisch bewijs van hoe de software is gebouwd en helpen ervoor te zorgen dat deze ongewijzigd in productie wordt genomen. Het SLSA-framework vertaalt dit idee naar een praktisch, stapsgewijs traject. In plaats van teams te vragen alles in één keer op te lossen, definieert het duidelijke niveaus die stapsgewijs kunnen worden geïmplementeerd.

Niveau 1 vereist dat de herkomst van de build wordt gegenereerd en beschikbaar wordt gesteld, zodat teams een overzicht hebben van hoe elk artefact is geproduceerd. Niveau 2 legt de lat hoger door het buildplatform zelf die herkomst te laten genereren en ondertekenen. Dit voorkomt dat een gecompromitteerd buildscript de herkomst vervalst en is haalbaar op de meeste moderne CI-platforms. Niveau 3 versterkt de buildomgeving nog verder voor kritieke workloads en software met hoge betrouwbaarheidseisen. Voor veel organisaties biedt het vroegtijdig bereiken van niveau 2 een sterke basisbeveiliging, terwijl niveau 3 in de loop van de tijd kan worden ingevoerd wanneer een hogere mate van betrouwbaarheid vereist is. Organisaties die nu aan dit traject beginnen, zullen goed gepositioneerd zijn wanneer verifieerbare buildintegriteit een standaardvereiste wordt.

Wilt u inzicht krijgen in de huidige stand van zaken binnen uw organisatie op het gebied van productprovenance, het ondertekenen van artefacten of de gereedheid voor productkwaliteitscontrole (PQC) in uw toeleveringsketen? Neem dan contact met ons op om het gesprek te starten.