Hva er SLSA?

Hvilket problem løser SLSA?

Du kan gå gjennom hver eneste linje med kildekode og likevel levere noe annet, for det brukerne kjører, er resultatet av et bygg. Hvis bygget er kompromittert, slik det var hos SolarWinds, gir ren kildekode en forgiftet utgivelse. SLSA retter seg mot det hullet: Kan noen verifisere at denne artefakten kom fra denne kilden, gjennom denne prosessen?

SLSA-nivåer

SLSA ordner kravene sine i spor. Den gjeldende versjonen, 1.2, har et Build-spor og et Source-spor. Build-sporet har fire nivåer.

Nivå	Navn	Hva det krever	Hva det gir deg
Build L0	Ingen garantier	Ingenting	L0 er fravær av SLSA
Build L1	Provenance finnes	En konsekvent byggeprosess, og provenance som genereres av byggeplattformen og gis til brukerne	Bidrar til å forhindre feil, men er enkelt å omgå eller forfalske
Build L2	Hostet byggeplattform	Bygg kjører på en hostet plattform som genererer og signerer provenance, og brukerne verifiserer den	Å forfalske provenance krever nå et bevisst angrep
Build L3	Herdede bygg	Kjøringer er isolert fra hverandre, og signeringshemmeligheten er utenfor rekkevidde for brukerdefinerte byggesteg	Å forfalske provenance krever at en sårbarhet utnyttes, noe som er utenfor de flestes rekkevidde

Nivåene er ikke en karakter du må maksimere. Hvert av dem beskytter mot bestemte trusler, så velg nivået som passer risikoen din. Vedlikeholdere av åpen kildekode med en hostet CI-tjeneste kan ofte nå L2 uten mye arbeid.

Hva er provenance?

Provenance er dokumentasjon på hvordan en artefakt ble laget. I SLSA sier den hvilken plattform som bygget den, fra hvilken kilde, med hvilken prosess og med hvilke inndata på toppnivå. Provenance på L2 og høyere er signert, så en bruker kan sjekke at den kom fra byggeplattformen og ikke er endret.

Tenk på en SBOM som ingrediensene, og på provenance som hvor og hvordan retten ble laget. De svarer på ulike spørsmål og fungerer godt sammen: En SBOM viser hva som er inni, mens provenance sier hvor artefakten kom fra.

Slik tar du i bruk SLSA

1. Bygg i CI, på samme måte hver gang. Slutt å gi ut fra bærbare maskiner. Det er det meste av arbeidet med å nå L1.
2. Generer provenance. På GitHub produserer artifact attestations signert provenance. Se hvordan attestations fungerer med SBOM-er i GitHub Actions.
3. Verifiser den et sted der det betyr noe. Signert provenance som ingen sjekker, beskytter ingen. Legg til verifisering i utrullingssteget eller admission controlleren din.
4. Herd bygget. Isoler kjøringer og hold signeringsnøkler unna byggesteg. Se runnersikkerhet sammenlignet.
5. Spør avhengighetene dine. Foretrekk pakker som publiserer provenance, noe registre som npm nå støtter.

Hva SLSA ikke dekker

• Sårbarheter. En perfekt bygget artefakt kan inneholde en feil. SLSA sier ingenting om hvorvidt koden er trygg.
• Ondsinnet kildekode. Hvis en angriper committer til repositoriet, registrerer provenance trofast et bygg av den koden. Source-sporet tar for seg en del av dette.
• Hva bygget trakk inn. Provenance viser inndata på toppnivå. Ingenting i Build-sporet krever en fullstendig liste over avhengigheter, og det er det en SBOM er til for.
• Betrodde innsidere. Bakdøren i xz kom gjennom en betrodd vedlikeholder, og SLSA alene ville ikke ha stoppet den.

SLSA og andre rammeverk

SLSA går i dybden på byggeintegritet. NIST SSDF er mye bredere: Det dekker sikker utvikling som helhet, inkludert en praksis for å beskytte og arkivere utgivelser som SLSA-provenance støtter. SLSA er et prosjekt under OpenSSF, og mange team bruker de to sammen. For det store bildet, se hva er sikkerhet i programvareleverandørkjeden.

Hvor CRACI passer inn

CRACI produserer ikke signert provenance og hevder ikke noe SLSA-nivå, så bruk GitHub artifact attestations eller en lignende tjeneste hvis du trenger det. Det CRACI tilfører, er det SLSA utelater: en fullstendig oversikt over hva hver GitHub Actions-jobb trakk inn. Hver jobb kjører i sin egen isolerte virtuelle maskin, hver pakke den henter, går inn i en SBOM, og en egress-policy blokkerer tilkoblinger bygget ikke trenger. Se SBOM-generering under bygget.

SLSA: ofte stilte spørsmål

Hva står SLSA for?

Supply-chain Levels for Software Artifacts. Det uttales «salsa».

Hva er SLSA-nivåene?

Build-sporet har fire: L0, ingen garantier; L1, provenance finnes; L2, en hostet byggeplattform som signerer provenance; og L3, herdede bygg med isolerte kjøringer og beskyttede signeringshemmeligheter. Versjon 1.2 legger også til et Source-spor.

Hva er SLSA-provenance?

Dokumentasjon på hvordan en artefakt ble bygget: hvilken plattform, fra hvilken kilde, med hvilken prosess og med hvilke inndata på toppnivå. På Build L2 og høyere er den signert, så brukere kan verifisere den.

Hva er forskjellen på SLSA og en SBOM?

En SBOM viser hva som er inni en programvare. SLSA-provenance beskriver hvordan og hvor den ble bygget. Som regel vil du ha begge deler.

Er SLSA obligatorisk?

Nei. Det er et frivillig rammeverk fra OpenSSF-miljøet. Noen kunder og organisasjoner kan be om et nivå, men det er ikke en lov.

Hvilket SLSA-nivå bør jeg sikte mot?

Begynn med Build L1 ved å bygge i CI og generere provenance, og gå deretter til L2 på en hostet plattform, noe mange team kan nå raskt. L3 passer for utgivelser som mange andre er avhengige av, eller som innebærer høy risiko.