Vad är SLSA?

Vilket problem löser SLSA?

Du kan granska varje rad källkod och ändå leverera något annat, eftersom det användarna kör är resultatet av ett bygge. Om bygget komprometteras, som hos SolarWinds, ger ren källkod en förgiftad release. SLSA riktar in sig på den luckan: kan någon verifiera att den här artefakten kom från den här källan, genom den här processen?

SLSA-nivåer

SLSA delar in sina krav i spår. Den aktuella versionen, 1.2, har ett Build-spår och ett Source-spår. Build-spåret har fyra nivåer.

Nivå	Namn	Vad den kräver	Vad den ger dig
Build L0	Inga garantier	Ingenting	L0 är frånvaron av SLSA
Build L1	Proveniens finns	En enhetlig byggprocess och proveniens som genereras av byggplattformen och lämnas till användarna	Hjälper till att förhindra misstag, men är trivialt att kringgå eller förfalska
Build L2	Hostad byggplattform	Byggen körs på en hostad plattform som genererar och signerar proveniensen, och användarna verifierar den	Att förfalska proveniens kräver nu en avsiktlig attack
Build L3	Härdade byggen	Körningar är isolerade från varandra, och signeringshemligheten är utom räckhåll för användardefinierade byggsteg	Att förfalska proveniens kräver att en sårbarhet utnyttjas, vilket ligger utom räckhåll för de flesta angripare

Nivåerna är inte ett betyg som du måste maximera. Var och en skyddar mot specifika hot, så välj den nivå som passar din risk. Open source-underhållare med en hostad CI-tjänst kan ofta nå L2 utan större arbete.

Vad är proveniens?

Proveniens är en registrering av hur en artefakt skapades. I SLSA anger den vilken plattform som byggde den, från vilken källa, genom vilken process och med vilka indata på toppnivå. Proveniens på L2 och högre är signerad, så en användare kan kontrollera att den kom från byggplattformen och inte har ändrats.

Tänk på en SBOM som ingredienserna och proveniens som var och hur rätten lagades. De besvarar olika frågor och fungerar bra tillsammans: en SBOM listar vad som finns inuti, medan proveniens säger var artefakten kom ifrån.

Så inför du SLSA

1. Bygg i CI, på samma sätt varje gång. Sluta släppa releaser från laptops. Det är det mesta av arbetet för att nå L1.
2. Generera proveniens. På GitHub ger artifact attestations signerad proveniens. Se hur attesteringar fungerar med SBOM:er i GitHub Actions.
3. Verifiera den där det spelar roll. Signerad proveniens som ingen kontrollerar skyddar ingen. Lägg till verifiering i ditt driftsättningssteg eller din admission controller.
4. Härda bygget. Isolera körningar och håll signeringsnycklar borta från byggsteg. Se runner-säkerhet i jämförelse.
5. Fråga dina beroenden. Föredra paket som publicerar proveniens, vilket register som npm nu har stöd för.

Vad SLSA inte täcker

• Sårbarheter. En perfekt byggd artefakt kan innehålla en brist. SLSA säger ingenting om huruvida koden är säker.
• Skadlig källkod. Om en angripare gör en commit till repot registrerar proveniensen troget ett bygge av den koden. Source-spåret tar upp en del av detta.
• Vad bygget drog in. Proveniens listar indata på toppnivå. Inget i Build-spåret kräver en fullständig lista över beroenden, vilket är vad en SBOM är till för.
• Betrodda insiders. Bakdörren i xz kom in genom en betrodd underhållare, och SLSA ensamt skulle inte ha stoppat den.

SLSA och andra ramverk

SLSA går på djupet med byggintegritet. NIST SSDF är mycket bredare: det täcker säker utveckling som helhet, inklusive ett arbetssätt för att skydda och arkivera releaser som SLSA-proveniens stöder. SLSA är ett projekt inom OpenSSF, och många team använder de två tillsammans. För den större bilden, se vad är säkerhet i mjukvarans leveranskedja.

Var CRACI passar in

CRACI tar inte fram signerad proveniens och gör inga anspråk på någon SLSA-nivå, så använd GitHub artifact attestations eller en liknande tjänst om du behöver det. Det CRACI tillför är det som SLSA lämnar utanför: en fullständig registrering av vad varje GitHub Actions-jobb drog in. Varje jobb körs i en egen isolerad virtuell maskin, varje paket det hämtar hamnar i en SBOM, och en egress-policy blockerar anslutningar som bygget inte behöver. Se SBOM-generering under bygget.

SLSA: vanliga frågor

Vad står SLSA för?

Supply-chain Levels for Software Artifacts. Det uttalas "salsa".

Vilka är SLSA-nivåerna?

Build-spåret har fyra: L0, inga garantier; L1, proveniens finns; L2, en hostad byggplattform som signerar proveniensen; och L3, härdade byggen med isolerade körningar och skyddade signeringshemligheter. Version 1.2 lägger också till ett Source-spår.

Vad är SLSA-proveniens?

En registrering av hur en artefakt byggdes: vilken plattform, från vilken källa, genom vilken process och med vilka indata på toppnivå. På Build L2 och högre är den signerad, så att användare kan verifiera den.

Vad är skillnaden mellan SLSA och en SBOM?

En SBOM listar vad som finns i en programvara. SLSA-proveniens beskriver hur och var den byggdes. Oftast vill du ha båda.

Är SLSA obligatoriskt?

Nej. Det är ett frivilligt ramverk från OpenSSF-communityn. Vissa kunder och organisationer kan fråga efter en nivå, men det är ingen lag.

Vilken SLSA-nivå bör jag sikta på?

Börja med Build L1 genom att bygga i CI och generera proveniens, och gå sedan vidare till L2 på en hostad plattform, vilket många team kan nå snabbt. L3 passar releaser som många andra är beroende av eller som innebär hög risk.