Versterking van de beveiliging van de toeleveringsketen met SLSA Level 3 en codeondertekening

Jarenlang draaide het veiligheidsdebat rond softwaredistributie om één vraag: is dit binaire bestand ondertekend? Een geldige digitale handtekening werd beschouwd als het keurmerk van vertrouwen, het bewijs dat een artefact afkomstig was van de persoon of instantie die het beweerde te vertegenwoordigen en niet was gemanipuleerd. Die aanname was echter altijd onvolledig, en de aanvallen op de toeleveringsketen van de afgelopen jaren hebben precies aangetoond hoe onvolledig die was.

De ongemakkelijke realiteit is dat een handtekening alleen de laatste stap bewijst. Het bevestigt dat degene die de ondertekeningssleutel bezat, het uiteindelijke resultaat heeft goedgekeurd. Het zegt niets over de vraag of de broncode die in dat resultaat is verwerkt, daadwerkelijk de code is die de ontwikkelaars hebben geschreven, of de buildomgeving is gecompromitteerd, of dat er ergens tussen de commit en de gecompileerde output een kwaadaardige stap is ingevoegd.

Dit is de kloof die het Supply-chain Levels for Software Artifacts (SLSA)-framework probeert te dichten, en met name SLSA Level 3 is waar codeondertekening helpt bij het creëren van een verifieerbare traceerbaarheidsketen die zich uitstrekt van broncode tot binair bestand. Deze blog legt uit wat SLSA Level 3 vereist, hoe het samenwerkt met codeondertekening en hoe organisaties de verifieerbare herkomst kunnen opbouwen waarop moderne softwarebeveiliging in de toeleveringsketen is gebaseerd.

Waarom is een handtekening alleen niet meer voldoende?

Om te begrijpen waarom SLSA belangrijk is, is het nuttig om precies te weten wat een codeondertekening wel en niet bewijst. Wanneer een binair bestand wordt ondertekend, bewijst de handtekening twee dingen: dat het artefact is goedgekeurd door een entiteit die de bijbehorende privésleutel bezit, en dat het artefact niet is gewijzigd sinds de ondertekening. Beide garanties zijn waardevol en codeondertekening blijft een essentiële beveiligingsmaatregel.

Maar het bewijst niet dat de broncode die in het binaire bestand is gecompileerd, overeenkomt met de broncode in uw repository. Het bewijst niet dat de build in een schone, ongecompromitteerde omgeving is uitgevoerd. Het bewijst niet dat er tijdens het buildproces geen ongeautoriseerde code is geïnjecteerd. En het bewijst evenmin dat de persoon of het systeem dat de ondertekening heeft uitgevoerd, bevoegd was om dat specifieke artefact vrij te geven. Een handtekening is een verklaring over het uiteindelijke object, niet over het proces dat ertoe heeft geleid.

De meest schadelijke aanvallen op de toeleveringsketen maken precies gebruik van deze blinde vlek. Ze vallen niet de handtekening zelf aan, omdat het aanvallen van de handtekening moeilijk en goed beveiligd is. In plaats daarvan vallen ze het bouwproces vóór de handtekening aan, waardoor kwaadaardige code door de legitieme pipeline stroomt en eruit komt met een perfect geldige handtekening. De handtekening is echt, maar het vertrouwen dat deze uitstraalt is misplaatst, omdat hetgeen ondertekend moet worden al corrupt was voordat het de ondertekeningsstap bereikte.

Wat organisaties nodig hebben, en wat softwaregebruikers steeds vaker eisen, is verifieerbaar bewijs van het volledige productieproces, niet alleen van de uiteindelijke goedkeuring. Ze moeten vragen kunnen beantwoorden zoals: welke exacte commit heeft dit binaire bestand geproduceerd, welk buildplatform heeft het gecompileerd, welke inputs zijn erin verwerkt, en kan dit alles cryptografisch worden bewezen in plaats van alleen maar te worden beweerd? Die verzameling verifieerbaar bewijs wordt provenance genoemd, en het genereren van fraudebestendige provenance is het kerndoel van het SLSA-framework.

Wat is SLSA en waarom bestaat het?

SLSA staat voor Supply-chain Levels for Software Artifacts en is een leveranciersneutraal beveiligingsraamwerk dat oorspronkelijk in 2021 door Google werd voorgesteld en nu als project wordt onderhouden door de Open Source Security Foundation (OpenSSF). Het doel ervan is om een ​​gemeenschappelijke, door de industrie overeengekomen set standaarden te bieden voor het beschrijven en verifiëren van de manier waarop software-artefacten worden gebouwd, zodat zowel producenten als gebruikers de integriteit van de toeleveringsketen kunnen beoordelen aan de hand van een gedeelde terminologie.

Het framework is gebouwd rond één centraal concept: herkomst. Herkomst is verifieerbare metadata die vastlegt waar, wanneer en hoe een software-artefact is geproduceerd. Een volledig herkomstrecord identificeert de bronrepository en de exacte commit, het buildplatform dat de build heeft uitgevoerd, de inputs en parameters die daarbij zijn gebruikt, en een cryptografische hash van het resulterende artefact. Wanneer deze herkomst wordt gegenereerd door een vertrouwd buildsysteem en op een zodanige manier wordt ondertekend dat de buildstappen zelf er niet mee kunnen knoeien, wordt het een fraudebestendig bewijs van hoe het artefact tot stand is gekomen.

Het is belangrijk om duidelijk te zijn over wat SLSA wel en niet is. SLSA is geen tool, scanner of product dat u installeert. Het is een specificatie die definieert hoe "veilig" eruitziet op verschillende niveaus van volwassenheid, en het is ontworpen om automatisch te worden afgedwongen via beleidsengines. Het is bovendien een aanvulling op, en geen vervanging van, andere beveiligingspraktijken. Kwetsbaarheidsscans identificeren bekende zwakke punten in code en afhankelijkheden, terwijl SLSA verifieert dat de build zelf niet is gemanipuleerd. De twee pakken verschillende bedreigingen aan en zijn het sterkst wanneer ze samen worden gebruikt.

Het raamwerk is aanzienlijk geëvolueerd. SLSA v1.0 werd uitgebracht in april 2023 en richtte de specificatie op het Build Track met niveaus 0 tot en met 3. SLSA v1.1 werd officieel goedgekeurd in april 2025, waarbij de precisie van de vereisten werd aangescherpt en verschillende eerdere aanbevelingen werden omgezet in strengere normatieve vereisten. SLSA v1.2, die het Source Track introduceerde en zich richtte op de integriteit van de broncode zelf, volgde in november 2025. Het raamwerk blijft zich ontwikkelen, maar het Build Track blijft de stabiele, breed geaccepteerde basis en is waar de relatie met codeondertekening het meest direct is.

Het SLSA Build Track definieert vier cumulatieve niveaus, genummerd van 0 tot en met 3. Elk niveau bouwt voort op het niveau eronder, wat betekent dat om niveau 3 te behalen, ook aan de eisen van niveau 1 en 2 moet worden voldaan. Deze cumulatieve structuur is bewust gekozen, omdat organisaties hierdoor SLSA stapsgewijs kunnen implementeren in plaats van in één keer een complete herziening van hun build-pipelines te proberen.

Niveau	Kernvereiste	Primaire dreiging aangepakt
Niveau 0	Geen enkele herkomstinformatie.	Geen bescherming; geen verifieerbaar bewijs van hoe de artefacten zijn vervaardigd.
Niveau 1	Er is een herkomstdocumentatie beschikbaar, waarin wordt beschreven hoe het artefact is vervaardigd.	Onbedoelde verspreiding van verkeerde versies; basis traceerbaarheid
Niveau 2	De herkomstgegevens worden ondertekend en gegenereerd door een gehost buildplatform.	Voorkomt dat de gebruiker de herkomst van de bestanden vervalst.
Niveau 3	Beveiligd, geïsoleerd buildplatform met ondertekeningsgeheimen die ontoegankelijk zijn voor de buildstappen.	Voorkomt vervalste herkomstgegevens, zelfs bij gecompromitteerde inloggegevens of bedreigingen van binnenuit.

Wat houdt SLSA Level 3 nu precies in?

SLSA Level 3 introduceert twee veeleisende eisen die veel verder gaan dan alleen het ondertekenen van een herkomstbewijs. Een nauwkeurig begrip hiervan is essentieel om te begrijpen hoe Level 3 een echte bewijsketen opbouwt.

De eerste vereiste is build-isolatie . De buildstappen moeten worden uitgevoerd in een geïsoleerde omgeving die niet kan worden beïnvloed door andere buildprocessen, en die omgeving mag niet worden hergebruikt tussen builds. In de praktijk betekent dit tijdelijke, afgeschermde omgevingen, zoals nieuw aangemaakte containers of virtuele machines die specifiek voor één build worden geconfigureerd en vervolgens worden verwijderd. Deze isolatie voorkomt dat de ene build de andere beïnvloedt, zelfs binnen hetzelfde project, waardoor een hele reeks aanvallen waarbij een gecompromitteerde build volgende builds besmet, wordt voorkomen.

De tweede en belangrijkste vereiste is dat de herkomstinformatie onvervalsbaar moet zijn . Het moet voor de gebruikers van het buildplatform zelf, inclusief degenen die de buildstappen definiëren, onmogelijk zijn om de herkomstinformatie te vervalsen. Dit wordt bereikt door ervoor te zorgen dat alle herkomstinformatie wordt gegenereerd door de buildservice binnen een vertrouwd controlepaneel, en, cruciaal, dat het geheime materiaal dat wordt gebruikt om de herkomst te ondertekenen, nooit toegankelijk is voor door gebruikers gedefinieerde buildstappen. De ondertekeningssleutels behoren tot het buildplatform, niet tot de buildconfiguratie die gebruikers beheren.

Deze tweede vereiste maakt niveau 3 zo krachtig, en het is hier dat de link met codeondertekening structureel wordt in plaats van incidenteel. Op niveau 3 kan zelfs een kwaadwillende insider met volledige toegang tot de buildconfiguratie de herkomst niet vervalsen, omdat de ondertekeningssleutel die die herkomst garandeert zich bevindt in een deel van het systeem waar de insider geen toegang toe heeft. De handtekening op de herkomst is daarom een ​​betrouwbare verklaring over de build, en niet iets dat door een gecompromitteerde buildstap zou kunnen zijn gefabriceerd.

Het resultaat is dat herkomstbewijs op niveau 3 antwoord geeft op vragen die een handtekening alleen niet kan beantwoorden. Het zegt niet alleen "dit artefact is goedgekeurd". Het zegt "dit artefact is gebouwd vanuit deze exacte broncommit, op dit beveiligde platform, via dit proces, en hier is cryptografisch bewijs gegenereerd door een systeem dat niet door de bouwstappen zelf gemanipuleerd had kunnen worden."

Hoe encryptieconsultancy kan helpen

Het opbouwen van een verifieerbare bewijsketen van broncode tot binaire code brengt precies de disciplines samen die de expertise van Encryption Consulting definiëren: het beschermen van ondertekeningssleutels, het reguleren van het gebruik ervan en het produceren van het controleerbare bewijs dat zowel beveiliging als compliance tegenwoordig vereisen. De connectie tussen SLSA Level 3 en codeondertekening is niet toevallig, omdat beide uiteindelijk afhankelijk zijn van de integriteit van de ondertekeningsinfrastructuur, en daar richt ons werk zich op.

Ons CodeSign Secure- platform biedt de basis voor een Level 3-keten van bewijsmateriaal. Het beschermt privésleutels in FIPS 140-3 en FIPS 140-2 Level 3 gevalideerde hardwarebeveiligingsmodules (HSM's) van leveranciers zoals Thales , Entrust , Utimaco en Securosys . Hierdoor bestaat het sleutelmateriaal dat gebruikt wordt om zowel artefacten als herkomstgegevens te ondertekenen nooit in softwarevorm en kan het niet worden achterhaald door een gecompromitteerde bouwstap.

Dit voldoet direct aan de SLSA Level 3-vereiste dat ondertekeningsgeheimen ontoegankelijk moeten blijven voor door de gebruiker gedefinieerde buildstappen. Het platform handhaaft op rollen gebaseerde toegangscontrole voor wie ondertekeningsbewerkingen kan aanvragen en goedkeuren, past RFC 3161-tijdstempels toe zodat handtekeningen gedurende de lange levenscyclus van uitgebrachte software verifieerbaar blijven, en registreert elke ondertekeningsgebeurtenis in een onveranderlijk auditspoor dat vastlegt wat er is ondertekend, wanneer, door wie en via welke pipelinefase.

Dat auditspoor is het verifieerbare bewijs dat een bewering over de integriteit van de build daadwerkelijk door een consument of toezichthouder kan worden gecontroleerd. Omdat CodeSign Secure direct integreert met CI/CD- platformen zoals Azure DevOps , Jenkins en GitLab , wordt ondertekenen een gecontroleerde, door beleid afgedwongen fase in de pipeline in plaats van een handmatige stap. Dit is precies het model dat de geautomatiseerde, platformgestuurde aanpak van SLSA vereist.

Naast het platform zelf helpen onze adviesteams organisaties bij het ontwerpen van de bredere architectuur die een verifieerbare bewijsketen vereist. Dit omvat alles, van het beoordelen van de huidige volwassenheid van uw bouw- en ondertekeningspipeline ten opzichte van de SLSA-niveaus, tot het structureren van de belangrijkste beheer- en isolatiecontroles die niveau 3 vereist, en het afstemmen van het resulterende bewijsmateriaal op de wettelijke kaders zoals de NIST SSDF , Executive Order 14028 en de EU Cyber ​​Resilience Act , die dit steeds vaker verwachten.

Voor organisaties die ook de onderliggende hardwarematige sleutelbeveiliging als beheerde functionaliteit nodig hebben, biedt onze HSM as a Service- oplossing FIPS-gevalideerde, leverancieronafhankelijke sleutelbeveiliging die zowel het ondertekenen van artefacten als het ondertekenen van herkomstgegevens kan ondersteunen, zonder dat de hardware intern beheerd hoeft te worden.

Conclusie

De tijd dat een geldige handtekening voldoende bewijs was voor de betrouwbaarheid van software is voorbij. De meest schadelijke aanvallen op de toeleveringsketen van de afgelopen jaren braken niet de handtekeningen; ze verstoorden het bouwproces vóór de ondertekening, waardoor kwaadaardige code ontstond met een volkomen legitieme handtekening. Om die kloof te dichten is verifieerbaar bewijs nodig van het hele traject van broncode tot binair bestand, en dat is precies wat SLSA, en SLSA Level 3 in het bijzonder, beoogt te leveren.

De relatie tussen SLSA Level 3 en codeondertekening is het belangrijkste inzicht. Het zijn geen concurrerende benaderingen, maar complementaire lagen binnen één enkele bewijsketen. Provenance toont aan hoe een artefact is vervaardigd en bewijst dat het zelfs door een insider niet vervalst had kunnen worden, terwijl codeondertekening aantoont dat het artefact en de herkomst ervan authentiek en ongewijzigd zijn.

Naarmate regelgeving steeds vaker aantoonbare in plaats van zelfverklaarde integriteit van de software vereist, en naarmate bedrijven en overheidsinstellingen minimale SLSA-niveaus als voorwaarde voor aanschaf stellen, verschuift de mogelijkheid om een ​​aantoonbare traceerbaarheidsketen voor elk binair bestand te creëren van een beveiligingsideaal naar een zakelijke noodzaak. De organisaties die deze capaciteit nu opbouwen, te beginnen met de digitale handtekening en stapsgewijs doorwerkend naar niveau 3, zullen degenen zijn die kunnen bewijzen, en niet alleen beloven, dat hun software te vertrouwen is.

Bij Encryption Consulting zijn ons CodeSign Secure- platform en onze adviesdiensten erop gericht om die basis te leggen. Als u werkt aan een verifieerbare traceerbaarheid van uw softwareleveringsketen, helpen we u daar graag bij.