Hvad er SLSA?

Hvilket problem løser SLSA?

Du kan gennemgå hver linje kildekode og alligevel levere noget andet, for det, brugerne kører, er outputtet af et build. Hvis buildet er kompromitteret, som det var hos SolarWinds, giver ren kildekode en forgiftet release. SLSA fokuserer på det hul: Kan nogen verificere, at dette artefakt kom fra denne kilde gennem denne proces?

SLSA-niveauer

SLSA organiserer sine krav i tracks. Den aktuelle version, 1.2, har et Build-track og et Source-track. Build-tracket har fire niveauer.

Niveau	Navn	Hvad det kræver	Hvad det giver dig
Build L0	Ingen garantier	Intet	L0 er fraværet af SLSA
Build L1	Provenance findes	En ensartet build-proces og provenance, der genereres af build-platformen og gives til forbrugerne	Hjælper med at forebygge fejl, men er trivielt at omgå eller forfalske
Build L2	Hostet build-platform	Builds kører på en hostet platform, der genererer og signerer provenance, og forbrugerne verificerer den	At forfalske provenance kræver nu et bevidst angreb
Build L3	Hærdede builds	Kørsler er isoleret fra hinanden, og signeringshemmeligheden er uden for rækkevidde af brugerdefinerede build-trin	At forfalske provenance kræver udnyttelse af en sårbarhed, hvilket ligger ud over de fleste modstanderes evner

Niveauer er ikke en karakter, du skal maksimere. Hvert niveau beskytter mod bestemte trusler, så vælg det niveau, der passer til din risiko. Open source-maintainere med en hostet CI-tjeneste kan ofte nå L2 uden det store arbejde.

Hvad er provenance?

Provenance er en registrering af, hvordan et artefakt blev lavet. I SLSA siger den, hvilken platform der byggede det, ud fra hvilken kilde, gennem hvilken proces og med hvilke input på øverste niveau. Provenance på L2 og derover er signeret, så en forbruger kan tjekke, at den kom fra build-platformen og ikke er blevet ændret.

Tænk på en SBOM som ingredienserne og på provenance som hvor og hvordan retten blev tilberedt. De besvarer forskellige spørgsmål og fungerer godt sammen: En SBOM angiver, hvad der er indeni, mens provenance siger, hvor artefaktet kom fra.

Sådan tager du SLSA i brug

1. Byg i CI, på samme måde hver gang. Stop med at udgive fra laptops. Det er det meste af arbejdet med at nå L1.
2. Generér provenance. På GitHub producerer artifact attestations signeret provenance. Se hvordan attestations fungerer med SBOM'er i GitHub Actions.
3. Verificér den et sted, hvor det betyder noget. Signeret provenance, som ingen tjekker, beskytter ingen. Føj verificering til dit deployment-trin eller din admission controller.
4. Hærd buildet. Isolér kørsler, og hold signeringsnøgler væk fra build-trin. Se runner-sikkerhed sammenlignet.
5. Stil krav til dine afhængigheder. Foretræk pakker, der offentliggør provenance, hvilket registries som npm nu understøtter.

Hvad SLSA ikke dækker

• Sårbarheder. Et perfekt bygget artefakt kan indeholde en fejl. SLSA siger intet om, hvorvidt koden er sikker.
• Ondsindet kildekode. Hvis en angriber committer til repositoriet, registrerer provenance troligt et build af den kode. Source-tracket tager fat på en del af det.
• Hvad buildet trak ind. Provenance angiver input på øverste niveau. Intet i Build-tracket kræver en fuld liste over afhængigheder, og det er det, en SBOM er til.
• Betroede insidere. Bagdøren i xz kom gennem en betroet maintainer, og SLSA alene ville ikke have stoppet den.

SLSA og andre rammeværker

SLSA går i dybden med build-integritet. NIST SSDF er langt bredere: Det dækker sikker udvikling som helhed, herunder en praksis om at beskytte og arkivere releases, som SLSA-provenance understøtter. SLSA er et projekt under OpenSSF, og mange teams bruger de to sammen. Det store billede finder du i hvad er forsyningskædesikkerhed for software.

Hvor CRACI passer ind

CRACI producerer ikke signeret provenance og gør ikke krav på et SLSA-niveau, så brug GitHub artifact attestations eller en lignende tjeneste, hvis du har brug for det. Det, CRACI tilføjer, er det, SLSA udelader: en fuld registrering af, hvad hvert GitHub Actions-job trak ind. Hvert job kører i sin egen isolerede virtuelle maskine, hver pakke, det henter, kommer i en SBOM, og en egress-politik blokerer forbindelser, buildet ikke har brug for. Se SBOM-generering under buildet.

SLSA: ofte stillede spørgsmål

Hvad står SLSA for?

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

Hvad er SLSA-niveauerne?

Build-tracket har fire: L0, ingen garantier; L1, provenance findes; L2, en hostet build-platform, der signerer provenance; og L3, hærdede builds med isolerede kørsler og beskyttede signeringshemmeligheder. Version 1.2 tilføjer også et Source-track.

Hvad er SLSA-provenance?

En registrering af, hvordan et artefakt blev bygget: hvilken platform, ud fra hvilken kilde, gennem hvilken proces og med hvilke input på øverste niveau. På Build L2 og derover er den signeret, så forbrugere kan verificere den.

Hvad er forskellen på SLSA og en SBOM?

En SBOM angiver, hvad der er inde i et stykke software. SLSA-provenance beskriver, hvordan og hvor det blev bygget. Som regel vil du have begge dele.

Er SLSA obligatorisk?

Nej. Det er et frivilligt rammeværk fra OpenSSF-fællesskabet. Nogle kunder og organisationer kan bede om et niveau, men det er ikke en lov.

Hvilket SLSA-niveau skal jeg sigte efter?

Start med Build L1 ved at bygge i CI og generere provenance, og gå derefter til L2 på en hostet platform, som mange teams kan nå hurtigt. L3 passer til releases, som mange andre afhænger af, eller som indebærer høj risiko.