Den 21 april 2025 ersatte SLSA-communityn version 1.0 av sin leveranskedjestandard med version 1.1. Sedan dess har specifikationen flyttat vidare igen: enligt den officiella dokumentationen på slsa.dev är version 1.2 den aktuella utgåvan i oktober 2026. Det är en liten detalj för den som inte jobbar med CI/CD-säkerhet dagligen, men för team som bygger och publicerar paket, containerimages eller firmware är det skillnaden mellan att kunna bevisa var en binär kom ifrån och att bara hoppas att den gjorde det.
Den här guiden visar hur du i praktiken sätter upp byggprovenance med SLSA, in-toto och slsa-verifier, och hur du knyter ihop det med cosign och Sigstore för signering. Du bygger ett komplett demoprojekt i GitHub Actions, genererar en attestation, verifierar den med rätt kommandon och sätter en policy som stoppar artefakter som saknar giltig proveniens. Allt är skrivet för utvecklare och säkerhetsansvariga i Sverige och Norden som redan kör CI/CD men ännu inte har låst byggkedjan.
Du behöver inte redan jobba på ett stort plattformsteam för att få nytta av det här. Mönstret skalar ner till ett enmansprojekt och skalar upp till en organisation med hundratals repon, bara verktygen runt omkring ändras. Guiden går igenom tretton konkreta steg, ett fullständigt repo-exempel, fem vanliga fallgropar, åtta felsökningsscenarier och en lista med avancerade tips för den som vill nå SLSA Build L3 på sikt.
Varför byggprovenance är dagens viktigaste leveranskedjeförsvar
De senaste årens säkerhetsincidenter i öppen källkod har ett gemensamt drag: en konsument litade på en artefakt utan att kunna verifiera var den faktiskt byggdes. Ett paket på npm eller PyPI kan se identiskt ut vare sig det kom från den riktiga CI-pipelinen eller från en angripares bärbara dator. Utan provenance finns inget sätt att skilja de två åt efter att artefakten lämnat byggservern.
SLSA (Supply-chain Levels for Software Artifacts) löser inte sårbarheter i koden. Det är viktigt att vara tydlig med det. Vad SLSA ger är ett verifierbart svar på frågorna: vilket källkodsförråd byggde detta, vilken commit, vilken arbetsflödesfil och vilken byggtjänst. Om svaret inte stämmer mot din policy kan du blockera artefakten innan den når produktion. Det är en detekterande och förebyggande kontroll, inte en skanner som letar kända CVE:er.
Det som gör en leveranskedjeattack särskilt kostsam att upptäcka är att den sällan ser ut som en attack i loggarna. Byggjobbet kör klart, testerna passerar och artefakten publiceras precis som vanligt. Skillnaden syns först om någon faktiskt jämför vad som hände mot vad som borde ha hänt, och det är exakt den jämförelsen en provenance-attestation gör automatiskt varje gång en konsument verifierar den. Utan den jämförelsen är organisationen beroende av att en människa råkar märka att något kändes fel, vilket i praktiken sällan sker förrän skadan redan är spridd.
Praktiskt sett fungerar det så här. Din byggpipeline producerar inte bara en binär eller ett containerimage, utan även ett signerat in-toto-statement som beskriver hela byggprocessen. Den som konsumerar artefakten kör ett verifieringssteg innan den tillåts gå vidare i leveranskedjan. Om commit-hashen i attestationen inte matchar vad policyn förväntar sig, eller om byggtjänsten inte är den godkända, stoppas flödet. Ingen mänsklig granskning behövs i det vanliga fallet, vilket gör kontrollen skalbar över hundratals releaser i veckan.
Både npm och PyPI har redan byggt in stöd för den här typen av attestationer i sina publiceringsflöden, och GitHub Actions har ett eget ekosystem av verktyg för att generera SLSA-provenance direkt i arbetsflödet. Det gör att byggprovenance inte längre är ett forskningsprojekt för stora techbolag, utan något ett mindre team kan sätta upp på en eftermiddag. Resten av den här artikeln går igenom exakt hur.
Det är också värt att förstå var gränsen för skyddet går. En leveranskedjeattack sker sällan genom att angriparen bryter sig in i det färdiga paketet. Oftare kapas en enskild utvecklares inloggning, en CI-tjänst eller en beroende-uppdatering, och den komprometterade koden följer sedan med i en helt normal, till synes legitim byggprocess. Provenance gör det möjligt att upptäcka avvikelser i den processen, till exempel att en release plötsligt byggdes från en annan gren eller av en annan arbetsflödesfil än vanligt, men den ersätter inte kodgranskning, beroendeskanning eller åtkomstkontroll på kontonivå. De kompletterar varandra snarare än att en ersätter den andra.
SLSA, in-toto och Sigstore: vem gör vad
De tre namnen dyker ofta upp tillsammans och blandas ihop, men de löser olika delar av problemet. SLSA definierar vilka nivåer av garantier en byggprocess kan uppnå och vilka krav som gäller för varje nivå. in-toto definierar själva formatet för attestationer, det så kallade statement-formatet som beskriver vem som gjorde vad och när i en kedja av steg. Sigstore, med verktyget cosign, hanterar signering, lagring och verifiering av både artefakter och attestationer.
Ett enkelt sätt att komma ihåg skillnaden är att SLSA svarar på hur bra byggkedjan är, in-toto svarar på hur beviset är formaterat och Sigstore svarar på hur du vet att beviset inte är manipulerat. SLSA-provenance är i praktiken ett in-toto-statement, ofta inpackat i ett DSSE-kuvert (Dataset Signing Envelope) och signerat via Sigstore. De tre lagren staplas på varandra snarare än att konkurrera.
| Komponent | Huvuduppgift | Typiskt verktyg |
|---|---|---|
| SLSA | Definierar nivåer och krav för en spårbar byggprocess | slsa-github-generator, slsa-verifier |
| in-toto | Definierar attestationens dataformat (statement) | in-toto attestation-spec |
| DSSE | Signerat kuvertformat runt attestationen | Inbyggt i cosign och slsa-verifier |
| Sigstore / cosign | Signerar, publicerar och verifierar artefakt och attestation | cosign sign, cosign attest, cosign verify |
En viktig nyans är att en vanlig cosign-signatur bara bevisar att någon med en viss nyckel eller identitet signerade en digest. Den säger ingenting om hur artefakten byggdes. SLSA-provenance lägger till just den biten: byggkedjan, källrevisionen och parametrarna. Du vill normalt ha båda delarna, en signatur som styrker avsändaren och en provenance som styrker byggprocessen.
Ett konkret exempel gör det lättare att hålla isär lagren. Säg att ditt team bygger ett containerimage. GitHub Actions kör byggsteget och producerar en digest. slsa-github-generator skapar sedan ett in-toto-statement som beskriver exakt vilken commit, vilken arbetsflödesfil och vilken runner som gjorde bygget. cosign signerar både imagets digest och det statementet, och lagrar allt i registret bredvid imaget. Den som sedan vill dra ner imaget kör cosign verify för signaturen och slsa-verifier eller cosign verify-attestation för själva provenance-innehållet, i två separata men kompletterande steg.
Ingen av delarna är användbar helt isolerad. En signatur utan provenance berättar bara vem som skickade filen, inte hur den uppstod. Provenance utan signatur går att redigera av vem som helst innan den läses, eftersom inget binder innehållet till en verifierbar identitet. Det är just kombinationen av de tre lagren, inte en enskild del, som ger den typ av end-to-end-spårbarhet många team egentligen letar efter när de säger att de vill “signera sina byggen”.
SLSA-nivåerna 1 till 3 förklarade
SLSA beskriver tre byggnivåer som varje blir strängare än den förra. Nivåerna är kumulativa, så nivå 3 uppfyller automatiskt kraven för nivå 1 och 2. Tanken är att du höjer nivån stegvis i takt med att teamet mognar, inte att du hoppar direkt till toppen.
Nivåerna fungerar också som ett gemensamt språk mellan organisationer som annars inte har insyn i varandras byggpipeliner. En leverantör kan säga att deras artefakter uppfyller Build L2 utan att behöva avslöja hela sin interna infrastruktur, och kunden kan sätta det som ett krav i sin inköpsprocess utan att själv behöva granska leverantörens källkod. Det är den egenskapen, mer än någon enskild teknisk detalj, som gör nivåerna användbara i avtal och upphandlingar, inte bara i en enskild utvecklares terminal.
| Nivå | Huvudkrav | Praktisk betydelse |
|---|---|---|
| Build L1 | Provenance genereras och görs tillgänglig | Du kan se hur artefakten byggdes, men inte lita blint på uppgifterna |
| Build L2 | Provenance genereras av en identifierbar, delad byggtjänst | Provenance är svårare att förfalska än manuellt ihopskriven metadata |
| Build L3 | Härdad byggplattform med starkare isolering mot manipulation | Byggmiljön separeras bättre från källkod och arbetsflödeskontroll |
SLSA v1.1 förtydligade hotmodellen, attestationsmodellen och verifieringsproceduren jämfört med v1.0, och lade till metadata för hur en verifierare ska uttrycka sina resultat genom en Verification Summary Attestation (VSA). Det är ett steg mot att inte bara producenten utan även en oberoende verifierare kan intyga att en artefakt klarar en given nivå, utan att själv behöva gå igenom hela byggloggen manuellt.
För de flesta team i Norden räcker det gott att sikta på Build L2 till att börja med. Det kräver en delad CI-tjänst som GitHub Actions snarare än en lokal utvecklardator, och det är precis det upplägget som resten av guiden bygger mot. Build L3 kräver härdade, isolerade byggrunners som normalt bara stora plattformsteam eller molnleverantörer erbjuder i dagsläget.
Språnget från L1 till L2 är i praktiken ett infrastrukturbeslut snarare än ett verktygsbeslut. Så länge bygget körs på en delad GitHub Actions-runner istället för en utvecklares egen maskin, och provenance genereras automatiskt av den delade tjänsten, uppfyller du redan huvuddelen av kraven. Språnget från L2 till L3 är betydligt större, eftersom det kräver att själva byggmiljön är isolerad så att ett kompromitterat jobb inte kan påverka nästa körning eller läsa hemligheter den inte ska ha tillgång till. Många organisationer väljer medvetet att stanna på L2 under lång tid, eftersom kostnaden för L3 bara motiveras när artefakterna är kritiska nog att vara ett högvärdigt mål.
Förutsättningar: verktyg och versioner du behöver
Innan du börjar bygga, se till att du har följande på plats. Versionerna nedan är vad som var aktuellt och verifierat när den här artikeln skrevs, men kontrollera alltid respektive projekts egen releasesida innan du låser en version i produktion.
- Ett GitHub-konto med Actions aktiverat, samt ett publikt eller privat repo för demoprojektet.
- Git 2.40 eller senare installerat lokalt.
- Node.js 20 LTS eller senare, för demoprojektet och för att testa npm publish med provenance.
- slsa-verifier version 2.7.0, den senaste stabila releasen enligt projektets GitHub-repo. En release candidate, v2.7.1-rc.1, fanns också men bör undvikas i produktion.
- cosign, senaste stabila version i 2.x-serien, installerad via Homebrew, Go install eller en binär från Sigstore-projektet.
- Go 1.22 eller senare, om du vill bygga slsa-verifier från källkod istället för att hämta en färdig binär.
- Grundläggande kännedom om YAML och GitHub Actions-syntax.
Ett observandum redan här: projektet slsa-framework/slsa-github-generator, som historiskt varit standardverktyget för att generera SLSA-provenance i GitHub Actions, anges numera inte längre vara aktivt underhållet enligt sin egen release-information. Den senaste identifierade stabila releasen är v2.1.0 från februari 2025. Det betyder inte att verktyget har slutat fungera, men du bör pinna det till en exakt version eller commit-hash och hålla ett öga på projektets egna migreringsrekommendationer innan du bygger något långsiktigt ovanpå det.
Tabellen nedan samlar versionsläget för de centrala verktygen i guiden på ett ställe, så att du inte behöver bläddra tillbaka under själva genomförandet.
| Verktyg | Version i denna guide | Status |
|---|---|---|
| SLSA-specifikation | v1.2 (aktuell), v1.1 godkänd 21 april 2025 | Aktivt underhållen |
| slsa-github-generator | v2.1.0 (februari 2025) | Inte längre aktivt underhållen, pinna exakt version |
| slsa-verifier | v2.7.0 (stabil), v2.7.1-rc.1 (release candidate) | Aktivt underhållen |
| cosign / Sigstore | Senaste stabila 2.x-release | Aktivt underhållen |
| npm | Senaste version med stöd för –provenance | Aktivt underhållen |
Steg 1 till 3: sätt upp demoprojektet och GitHub-repot
Vi bygger ett minimalt Node.js-paket som exempel. Samma mönster går att återanvända för containerimages, Go-binärer eller Python-paket, bara generator- och verifieringsstegen byts ut.
Ordningen på de första stegen spelar roll. Projektet måste finnas i ett riktigt GitHub-repo innan generatorn kan koppla provenance till en specifik commit och arbetsflödesfil. Hoppar du över det och testar lokalt först riskerar du att bygga vanor som inte går att återskapa i CI, till exempel sökvägar eller miljövariabler som bara finns på din egen maskin.
Steg 1: Skapa projektstrukturen.
mkdir slsa-demo-paket && cd slsa-demo-paket
npm init -y
mkdir -p src .github/workflows
echo "module.exports = () => 'hej fran en verifierad byggkedja';" > src/index.jsSteg 2: Initiera Git och koppla till GitHub.
git init
git add .
git commit -m "Initiera demoprojekt for SLSA-provenance"
git branch -M main
git remote add origin https://github.com/DITT-ANVANDARNAMN/slsa-demo-paket.git
git push -u origin mainSteg 3: Lägg till ett byggskript i package.json. Lägg till ett enkelt byggsteg som faktiskt producerar en artefakt att attestera, till exempel en tar-fil med källkoden. I ett verkligt projekt motsvarar det här er riktiga byggprocess, kompilering, bundling eller containerimage-byggnation.
{
"scripts": {
"build": "tar -czf dist/slsa-demo-paket.tar.gz src package.json"
}
}Steg 4 till 6: bygg arbetsflödet och generera provenance
Steg 4: Skriv GitHub Actions-workflowet. Workflowet nedan bygger artefakten och beräknar dess SHA-256-digest, som sedan matas in i generatorn för SLSA-provenance. Pinna alltid generatorn till en exakt tagg eller commit-hash, aldrig en rörlig major-tagg, av precis det skäl som nämndes i föregående avsnitt.
name: build-and-attest
on:
push:
tags: ["v*"]
jobs:
build:
runs-on: ubuntu-latest
outputs:
digest: ${{ steps.hash.outputs.digest }}
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run build
- id: hash
run: |
echo "digest=$(sha256sum dist/slsa-demo-paket.tar.gz | cut -d ' ' -f1)" >> "$GITHUB_OUTPUT"
- uses: actions/upload-artifact@v4
with:
name: slsa-demo-paket
path: dist/slsa-demo-paket.tar.gz
provenance:
needs: [build]
permissions:
actions: read
id-token: write
contents: write
uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
with:
base64-subjects: "${{ needs.build.outputs.digest }}"Lägg märke till att de två jobben är separerade med ett needs-beroende. Byggjobbet känner inte till provenance-generatorn alls, det bara producerar en artefakt och en digest. Det är generatorns eget, återanvändbara workflow som tar emot digesten och sköter signeringen, vilket är precis den typ av tydlig uppdelning SLSA förespråkar: byggsteget ska inte själv kunna påverka hur det attesteras.
Steg 5: Kör workflowet och ladda ner artefakterna. Tagga en release för att trigga flödet, och vänta tills både byggjobbet och provenance-jobbet är klara. Första gången tar det ofta några minuter extra eftersom GitHub behöver hämta och cacha det återanvändbara generator-workflowet, men efterföljande körningar brukar gå snabbare.
git tag v0.1.0
git push origin v0.1.0
gh run watchSteg 6: Hämta provenance-filen. Generatorn bifogar en fil med ändelsen .intoto.jsonl som artefakt på körningen. Ladda ner både den byggda tar-filen och attestationsfilen till samma mapp lokalt innan nästa steg.
gh run download --name slsa-demo-paket
gh run download --name slsa-demo-paket.intoto.jsonlSteg 7 till 9: installera och köra slsa-verifier
Steg 7: Installera slsa-verifier v2.7.0.
go install github.com/slsa-framework/slsa-verifier/v2/cli/[email protected]
slsa-verifier versionSteg 8: Kontrollera CLI-hjälpen innan du låser kommandot. Det nyare verifieringsprojektet stödjer fler attestationstyper än den äldre GitHub-specifika varianten, bland annat build-provenance, source-provenance och Verification Summary Attestations, och det tolkar in-toto-statements, DSSE-kuvert och Sigstore-buntar direkt. Kör alltid hjälpen för din installerade version innan du skriver en produktionspipeline mot den.
slsa-verifier verify-artifact --help
slsa-verifier verify-image --helpSteg 9: Verifiera artefakten mot provenance.
slsa-verifier verify-artifact \
--provenance-path slsa-demo-paket.tar.gz.intoto.jsonl \
--source-uri github.com/DITT-ANVANDARNAMN/slsa-demo-paket \
--source-tag v0.1.0 \
dist/slsa-demo-paket.tar.gzOm allt stämmer svarar verktyget med en bekräftelse om att artefaktens digest matchar den som angavs i attestationen, att källförrådet och taggen överensstämmer och att signaturen över DSSE-kuvertet är giltig. Byter du en enda byte i den byggda filen, eller om digesten i provenance-filen pekar på fel commit, avvisas verifieringen direkt med ett felmeddelande som pekar ut exakt vilket fält som inte stämde.
Det är lätt att underskatta hur mycket detta skiljer sig från att “lita på HTTPS” när man laddar ner ett paket. En giltig TLS-anslutning bevisar bara att trafiken inte avlyssnades på vägen, inte att innehållet i sig kom från rätt source. Digest-matchningen i slsa-verifier är bitvis exakt, vilket gör den betydligt svårare att kringgå av misstag eller med en halvfärdig attack.
Spara gärna utskriften från verifieringskommandot som en artefakt i samma CI-körning, inte bara i terminalens scrollback. Om något senare ifrågasätts, till exempel vid en incidentutredning eller en revision, är det mycket enklare att peka på en loggad, tidsstämplad verifiering än att försöka återskapa vad som faktiskt hände flera veckor i efterhand.
Steg 10 och 11: signera och verifiera med cosign
Steg 10: Signera artefakten och bifoga attestationen med cosign. Om din artefakt är ett containerimage snarare än en tar-fil kan du använda cosign för att både signera avtrycket och bifoga SLSA-provenance som en separat attestation i registret. Kontrollera alltid flaggorna mot din egen cosign-version med cosign attest --help, eftersom exakt syntax kan skilja mellan utgåvor.
cosign sign ghcr.io/DITT-ANVANDARNAMN/slsa-demo-image@sha256:DIGEST
cosign attest \
--predicate slsa-demo-paket.tar.gz.intoto.jsonl \
--type slsaprovenance \
ghcr.io/DITT-ANVANDARNAMN/slsa-demo-image@sha256:DIGESTSteg 11: Verifiera signatur och attestation.
cosign verify \
--certificate-identity-regexp "^https://github.com/DITT-ANVANDARNAMN" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/DITT-ANVANDARNAMN/slsa-demo-image@sha256:DIGEST
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity-regexp "^https://github.com/DITT-ANVANDARNAMN" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/DITT-ANVANDARNAMN/slsa-demo-image@sha256:DIGESTLägg märke till att verifieringen inte bara kollar en nyckel, utan en identitet kopplad till GitHubs OIDC-utfärdare. Det är kärnan i Sigstores keyless-signering: istället för att förvalta en långlivad privat nyckel binds signaturen till GitHub Actions-identiteten för den exakta workflow-körningen som skapade den.
Det ger även ett revisionsspår som fungerar bra för svenska organisationer som behöver dokumentera sin leveranskedja för en intern eller extern granskning. Varje signatur loggas i Sigstores publika transparenslogg, vilket betyder att ingen, inte heller en insider med tillgång till byggservern, kan signera om en artefakt i efterhand utan att det syns i loggen. Nyckelhanteringen som annars brukar vara den svagaste länken i certifikatbaserad signering försvinner nästan helt.
Steg 12 och 13: npm-provenance och en blockerande policy
Steg 12: Publicera paketet med inbyggd npm-provenance. Om din artefakt är ett npm-paket behöver du inte alltid den fristående SLSA-generatorn. npm har eget stöd för att bifoga provenance vid publicering, under förutsättning att publiceringen sker från ett stött CI-flöde som GitHub Actions med trusted publishing konfigurerat.
Trusted publishing kopplar npm-registret direkt till din GitHub Actions-identitet via OIDC, på samma sätt som cosign gör för containerimages. Det eliminerar behovet av en långlivad npm-token lagrad som hemlighet i repot, vilket i sig tar bort en vanlig attackyta: en läckt publiceringstoken som annars skulle kunna användas för att skicka en falsk release direkt till registret utan att gå via din riktiga pipeline.
npm publish --provenance --access publicSteg 13: Skriv en policy som blockerar artefakter utan giltig provenance. Det sista och viktigaste steget är att faktiskt göra verifieringen obligatorisk, inte frivillig. Lägg till ett steg i din distributions- eller deploy-pipeline som avbryter flödet om slsa-verifier returnerar en felkod.
#!/usr/bin/env bash
set -euo pipefail
if ! slsa-verifier verify-artifact \
--provenance-path "$PROVENANCE_FIL" \
--source-uri "github.com/DITT-ANVANDARNAMN/slsa-demo-paket" \
--source-tag "$RELEASE_TAGG" \
"$ARTEFAKT"; then
echo "BLOCKERAR DEPLOY: artefakten saknar giltig SLSA-provenance"
exit 1
fi
echo "Provenance godkand, fortsatter mot produktion"Testa gärna policyn negativt också, det vill säga byt ut en byte i artefakten eller peka på fel tagg och bekräfta att skriptet faktiskt stoppar flödet. Ett verifieringssteg som ingen sett misslyckas är ett verifieringssteg ingen litar på.
Det negativa testet är ofta det steg team hoppar över av tidsbrist, men det är samtidigt det enda sättet att vara säker på att policyn faktiskt gör vad den ska. En skrivfelsbugg i jämförelselogiken kan göra att skriptet alltid returnerar godkänt oavsett innehåll, och det syns bara om du aktivt försöker få det att misslyckas minst en gång innan du litar på det i produktion.
Fullständigt arbetsexempel: repo-struktur och filer
När alla tretton stegen är genomförda ser ditt demoprojekt ut ungefär som nedan. Det här är den minimala strukturen du kan klona och bygga vidare på för ett riktigt projekt.
slsa-demo-paket/
├── .github/
│ └── workflows/
│ └── build-and-attest.yml
├── scripts/
│ └── verify-provenance.sh
├── src/
│ └── index.js
├── dist/
│ └── slsa-demo-paket.tar.gz
├── package.json
└── README.mdREADME-filen bör dokumentera exakt vilken kommandorad en konsument ska köra för att verifiera paketet, inklusive source-uri och vilken slsa-verifier-version som testats. Det är lätt att glömma, men det är precis den dokumentationen som gör skillnaden mellan att provenance faktiskt används och att den bara ligger och samlar damm i en artefaktlagring ingen tittar i.
Varje fil i strukturen har en tydlig roll. Workflowfilen under .github/workflows/ äger hela bygg- och attesteringsprocessen och är den fil en granskare först bör läsa. Skriptet verify-provenance.sh under scripts/ är det som faktiskt kör i deploy-pipelinen och blockerar vid fel, så det bör versionshanteras precis som produktionskod, inte lämnas som ett engångsskript någon körde manuellt en gång. Mappen dist/ innehåller den byggda artefakten och ska normalt inte checkas in i Git, bara publiceras som ett körningsresultat i CI. Håller du de rollerna isär blir det mycket enklare att felsöka när något går fel längre fram.
Fem vanliga fallgropar när du inför SLSA
De flesta misstag i en tidig SLSA-implementation handlar inte om krånglig kryptografi, utan om små, mänskliga genvägar som gör hela kontrollen meningslös utan att det syns direkt. Här är de fem vi stöter på oftast när team sätter upp byggprovenance för första gången.
- Att pinna generatorn till en rörlig tagg. Eftersom slsa-github-generator inte längre underhålls aktivt är det extra viktigt att låsa till en exakt version, som v2.1.0, snarare än en major-referens som kan ändra beteende utan förvarning.
- Att generera provenance men aldrig verifiera den. Det är den vanligaste fallgropen av alla. En attestation som ingen läser ger inget säkerhetsvärde, bara en falsk känsla av ordning.
- Att blanda ihop signatur och provenance. En cosign-signatur bevisar vem som signerade, inte hur artefakten byggdes. Många team tror att de har byggkedjespårbarhet när de egentligen bara har en signerad artefakt.
- Att lita på provenance från en builder du inte kontrollerar. Om byggtjänsten själv är komprometterad kan den fortfarande producera en teknisk korrekt, giltigt signerad provenance som pekar på fel verklighet. Provenance beskriver vad byggsystemet säger hände, inte en oberoende sanning.
- Att glömma source-tag eller source-uri i verifieringskommandot. Utan dessa flaggor verifierar slsa-verifier bara att attestationen är korrekt signerad, inte att den faktiskt hör ihop med det källförråd och den release du förväntar dig.
- Att behandla SLSA som en ersättning för sårbarhetsskanning. Ett paket kan ha perfekt, korrekt verifierad provenance och samtidigt innehålla ett beroende med en känd kritisk sårbarhet. Provenance och beroendeskanning löser olika problem och bör köras som separata, parallella steg i pipelinen snarare än att ena ersätta den andra.
- Att bara verifiera i ett undantagsfall, inte som standard. Vissa team lägger till verifieringssteget men gör det frivilligt, eller kör det bara när någon minns att trycka på en extra knapp. En kontroll som kräver att en människa aktivt väljer att köra den varje gång kommer förr eller senare att missas, oftast precis när det spelar mest roll.
Felsökning: åtta vanliga fel och lösningar
Felmeddelandena från slsa-verifier och cosign är ovanligt precisa jämfört med många säkerhetsverktyg, men det hjälper inte om man inte vet var man ska börja leta. Nedan är åtta fel vi stött på i praktiken, i ungefär den ordning de brukar dyka upp första gången ett team sätter upp flödet.
- “verification failed: artifact digest mismatch”. Artefakten du verifierar är inte bitvis identisk med den som byggdes. Bygg om och ladda ner artefakten på nytt, och undvik att packa om eller komprimera filen efter nedladdning.
- “no provenance found for subject”. Attestationsfilen matchar inte digesten för den artefakt du pekar på. Kontrollera att du använder rätt
.intoto.jsonl-fil för exakt den tar-fil eller det image-lager du testar. - “source-uri mismatch”. Du angav fel repo-sökväg. Formatet ska vara exakt
github.com/ANVANDARE/REPOutan protokollprefix och utan avslutande snedstreck. - GitHub Actions-jobbet för provenance misslyckas med behörighetsfel. Kontrollera att workflowet har
id-token: writeochcontents: writesatt under permissions, annars kan generatorn inte begära ett OIDC-token för signeringen. - cosign verify misslyckas trots korrekt signatur. Kontrollera att
--certificate-identity-regexpoch--certificate-oidc-issuermatchar exakt den workflow-sökväg och utfärdare som faktiskt signerade. Ett för strikt eller felskrivet reguljärt uttryck är den vanligaste orsaken. - npm publish –provenance ger felet “provenance generation is not supported”. Det inträffar oftast när publiceringen körs lokalt istället för i ett stött CI-flöde. Flytta publiceringssteget till GitHub Actions med trusted publishing konfigurerat.
- slsa-verifier hittas inte efter go install. Kontrollera att din
$GOPATH/bineller$HOME/go/binfinns med i$PATH. Det är den vanligaste orsaken till felet “command not found” direkt efter installation. - Policyskriptet blockerar allt, även giltiga releaser. Oftast beror det på att
$RELEASE_TAGGi skriptet inte matchar exakt den Git-tagg som triggade bygget. Skriv ut variabelns värde i ett debug-steg innan du kör verifieringen, så ser du snabbt om taggformatet skiljer sig.
Avancerade tips för SLSA nivå 3 och större organisationer
När grunderna sitter är nästa naturliga steg att röra sig mot Build L3, vilket kräver en härdad byggplattform med starkare isolering mellan byggjobb, källkod och arbetsflödeskontroll. I praktiken betyder det att undvika delade, långlivade byggrunners där ett jobb kan påverka miljön för nästa, och istället köra varje bygge i en engångsisolerad container eller virtuell maskin som rivs efter körning.
För organisationer med fler än ett tiotal repon lönar det sig att bygga en delad, återanvändbar workflow för provenance-generering istället för att kopiera YAML mellan projekt. Det minskar risken att ett enskilt team glömmer att pinna en version eller sätter fel behörigheter, och gör det möjligt att höja säkerhetsnivån centralt för alla repon samtidigt genom att bara ändra en fil.
Verification Summary Attestations, som introducerades som en del av SLSA v1.1, gör det möjligt för en central säkerhetsfunktion att själv intyga att en artefakt klarat en viss nivå, utan att varje nedströmsteam behöver göra om hela verifieringskedjan själva. Det är särskilt användbart i större organisationer där ett plattformsteam vill kunna säga att allt som passerar gatewayen redan är verifierat till L2, och låta övriga team lita på det intyget istället för att köra slsa-verifier manuellt varje gång.
Provenance-verifiering bör aldrig vara det enda skyddet. Kombinera den med beroendeskanning, hemlighetsskanning i kodbasen och signering av containerimages som separata kontroller. SLSA stärker tilliten till byggkedjan, men ersätter inte behovet av att faktiskt granska vad koden gör.
Ett sista avancerat tips rör loggning och spårbarhet över tid. Skicka resultatet av varje verifieringskörning, både godkända och nekade, till samma plats där ni redan samlar annan säkerhetslogg, till exempel ett SIEM-system eller en central logghanterare. En plötslig ökning i antal nekade verifieringar kan vara ett tidigt tecken på att något i byggkedjan har börjat bete sig avvikande, långt innan det märks på något annat sätt. Det kostar nästan ingenting att lägga till, men ger ett larm du annars helt skulle sakna.
SLSA i relation till NIS2 och Cyber Resilience Act
Både EU:s NIS2-direktiv och Cyber Resilience Act ställer krav på riskhantering i leverantörskedjan och på säker utvecklingsprocess för produkter med digitala element, men ingen av regelverken namnger SLSA eller någon annan specifik attestationsstandard som obligatorisk. Det är en skillnad värd att hålla isär: lagstiftningen kräver att du kan visa kontroll över din byggkedja, inte att du använder ett bestämt verktyg för att göra det.
Det gör SLSA-provenance till ett praktiskt sätt att möta kraven snarare än ett lagkrav i sig. När en revisor eller tillsynsmyndighet frågar hur ni vet att en release faktiskt kom från er egen byggprocess, är ett verifierbart in-toto-statement med tillhörande cosign-signatur ett betydligt starkare svar än en commit-logg och ett löfte. För svenska och nordiska bolag som redan omfattas av NIS2 är det värt att börja med den typen av teknisk dokumentation nu, innan revisionen kräver det.
I praktiken brukar det löna sig att göra tre saker i den ordningen: först kartlägga vilka artefakter som faktiskt når produktion och kunder, sedan sätta Build L2-provenance på de mest kritiska av dem, och till sist utöka verifieringen till att bli en obligatorisk, blockerande kontroll snarare än ett valfritt steg någon kan hoppa över under tidspress. Att göra allt tre på en gång för hela artefaktflottan samtidigt brukar skapa mer motstånd i organisationen än det löser, medan en stegvis utrullning ger teamet tid att lära sig verktygen innan de blir en hård spärr.
Säkerhetsteamet behöver sällan äga hela genomförandet själva. De flesta utvecklingsteam kan sätta upp sin egen workflow-fil utifrån ett delat exempel, medan säkerhetsfunktionen håller i policyn, granskar undantag och äger den centrala återanvändbara workflowfilen som beskrevs i avsnittet om avancerade tips. Den uppdelningen gör att införandet skalar utan att skapa en flaskhals hos ett enda litet team som annars skulle behöva granska varenda repo manuellt.
Vanliga frågor
Måste jag använda GitHub Actions för att bygga SLSA-provenance?
Nej, men det är i dagsläget den plattform med mest moget tillgängligt stöd. Andra CI-plattformar som Tekton har egna integrationer för provenance, men verktygen och dokumentationen är inte lika utbredda som för GitHub Actions. Kör du GitLab CI eller en annan plattform kan du fortfarande generera in-toto-statements manuellt och signera dem med cosign, det kräver bara mer eget arbete kring hur statementet byggs ihop.
Räcker SLSA Build L1 för ett litet open source-projekt?
Som startpunkt, ja. L1 ger dig i alla fall en dokumenterad byggprocess att utgå från. Men eftersom provenance på L1 kan skapas manuellt är tilliten begränsad, och de flesta konsumenter bör inte lita blint på en L1-attestation för kritisk infrastruktur.
Vad händer om slsa-github-generator slutar fungera helt?
Eftersom projektet redan anges som inte aktivt underhållet bör du följa projektets egna kanaler för migreringsvägledning och vara beredd att byta till ett nyare verktyg eller en egen implementation baserad på in-toto-biblioteken direkt.
Kan jag använda SLSA-provenance för containerimages istället för npm-paket?
Ja. Mönstret är detsamma, men du bifogar attestationen till imagets digest i registret via cosign istället för att ladda upp en separat .intoto.jsonl-fil, och verifierar sedan med slsa-verifier verify-image istället för verify-artifact.
Är en SLSA-badge på GitHub ett bevis på säkerhet?
Nej. En badge visar bara att provenance genereras för projektet, inte att alla nedströmskonsumenter faktiskt verifierar den eller att resten av beroendekedjan är säker. Se den som en indikation att projektet tagit ett första steg, inte ett certifikat på att allt nedströms är kontrollerat.
Måste jag betala för Sigstore eller cosign?
Nej, Sigstore-ekosystemet, inklusive cosign och den publika transparensloggen, är öppen källkod och gratis att använda för både öppna och privata projekt.
Vad är skillnaden mellan slsa-verifier och det bredare verifieringsprojektet som nu kallas verifier?
Det nyare projektet stödjer fler attestationstyper, bland annat source-provenance och Verification Summary Attestations, och tolkar fler format som DSSE-kuvert och Sigstore-buntar direkt. Kontrollera alltid vilket projekt din pipeline faktiskt pekar mot innan du antar att syntaxen är identisk mellan dem.
Kan en angripare som kompromitterar min byggserver fortfarande producera giltig provenance?
Ja, det är en viktig begränsning att känna till. Om byggtjänsten själv är komprometterad på ett sätt som inte syns utåt kan den fortsätta signera och publicera en teknisk giltig attestation som beskriver en verklighet som redan är manipulerad. SLSA skyddar mot förfalskad eller okontrollerad proveniens, inte mot en fullständigt infiltrerad byggkedja. Det är just det scenariot som Build L3:s isolerade byggmiljöer försöker göra svårare, genom att minska vad en angripare kan påverka i varje enskild byggkörning.
