Mikä on SLSA?

Minkä ongelman SLSA ratkaisee?

Voit katselmoida jokaisen lähdekoodirivin ja silti toimittaa jotain muuta, koska käyttäjät ajavat buildin tuotosta. Jos buildi on kompromissoitu, kuten SolarWindsillä, puhtaasta lähdekoodista syntyy myrkytetty julkaisu. SLSA keskittyy tähän aukkoon: voiko kuka tahansa varmistaa, että tämä artefakti on peräisin tästä lähdekoodista tämän prosessin kautta?

SLSA-tasot

SLSA jakaa vaatimuksensa raitoihin (tracks). Nykyisessä versiossa 1.2 on Build-raita ja Source-raita. Build-raidalla on neljä tasoa.

Taso	Nimi	Mitä se vaatii	Mitä se antaa
Build L0	Ei takeita	Ei mitään	L0 tarkoittaa, ettei SLSA:ta ole
Build L1	Alkuperätiedot ovat olemassa	Johdonmukainen build-prosessi sekä build-alustan tuottamat alkuperätiedot, jotka annetaan käyttäjille	Auttaa estämään virheitä, mutta on helppo ohittaa tai väärentää
Build L2	Hostattu build-alusta	Buildit ajetaan hostatulla alustalla, joka tuottaa ja allekirjoittaa alkuperätiedot, ja käyttäjät varmistavat ne	Alkuperätietojen väärentäminen vaatii nyt tietoisen hyökkäyksen
Build L3	Kovennetut buildit	Ajot on eristetty toisistaan, eivätkä käyttäjän määrittämät build-vaiheet pääse käsiksi allekirjoitussalaisuuteen	Alkuperätietojen väärentäminen vaatii haavoittuvuuden hyödyntämistä, mihin useimmat hyökkääjät eivät pysty

Tasot eivät ole arvosana, joka pitäisi maksimoida. Jokainen niistä suojaa tietyiltä uhilta, joten valitse taso, joka sopii riskiisi. Avoimen lähdekoodin ylläpitäjät, joilla on hostattu CI-palvelu, pääsevät usein tasolle L2 ilman suurta vaivaa.

Mitä alkuperätiedot ovat?

Alkuperätiedot (provenance) ovat tallenne siitä, miten artefakti on tehty. SLSA:ssa ne kertovat, mikä alusta sen buildasi, mistä lähdekoodista, millä prosessilla ja millä ylätason syötteillä. Tasolla L2 ja sitä ylemmillä alkuperätiedot on allekirjoitettu, joten käyttäjä voi tarkistaa, että ne tulevat build-alustalta eikä niitä ole muutettu.

Ajattele SBOM:ia ainesosaluettelona ja alkuperätietoja tietona siitä, missä ja miten ruoka valmistettiin. Ne vastaavat eri kysymyksiin ja toimivat hyvin yhdessä: SBOM luettelee, mitä sisällä on, ja alkuperätiedot kertovat, mistä artefakti on peräisin.

Miten SLSA otetaan käyttöön

1. Buildaa CI:ssä, joka kerta samalla tavalla. Lopeta julkaiseminen läppäreiltä. Tämä on suurin osa tasolle L1 pääsemisen työstä.
2. Tuota alkuperätiedot. GitHubissa artifact attestations tuottavat allekirjoitetut alkuperätiedot. Katso, miten attestaatiot toimivat SBOM:ien kanssa GitHub Actionsissa.
3. Varmista ne siellä, missä sillä on merkitystä. Allekirjoitetut alkuperätiedot, joita kukaan ei tarkista, eivät suojaa ketään. Lisää varmistus käyttöönottovaiheeseen tai admission controlleriin.
4. Kovenna buildi. Eristä ajot ja pidä allekirjoitusavaimet poissa build-vaiheiden ulottuvilta. Katso runnereiden tietoturva vertailussa.
5. Kysy riippuvuuksiltasi. Suosi paketteja, jotka julkaisevat alkuperätiedot, mitä esimerkiksi npm:n kaltaiset rekisterit nyt tukevat.

Mitä SLSA ei kata

• Haavoittuvuudet. Täydellisesti buildatussa artefaktissa voi olla vika. SLSA ei sano mitään siitä, onko koodi turvallista.
• Haitallinen lähdekoodi. Jos hyökkääjä tekee commitin repositorioon, alkuperätiedot tallentavat uskollisesti tuon koodin buildin. Source-raita käsittelee osan tästä.
• Mitä buildi haki mukaansa. Alkuperätiedot luettelevat ylätason syötteet. Mikään Build-raidalla ei vaadi täydellistä riippuvuusluetteloa, ja juuri sitä varten SBOM on olemassa.
• Luotetut sisäpiiriläiset. xz-takaovi tuli luotetun ylläpitäjän kautta, eikä SLSA yksin olisi pysäyttänyt sitä.

SLSA ja muut viitekehykset

SLSA menee syvälle buildin eheyteen. NIST SSDF on paljon laajempi: se kattaa turvallisen kehityksen kokonaisuutena, mukaan lukien käytännön julkaisujen suojaamisesta ja arkistoinnista, jota SLSA:n alkuperätiedot tukevat. SLSA on OpenSSF:n projekti, ja monet tiimit käyttävät niitä yhdessä. Laajemman kuvan saat sivulta mitä ohjelmistotoimitusketjun tietoturva on.

Mihin CRACI sopii

CRACI ei tuota allekirjoitettuja alkuperätietoja eikä väitä täyttävänsä mitään SLSA-tasoa, joten käytä GitHubin artifact attestations -toimintoa tai vastaavaa palvelua, jos tarvitset niitä. CRACI lisää sen, minkä SLSA jättää pois: täydellisen tallenteen siitä, mitä kukin GitHub Actions -jobi haki mukaansa. Jokainen jobi ajetaan omassa eristetyssä virtuaalikoneessaan, jokainen sen hakema paketti päätyy SBOM:iin, ja egress-käytäntö estää yhteydet, joita buildi ei tarvitse. Katso SBOM-generointi buildin aikana.

SLSA: usein kysytyt kysymykset

Mistä SLSA tulee?

Sanoista Supply-chain Levels for Software Artifacts. Se lausutaan "salsa".

Mitkä ovat SLSA-tasot?

Build-raidalla on neljä tasoa: L0, ei takeita; L1, alkuperätiedot ovat olemassa; L2, hostattu build-alusta, joka allekirjoittaa alkuperätiedot; ja L3, kovennetut buildit, joissa ajot on eristetty ja allekirjoitussalaisuudet suojattu. Versio 1.2 lisää myös Source-raidan.

Mitä SLSA:n alkuperätiedot ovat?

Tallenne siitä, miten artefakti on buildattu: millä alustalla, mistä lähdekoodista, millä prosessilla ja millä ylätason syötteillä. Tasolla Build L2 ja sitä ylemmillä ne on allekirjoitettu, joten käyttäjät voivat varmistaa ne.

Mikä ero on SLSA:lla ja SBOM:lla?

SBOM luettelee, mitä ohjelmiston sisällä on. SLSA:n alkuperätiedot kuvaavat, miten ja missä se on buildattu. Yleensä tarvitset molemmat.

Onko SLSA pakollinen?

Ei. Se on OpenSSF-yhteisön vapaaehtoinen viitekehys. Jotkin asiakkaat ja organisaatiot voivat vaatia tiettyä tasoa, mutta se ei ole laki.

Mihin SLSA-tasoon minun kannattaa pyrkiä?

Aloita tasosta Build L1 buildaamalla CI:ssä ja tuottamalla alkuperätiedot, ja siirry sitten tasolle L2 hostatulla alustalla, jonne moni tiimi pääsee nopeasti. L3 sopii julkaisuille, joista moni muu riippuu tai joihin liittyy suuri riski.