I åratal kretsade säkerhetsdiskussionen kring programdistribution kring en enda fråga: är denna binärfil signerad? En giltig digital signatur behandlades som ett förtroendestämpel, ett bevis på att en artefakt kom från den den påstod sig komma ifrån och inte hade ändrats. Det antagandet var alltid ofullständigt, och attackerna i leveranskedjan under de senaste åren har avslöjat exakt hur ofullständigt det var.
Den obekväma verkligheten är att en signatur bara bevisar det sista steget. Den bekräftar att den som innehade signeringsnyckeln godkände den slutliga artefakten. Den säger ingenting om huruvida källkoden som ingick i den artefakten var den kod som utvecklarna faktiskt skrev, om byggmiljön komprometterades eller om ett skadligt steg injicerades någonstans mellan commiten och den kompilerade utdata.
Det är detta gap som ramverket Supply-chain Levels for Software Artifacts (SLSA) är utformat för att täcka, och det är särskilt SLSA Level 3 som kodsignering hjälper till att skapa en verifierbar spårbarhetskedja som sträcker sig från källkod till binärfil. Den här bloggen förklarar vad SLSA Level 3 kräver, hur det fungerar hand i hand med kodsignering och hur organisationer kan bygga den verifierbara proveniens som modern säkerhet i programvaruleveranskedjan är beroende av.
Varför räcker det inte längre med en enda signatur?
För att förstå varför SLSA är viktigt är det bra att vara tydlig med vad en kodsignatur bevisar och inte bevisar. När en binärfil signeras fastställer signaturen två saker: att artefakten godkändes av en enhet som innehar motsvarande privata nyckel, och att artefakten inte har modifierats sedan den signerades. Båda dessa garantier är värdefulla, och kodsignering är fortfarande en viktig säkerhetskontroll.
Men det bevisar inte att källkoden som kompilerats till binärfilen matchar källkoden i ditt arkiv. Det bevisar inte att bygget kördes i en ren, komprometterad miljö. Det bevisar inte att inget obehörigt byggsteg injicerade ytterligare kod längs vägen. Och det bevisar inte att personen eller systemet som utlöste signeringsoperationen var behörig att släppa just den artefakten. En signatur är ett uttalande om det slutliga objektet, inte om resan som producerade det.
De mest skadliga attackerna i leveranskedjan utnyttjar just denna blinda fläck. De attackerar inte signaturen, eftersom det är svårt och välförsvarat att attackera signaturen. Istället attackerar de byggprocessen uppströms signaturen, så att skadlig kod flödar genom den legitima pipelinen och dyker upp med en helt giltig signatur bifogad. Signaturen är verklig men det förtroende den förmedlar är felaktigt, eftersom det som signerades redan var korrupt innan det nådde signeringssteget.
Det organisationer behöver, och det som konsumenter av programvara i allt högre grad kräver, är verifierbara bevis om hela produktionsprocessen, inte bara det slutliga godkännandet. De behöver kunna svara på frågor som: exakt vilken commit som producerade denna binärfil, vilken byggplattform kompilerade den, vilka indata som användes, och kan allt detta kryptografiskt bevisas snarare än bara hävdas. Denna mängd verifierbara bevis kallas proveniens, och att generera manipulationssäker proveniens är kärnsyftet med SLSA-ramverket.
Vad är SLSA och varför finns det?
SLSA står för Supply-chain Levels for Software Artifacts och är ett leverantörsneutralt säkerhetsramverk som ursprungligen föreslogs av Google 2021 och nu underhålls som ett projekt under Open Source Security Foundation (OpenSSF). Dess syfte är att tillhandahålla en gemensam, branschöverenskommen uppsättning standarder för att beskriva och verifiera hur programvaruartefakter byggs, så att både producenter och konsumenter kan resonera om leveranskedjans integritet med hjälp av ett gemensamt ordförråd.
Ramverket är byggt kring ett enda centralt koncept: proveniens. Proveniens är verifierbara metadata som registrerar var, när och hur en programvaruartefakt producerades. En komplett provenienspost identifierar källförvaret och exakt commit, byggplattformen som utförde bygget, de indata och parametrar som användes, och en kryptografisk sammanfattning av den resulterande artefakten. När denna proveniens genereras av ett betrott byggsystem och signeras på ett sätt som själva byggstegen inte kan manipulera, blir den ett manipuleringssäkert bevis på hur artefakten uppstod.
Det är viktigt att vara tydlig med vad SLSA är och inte är. SLSA är inte ett verktyg, en skanner eller en produkt som du installerar. Det är en specifikation som definierar vad "säker" ser ut på progressiva mognadsnivåer, och den är utformad för att kunna verkställas automatiskt genom policymotorer. Den kompletterar snarare än ersätter andra säkerhetsrutiner. Sårbarhetsskanning identifierar kända svagheter i kod och beroenden, medan SLSA verifierar att själva bygget inte har manipulerats. De två adresserar olika hot och är starkast när de används tillsammans.
Ramverket har utvecklats avsevärt. SLSA v1.0 släpptes i april 2023 och fokuserade specifikationen på Build Track med nivåerna 0 till 3. SLSA v1.1 godkändes officiellt i april 2025, vilket skärpte precisionen i kraven och omvandlade flera tidigare rekommendationer till strängare normativa krav. SLSA v1.2, som introducerade Source Track som adresserade källkodens integritet, följde i november 2025. Ramverket fortsätter att mogna, men Build Track är fortfarande den stabila, allmänt använda grunden, och det är där relationen till kodsignering är som mest direkt.
SLSA-byggspåret definierar fyra kumulativa nivåer, numrerade 0 till 3. Varje nivå bygger på den underliggande, vilket innebär att för att uppnå nivå 3 krävs det att även kraven i nivå 1 och 2 uppfylls. Denna kumulativa struktur är avsiktlig eftersom den tillåter organisationer att införa SLSA stegvis snarare än att försöka göra en fullständig översyn av sina byggpipelines på en gång.
| Nivå | Kärnkrav | Primärt hot adresserat |
|---|---|---|
| Nivå 0 | Ingen proveniens alls | Inget skydd; inga verifierbara bevis på hur artefakter byggdes |
| Nivå 1 | Proveniens finns, som beskriver hur artefakten byggdes | Oavsiktlig distribution av fel versioner; grundläggande spårbarhet |
| Nivå 2 | Proveniens signeras och genereras av en värdbaserad byggplattform | Förhindrar att bygghyresgästen förfalskar sitt ursprung |
| Nivå 3 | Härdad, isolerad byggplattform med signeringshemligheter som inte är tillgängliga för byggsteg | Förhindrar förfalskad proveniens även från komprometterade inloggningsuppgifter eller insiderhot |
Vad krävs egentligen för SLSA nivå 3?
SLSA Nivå 3 introducerar två krävande krav som går långt utöver att bara signera proveniens. Att förstå dem exakt är nyckeln till att förstå hur Nivå 3 bygger en genuin spårbarhetskedja.
Det första kravet är byggisolering . Byggstegen måste köras i en isolerad miljö som inte kan påverkas av andra byggprocesser, och den miljön får inte återanvändas mellan byggen. I praktiken innebär detta kortlivade, sandlådebaserade miljöer, såsom nyligen skapade containrar eller virtuella maskiner som är specifikt avsedda för en enskild bygg och sedan förstörda. Denna isolering förhindrar att en byggkörning stör en annan, även inom samma projekt, vilket stänger dörren för en hel klass av attacker där en komprometterad bygg kontaminerar efterföljande byggen.
Det andra och viktigaste kravet är att proveniensen måste vara omöjlig att förfalska . Det måste vara omöjligt för byggplattformens egna användare, inklusive de personer som definierar byggstegen, att förfalska proveniensinformation. Detta uppnås genom att säkerställa att all proveniens genereras av byggtjänsten inom ett betrott kontrollplan, och framför allt att det hemliga materialet som används för att signera proveniensen aldrig är tillgängligt för användardefinierade byggsteg. Signeringsnycklarna tillhör byggplattformen, inte den byggkonfiguration som användarna kontrollerar.
Det är detta andra krav som gör nivå 3 så kraftfull, och det är där kopplingen till kodsignering blir strukturell snarare än tillfällig. På nivå 3 kan inte ens en illvillig insider som har fullständig åtkomst till byggkonfigurationen förfalska proveniens, eftersom signeringsnyckeln som garanterar den proveniensen finns i en del av systemet som insidern inte kan nå. Signaturen på proveniensen är därför ett trovärdigt uttalande om bygget, inte något som ett komprometterat byggsteg kunde ha skapat.
Resultatet är att proveniensnivå 3 besvarar de frågor som en signatur ensam inte kan. Den säger inte bara "denna artefakt godkändes". Den säger "denna artefakt byggdes från exakt denna källkod, på denna härdade plattform, genom denna process, och här är kryptografiskt bevis genererat av ett system som själva byggstegen inte kunde ha manipulerat."
Hur krypteringskonsulting kan hjälpa
Att bygga en verifierbar spårbarhetskedja från källa till binärkod sammanför exakt de discipliner som definierar Encryption Consultings expertis: att skydda signeringsnycklar, styra hur de används och producera de granskningsbara bevis som både säkerhet och efterlevnad nu kräver. Sambandet mellan SLSA nivå 3 och kodsignering är inte en tillfällighet, eftersom båda i slutändan vilar på signeringsinfrastrukturens integritet, och det är där vårt arbete är fokuserat.
Vår CodeSign Secure- plattform tillhandahåller den signeringsgrund som en nivå 3-kedja för förvaring är beroende av. Den skyddar privata signeringsnycklar i FIPS 140-3 och FIPS 140-2 nivå 3-validerade hårdvarusäkerhetsmoduler (HSM) från leverantörer som Thales , Entrust , Utimaco och Securosys , så att nyckelmaterialet som används för att signera både artefakter och proveniens aldrig existerar i programvaruform och inte kan extraheras av ett komprometterat byggsteg.
Detta adresserar direkt SLSA nivå 3-kravet att signeringshemligheter ska förbli oåtkomliga för användardefinierade byggsteg. Plattformen tillämpar rollbaserad åtkomstkontroll över vem som kan begära och godkänna signeringsåtgärder, tillämpar RFC 3161-tidsstämpling så att signaturer förblir verifierbara under hela den långa livscykeln för släppt programvara och registrerar varje signeringshändelse i en oföränderlig revisionslogg som fångar upp vad som signerades, när, av vems behörighet och genom vilket pipeline-steg.
Den revisionsloggen är det verifierbara bevis som förvandlar ett påstående om byggintegritet till något som en konsument eller tillsynsmyndighet faktiskt kan kontrollera. Eftersom CodeSign Secure integreras direkt i CI/CD -plattformar, inklusive Azure DevOps , Jenkins och GitLab , blir signering ett styrt, policystyrt steg i processen snarare än ett manuellt steg, vilket är just den modell som SLSA:s automatiserade, byggplattformsdrivna tillvägagångssätt kräver.
Utöver själva plattformen hjälper våra rådgivande team organisationer att utforma den bredare arkitektur som en verifierbar spårbarhetskedja kräver, från att bedöma den nuvarande mognaden för er bygg- och signeringspipeline mot SLSA-nivåerna, till att strukturera nyckelhanterings- och isoleringskontrollerna som nivå 3 kräver, till att anpassa de resulterande bevisen till de regelverk som NIST SSDF , Executive Order 14028 och EU:s Cyber Resilience Act som i allt högre grad kräver det.
För organisationer som också behöver det underliggande hårdvarunyckelskyddet levererat som en hanterad funktion, erbjuder vårt HSM as a Service- erbjudande FIPS-validerat, leverantörsoberoende nyckelskydd som kan förankra både artefaktsignering och provenienssignering utan bördan av att driva hårdvaran internt.
Slutsats
Tiden då en giltig signatur var tillräckligt bevis på programvarans tillförlitlighet är förbi. De mest skadliga attackerna i leveranskedjan under senare år förstörde inte signaturer; de korrumperade byggprocessen före signering, så att skadlig kod uppstod med en helt legitim signatur bifogad. För att täppa till den luckan krävs verifierbara bevis om hela resan från källkod till binärkod, och det är vad SLSA, och SLSA nivå 3 i synnerhet, utformades för att tillhandahålla.
Sambandet mellan SLSA nivå 3 och kodsignering är den viktigaste insikten. De är inte konkurrerande metoder utan kompletterande lager i en enda spårbarhetskedja. Proveniens fastställer hur en artefakt byggdes och bevisar att den inte ens kunde ha förfalskats av en insider, medan kodsignering fastställer att artefakten och dess proveniens är autentiska och oförändrade.
I takt med att regelverk i allt högre grad kräver verifierbar snarare än självbekräftad byggintegritet, och i takt med att företag och myndigheter börjar kräva miniminivåer av SLSA som ett villkor för upphandling, går möjligheten att producera en verifierbar spårbarhetskedja för varje binärfil från ett säkerhetsideal till en affärsnödvändighet. De organisationer som bygger denna kapacitet nu, med början i signeringsgrunden och gradvis arbetar mot nivå 3, kommer att vara de som kan bevisa, inte bara lova, att deras programvara kan litas på.
På Encryption Consulting är vår CodeSign Secure- plattform och rådgivningstjänster byggda för att ge den grunden. Om ni arbetar mot en verifierbar spårbarhetskedja för er programvaruleveranskedja hjälper vi er gärna.
