Wat is SLSA?

Welk probleem lost SLSA op?

U kunt elke regel broncode beoordelen en toch iets anders leveren, want wat gebruikers draaien, is de output van een build. Is de build gecompromitteerd, zoals bij SolarWinds, dan levert schone broncode een vergiftigde release op. SLSA richt zich op dat hiaat: kan iemand verifiëren dat dit artefact via dit proces uit deze broncode is ontstaan?

SLSA-niveaus

SLSA verdeelt zijn eisen over tracks. De huidige versie, 1.2, heeft een Build-track en een Source-track. De Build-track heeft vier niveaus.

Niveau	Naam	Wat het vereist	Wat het u oplevert
Build L0	Geen garanties	Niets	L0 is de afwezigheid van SLSA
Build L1	Herkomstgegevens bestaan	Een consistent buildproces, en herkomstgegevens die het buildplatform genereert en aan afnemers verstrekt	Helpt fouten voorkomen, maar is triviaal te omzeilen of te vervalsen
Build L2	Gehost buildplatform	Builds draaien op een gehost platform dat de herkomstgegevens genereert en ondertekent, en afnemers verifiëren ze	Herkomstgegevens vervalsen vraagt nu om een doelbewuste aanval
Build L3	Geharde builds	Runs zijn van elkaar geïsoleerd, en het ondertekeningssecret is buiten bereik van door gebruikers gedefinieerde buildstappen	Herkomstgegevens vervalsen vereist het misbruiken van een kwetsbaarheid, wat de meeste tegenstanders niet kunnen

Niveaus zijn geen cijfer dat u moet maximaliseren. Elk niveau beschermt tegen specifieke dreigingen, dus kies het niveau dat bij uw risico past. Open-sourcemaintainers met een gehoste CI-dienst kunnen vaak zonder veel werk L2 halen.

Wat zijn herkomstgegevens?

Herkomstgegevens (provenance) zijn een record van hoe een artefact is gemaakt. In SLSA vermelden ze welk platform het heeft gebouwd, vanuit welke broncode, via welk proces en met welke invoer op het hoogste niveau. Vanaf L2 zijn herkomstgegevens ondertekend, zodat een afnemer kan controleren dat ze van het buildplatform komen en niet zijn gewijzigd.

Zie een SBOM als de ingrediënten, en herkomstgegevens als waar en hoe het gerecht is bereid. Ze beantwoorden verschillende vragen en vullen elkaar goed aan: een SBOM vermeldt wat erin zit, terwijl herkomstgegevens zeggen waar het artefact vandaan komt.

Hoe voert u SLSA in?

1. Bouw in CI, elke keer op dezelfde manier. Stop met releases vanaf laptops. Dit is het meeste werk om L1 te halen.
2. Genereer herkomstgegevens. Op GitHub leveren artifact attestations ondertekende herkomstgegevens. Zie hoe attestations werken met SBOM's in GitHub Actions.
3. Verifieer op een plek die ertoe doet. Ondertekende herkomstgegevens die niemand controleert, beschermen niemand. Voeg verificatie toe aan uw deploymentstap of admission controller.
4. Versterk de build. Isoleer runs en houd ondertekeningssleutels weg van buildstappen. Zie runnerbeveiliging vergeleken.
5. Vraag het uw afhankelijkheden. Geef de voorkeur aan pakketten die herkomstgegevens publiceren, wat registries zoals npm nu ondersteunen.

Wat SLSA niet dekt

• Kwetsbaarheden. Een perfect gebouwd artefact kan een fout bevatten. SLSA zegt niets over de vraag of de code veilig is.
• Kwaadaardige broncode. Als een aanvaller naar de repository commit, leggen herkomstgegevens getrouw een build van die code vast. De Source-track pakt een deel hiervan aan.
• Wat de build heeft binnengehaald. Herkomstgegevens vermelden invoer op het hoogste niveau. Niets in de Build-track vereist een volledige lijst van afhankelijkheden, en daar is een SBOM voor.
• Vertrouwde insiders. De xz-backdoor kwam via een vertrouwde maintainer, en SLSA alleen had die niet tegengehouden.

SLSA en andere kaders

SLSA gaat diep in op buildintegriteit. Het NIST SSDF is veel breder: het behandelt veilige ontwikkeling als geheel, inclusief een werkwijze voor het beschermen en archiveren van releases die SLSA-herkomstgegevens ondersteunen. SLSA is een project van de OpenSSF, en veel teams gebruiken de twee samen. Voor het grotere plaatje, zie wat is ketenbeveiliging van software.

Waar CRACI past

CRACI produceert geen ondertekende herkomstgegevens en claimt geen SLSA-niveau, dus gebruik GitHub artifact attestations of een vergelijkbare dienst als u die nodig hebt. Wat CRACI toevoegt, is wat SLSA weglaat: een volledig record van wat elke GitHub Actions-job heeft binnengehaald. Elke job draait in een eigen geïsoleerde virtuele machine, elk pakket dat hij ophaalt, komt in een SBOM, en een egressbeleid blokkeert verbindingen die de build niet nodig heeft. Zie build-time SBOM-generatie.

SLSA: veelgestelde vragen

Waar staat SLSA voor?

Supply-chain Levels for Software Artifacts. Het wordt uitgesproken als "salsa".

Wat zijn de SLSA-niveaus?

De Build-track heeft er vier: L0, geen garanties; L1, herkomstgegevens bestaan; L2, een gehost buildplatform dat herkomstgegevens ondertekent; en L3, geharde builds met geïsoleerde runs en beschermde ondertekeningssecrets. Versie 1.2 voegt daarnaast een Source-track toe.

Wat zijn SLSA-herkomstgegevens?

Een record van hoe een artefact is gebouwd: welk platform, vanuit welke broncode, via welk proces en met welke invoer op het hoogste niveau. Vanaf Build L2 zijn ze ondertekend, zodat afnemers ze kunnen verifiëren.

Wat is het verschil tussen SLSA en een SBOM?

Een SBOM vermeldt wat er in een stuk software zit. SLSA-herkomstgegevens beschrijven hoe en waar het is gebouwd. Over het algemeen wilt u beide.

Is SLSA verplicht?

Nee. Het is een vrijwillig framework van de OpenSSF-community. Sommige klanten en organisaties kunnen om een niveau vragen, maar het is geen wet.

Welk SLSA-niveau moet ik nastreven?

Begin met Build L1 door in CI te bouwen en herkomstgegevens te genereren, en ga daarna naar L2 op een gehost platform, wat veel teams snel kunnen halen. L3 past bij releases waar veel anderen van afhankelijk zijn of die een hoog risico dragen.