SLSA-byggproveniens och signering i CI/CD-pipelines

De flesta säkerhetsteam har idag en Software Bill of Materials (SBOM) . Men en lista över programvarukomponenter är bara halva historien. Den berättar vad som finns inuti din programvara men säger ingenting om hur programvaran byggdes eller om någon har manipulerat den mellan källdatabasen och produktionsservern.

Att bevisa byggintegritet, inte bara katalogisering av komponenter, är den lucka som byggproveniens och artefaktsignering är utformade för att täcka. Kort sagt är byggproveniens en signerad, verifierbar registrering av hur, var och från vilken källa en programvaruartefakt byggdes, och artefaktsignering är den kryptografiska försegling som gör den registreringen manipulationssäker.

Den här bloggen förklarar vad build proveniens egentligen innebär, hur Supply-chain Levels for Software Artifacts (SLSA)-ramverksnivåerna fungerar i praktiken och hur artefaktsignering passar in i en CI/CD-pipeline.

Varför SBOM:er ensamma inte längre räcker till

En SBOM är i huvudsak en stycklista. Den visar vilka bibliotek, paket och beroenden som ingår i din programvara. Det är användbart för att spåra kända sårbarheter och hantera licensskyldigheter. Men det säger ingenting om integriteten i själva byggprocessen.

Angripare har förstått denna begränsning i åratal. I SolarWinds SUNBURST-intrång var alla programvarukomponenter i den drabbade builden legitima. Angriparen hade komprometterat build-pipelinen och injicerat skadlig kod i den kompilerade utdata. En SBOM skulle ha listat rena, betrodda komponenter. Den skulle inte ha upptäckt komprometteringen eftersom attacken skedde inuti builden, inte inuti ett beroende.

Nyare incidenter följer samma mönster. Bakdörren för XZ Utils från 2024 (CVE-2024-3094) och npm-masken Shai-Hulud från 2025 klarade sig båda förbi kontroller på komponentnivå. Shai-Hulud-masken gjorde det genom att kompromettera betrodd paketpublicering och CI/CD-arbetsflöden. I båda fallen undergrävdes själva bygg- eller releasesökvägen, inte ett listat beroende.

Det är därför tillsynsmyndigheter, säkerhetsteam inom företag och DevSecOps-ingenjörer nu efterfrågar något mer specifikt. De vill ha kryptografiskt, manipuleringssäkert bevis på att en artefakt byggdes från en känd källa, med hjälp av en definierad process, på ett verifierat byggsystem. Det beviset kallas byggproveniens.

NIST SP 800-204D , publicerad i februari 2024, tar upp detta direkt. Den betonar kryptografiskt signerade attesteringar som en grundläggande mekanism för att fastställa programvaruintegritet och proveniens i CI/CD-pipelines. Publikationen förklarar också att SBOM:er ensamma inte kan användas för sårbarhetshantering eftersom de tillhandahåller en komponentinventering snarare än kryptografiska bevis på hur programvara byggdes eller om byggprocessen var tillförlitlig.

Det kryptografiska beviset är precis vad byggproveniens tillhandahåller. Den praktiska frågan är då vad det registrerar och hur den posten är strukturerad.

Vad är byggproveniens?

Byggproveniens är en verifierbar post som vanligtvis är kryptografiskt signerad och besvarar fyra frågor om en programvaruartefakt.

• Vad: Den exakta artefakten, identifierad av en kryptografisk hash (SHA-256-digest).
• Var: Källkodsförrådet och den specifika commit som producerade det.
• När: Tidpunkten då bygget utfördes.
• Hur: Byggsystemet, arbetsflödesdefinitionen, löparmiljön och använda indata.

Tillsammans skapar dessa detaljer en spårbar, verifierbar spårbarhetskedja från kodcommit till distributionsbar artefakt. När en incident inträffar kan du spåra bakåt genom proveniensregister. När något ser misstänkt ut vid en distributionsgate kan du verifiera anspråket kryptografiskt snarare än att förlita dig på en utvecklarpåstående eller en CI-logg som vem som helst med pipeline-åtkomst kan ändra.

Proveniens uttrycks med hjälp av in-toto-attesteringsramverket. En in-toto-attestering är ett signerat dokument som binder metadata till en artefakt. Den har tre delar: uttalandetypen (vilken typ av anspråk detta är), ämnet (artefakten, identifierad av dess sammanfattning) och predikatet (de faktiska metadata, såsom arkivet, arbetsflödet, byggindata och byggarens identitet). SLSA Build Provenance är ett standardiserat provenienspredikat som ingår i en in-toto-attesteringsuttalelse.

Att definiera proveniens är en sak; att sätta en mätbar ribba för hur tillförlitligt det måste vara är SLSA-ramverkets uppgift.

SLSA: Ett ramverk för byggintegritet

SLSA är ett öppet ramverk som underhålls av Open Source Security Foundation (OpenSSF) och som definierar allt striktare krav för hur programvara ska byggas och hur proveniens ska genereras och skyddas. Den nuvarande stabila utgåvan är SLSA v1.2 (november 2025), som lägger till ett källspår till det befintliga byggspåret; byggspåret definierar tre distinkta nivåer av ökad säkerhet.

SLSA Nivå 1: Proveniens finns

Byggprocessen genererar ett proveniensdokument som beskriver hur artefakten producerades. Detta dokument distribueras tillsammans med artefakten. På nivå 1 är proveniensen inte kryptografiskt signerad. Alla som kan ändra byggskriptet kan också ändra proveniensen. Nivå 1 är en utgångspunkt som förbättrar spårbarheten och hjälper till med incidenthantering, men det hindrar inte en beslutsam angripare från att förfalska anspråk.

SLSA Nivå 2: Signerad av Byggplattformen

Proveniens måste genereras och signeras av själva byggplattformen, inte av ett användarkontrollerat byggskript. Signeringsnyckeln innehas av plattformen och är inte tillgänglig för byggstegen. Denna distinktion är avgörande. Om en angripare komprometterar ett byggskript på nivå 2 kan de inte förfalska ett giltigt proveniensdokument eftersom de inte har tillgång till plattformens signeringsnyckel. Nivå 2 är det praktiska målet för de flesta team. Det är uppnåeligt på GitHub Actions eller GitLab CI med en liten mängd pipeline-konfiguration.

SLSA Nivå 3: Härdad och isolerad byggmiljö

Byggmiljön är härdad så att signeringsnyckeln och det hemliga materialet aldrig är åtkomliga för de användardefinierade byggstegen, även om dessa steg är helt komprometterade. Byggplattformen framtvingar isolering på infrastrukturnivå. Nivå 3 är det lämpliga målet för kritiska komponenter, programvara som skickas till reglerade miljöer och allt med en attackyta med hög konsekvens.

Ett enkelt sätt att tänka på det: Nivå 1 är ett kvitto. Nivå 2 är ett kvitto med en officiell plattformsstämpel som utvecklaren inte kunde ha skrivit ut själv. Nivå 3 är ett kvitto som produceras i ett låst rum där operatören inte hade tillgång till stämpelmekanismen.

Det finns också en fjärde nivå: som täcker hermetiska, fullt reproducerbara byggen med tvåpartsgranskning. Den finns i det ursprungliga SLSA-utkastet och är planerad för en framtida utgåva, men den är inte en del av den nuvarande v1.2-specifikationen, så nivå 3 är den högsta nivån du kan certifiera mot idag.

När nivåerna är klara är nästa steg att se hur proveniens och signering flödar genom en fungerande CI/CD-pipeline.

Hur hela arbetsflödet kommer samman i CI/CD

Så här flyter byggproveni och signering genom en typisk CI/CD-pipeline från commit till distribution.

• Det börjar när en utvecklare skickar kod till en gren, och den push-händelsen utlöser CI-pipelinen.
• Byggnaden körs sedan och kompilerar eller paketerar källkoden, med beroenden som lösts från fästa digest-baserade versioner snarare än muterbara taggar.
• Proveniens genereras av själva plattformen, inte byggskriptet, som producerar en in-toto-attestering som fångar källkoden, arbetsflödesidentiteten, löparmiljön och SHA-256-sammanfattningen av utdataartefakten.
• I en nyckelfri signeringsimplementering signeras attesteringen av en tjänst som utfärdar ett kortlivat certifikat kopplat till byggplattformens OIDC-identitet (OpenID Connect), använder det för att signera attesteringen och registrerar signeringshändelsen i en offentlig, manipulationssäker transparenslogg. Eftersom certifikatet är kortlivat finns det inga långlivade privata nycklar att lagra, rotera eller återkalla.
• Det undertecknade intyget lagras sedan tillsammans med artefakten i en behållarregistret eller artefaktförråd, i en transparenslogg, eller i båda.
• Slutligen körs verifieringen vid distributionsgaten. Innan en artefakt flyttas till mellanlagring eller produktion verifierar en policykontroll signaturen och bekräftar att attesteringen kom från det förväntade arkivet och arbetsflödet. Den kontrollerar också att artefaktsammanfattningen matchar proveniensposten. Artefakter som inte klarar verifieringen avvisas automatiskt.

GitLab CI har inbyggt stöd för proveniens. Verifiering kan göras med hjälp av GitHub CLI, ett signaturverifieringsverktyg eller en Kubernetes - admission controller som tillämpar policyer för varje pod-distribution.

Att koppla detta till en enda pipeline är enkelt; att implementera det i en hel organisation kräver en mer medveten strategi.

Att tänka på vid implementering av företag

Börja med kritiska artefakter, inte allt

Inte alla artefakter i en stor organisation behöver SLSA nivå 3 från dag ett. Börja med att identifiera vilka programvarukomponenter som är kundvända, levereras till reglerade miljöer eller ingår i kritisk infrastruktur. Tillämpa SLSA nivå 2 på dessa först, etablera verifieringsgrindarna som tillämpar det och rulla sedan ut det mer allmänt. Denna etappvisa metod gör arbetet hanterbart samtidigt som den snabbt levererar värde för efterlevnad.

Verifiering är lika viktigt som signering

Många team implementerar signering och antar att arbetet är klart. Proveniens ger bara ett verkligt säkerhetsvärde när det aktivt verifieras vid distributionstillfället. Lägg till ett verifieringssteg i varje distributionspipeline. Konfigurera din Kubernetes-admission controller eller distributionsgate för att avvisa artefakter som saknar en giltig, policykompatibel attestering. En artefakt vars proveniens inte matchar den förväntade källförvarings-, gren- eller arbetsflödesidentiteten bör aldrig nå produktion.

Fäst beroenden till sammanfattningar

Byggproveniens beskriver korrekt indata till din build endast om dessa indata är stabila. Om din pipeline löser beroenden dynamiskt från föränderliga versionstaggar kan en skadlig uppdatering av ett offentligt registerpaket ändra vad som hamnar i din artefakt utan att din källkod ändras. Fäst beroenden till specifika SHA-256-sammanfattningar snarare än versionstaggar. Det är detta som gör dina builds reproducerbara och din proveniens meningsfull.

Långlivade signaturer kräver tidsstämplar

Kortlivade signeringscertifikat är väl lämpade för signering under byggtid där verifiering sker kort efter signering. Om du behöver verifiera releaseartefakter år efter att de signerades, räcker inte kortlivade certifikat ensamma eftersom certifikatet kommer att ha löpt ut långt före verifieringen. I dessa fall behöver du också en RFC 3161-tidsstämpel från en betrodd tidsstämpelutfärdare, som binder signaturen till en tidpunkt som kan verifieras oberoende av certifikatets giltighet. För högsta möjliga säkerhet, förankra dina signeringsnycklar i en HSM (hårdvarusäkerhetsmodul) för att förhindra nyckelutvinning och säkerställa den fysiska säkerheten för din signeringsinfrastruktur.

Även team som följer dessa metoder noggrant kan fortfarande snubbla, så det är värt att påpeka de misstag som oftast undergräver byggproveniens i praktiken.

Där proveniensen går fel

• Generera proveniens inuti byggskriptet: Om byggskriptet styr proveniensgeneratorn kan en angripare som komprometterar skriptet förfalska vad proveniensen påstår sig vara. Proveniens måste genereras av byggplattformen, utanför de användarkontrollerade stegen. Denna gräns är det som skiljer SLSA nivå 2 från nivå 1.
• Signering utan verifieringsgrindar: Att producera signerade attesteringar utan att tillämpa dem vid driftsättning skapar en falsk trygghetskänsla. Varje väg till produktion måste innehålla ett verifieringssteg som avvisar icke-kompatibla artefakter.
• Användning av nycklar med lång livslängd utan HSM-skydd eller rotationsplaner: En komprometterad signeringsnyckel ogiltigförklarar hela din förtroendekedja. Statiska, programvarulagrade nycklar måste skyddas av HSM:er och stödjas av dokumenterade rotations- och återkallningsprocedurer.
• Att behandla proveniens som en dokumentationsövning: Proveniens ger värde endast när den driver beslut om åtkomstkontroll och incidenthantering. Om din verifieringspolicy inte tillämpas automatiskt erbjuder den en efterlevnadsstrategi, inte faktisk säkerhet.
• Ignorera tredjepartsberoenden: Din källkod från första part kan vara ren, men dina tredjepartsberoenden kanske inte är rena. När ett uppströmspaket publicerar SLSA-proveniens, verifiera det. Och om det inte gör det, bedöm om den luckan är en acceptabel risk med tanke på komponentens roll i din programvara.

Att undvika dessa fallgropar är skillnaden mellan ett proveniensprogram som verkligen minskar risken och ett som bara existerar på pappret.

Att få dessa detaljer korrekta konsekvent är där specialistvägledning lönar sig, särskilt i takt med att kryptografin bakom byggsäkerhet börjar förändras.

Hur krypteringskonsulting kan hjälpa

CodeSign Secure är Encryption Consultings plattform för kodsigneringshantering i företagsklass, utformad för att tillhandahålla de infrastrukturkontroller som branscher behöver.

HSM-baserad nyckelhantering

CodeSign Secure lagrar alla privata signeringsnycklar i FIPS 140-2 nivå 3-certifierade hårdvarusäkerhetsmoduler, som integreras med Thales Luna, Entrust nCipher, Utimaco, Securosys och molnbaserade HSM:er från AWS och Azure. Produktspecifik isolering av nyckeln sker på HSM-partitionsnivå: varje produktlinje får sin egen dedikerade nyckel, som genereras inuti hårdvaran och aldrig exporteras.

M-of-N-signeringsquorum och RBAC

Plattformens rollbaserade åtkomstkontrollmodell tillämpar krav på M-of-N-godkännande för signering av produktionsfirmware. Ingen enskild individ kan initiera och godkänna en signeringsoperation. Signeringsförfrågningar, godkännanden och avslag loggas alla. Själva RBAC-konfigurationen är granskningsbar och versionskontrollerad, vilket ger den dokumenterade signeringspolicy som CRA-överensstämmelsebedömningar kräver.

Oföränderlig granskningsloggning

Varje signeringshändelse i CodeSign Secure genererar en oföränderlig loggpost som registrerar artefaktens hash, nyckelidentifieraren, det använda certifikatet, den godkännande identiteten och RFC 3161-tidsstämpeln. Loggarna är centraliserade och lagras separat från signeringsinfrastrukturen.

Stöd för firmwareformat över flera plattformar

CodeSign Secure stöder signering av firmware-artefakter i alla format som en varierad produktportfölj kräver: .bin, .img, .hex, .fw, .dfu och .efi, vilket uppfyller CRA:s krav på konsekventa kontroller över produktlinjer utan att behöva bygga om signeringsinfrastrukturen för varje plattform.

Stöd för postkvantkryptografi

CodeSign Secure v3.02 stöder ML-DSA i produktionsklass (FIPS 204, på säkerhetsnivåerna ML-DSA-44, ML-DSA-65 och ML-DSA-87) och SLH-DSA (FIPS 205) som avtagbara signaturer vid sidan av klassiska algoritmer. För tillverkare som bygger produkter med CRA- supportskyldigheter på över fem år är PQC-signering idag den arkitektur som skyddar mot HNDL-hotet innan en CRQC anländer.

CI/CD Pipeline Integration

CodeSign Secure integreras med Azure DevOps , Jenkins , GitLab CI och andra större pipeline-plattformar via API- och kommandoradsgränssnitt. Firmware-signering är ett kontrollerat, policystyrt steg i byggpipelinen, inte ett manuellt steg.

Slutsats

SBOM:er ger säkerhetsteam insyn i vad som ingår i deras programvara. Byggproveniens och artefaktsignering tar nästa steg. De ger dig kryptografiskt bevis på hur programvaran byggdes och de hjälper till att bekräfta att den når produktionskedjan oförändrad. SLSA-ramverket förvandlar den idén till en praktisk, etappvis process. Istället för att be teamen att lösa allt på en gång definierar det tydliga nivåer som kan antas stegvis.

Nivå 1 kräver att byggproveniens genereras och görs tillgänglig, vilket ger team en förteckning över hur varje artefakt producerades. Nivå 2 höjer ribban genom att byggplattformen själv genererar och signerar proveniensen. Detta förhindrar att ett komprometterat byggskript förfalskar den, och det är uppnåeligt på de flesta moderna CI-plattformar. Nivå 3 hårdgör byggmiljön ytterligare för kritiska arbetsbelastningar och programvara med hög säkerhetsnivå. För många organisationer ger det en stark säkerhetsbaslinje att nå nivå 2 tidigt, medan nivå 3 kan implementeras över tid där högre säkerhetsnivå krävs. Organisationer som påbörjar denna resa nu kommer att vara väl positionerade eftersom verifierbar byggintegritet blir en grundläggande förväntan.

Om du vill förstå var din organisation står idag gällande byggnadens ursprung, artefaktsignering eller PQC-beredskap för din leveranskedja, kontakta oss för att starta samtalet.