Ohjelmistotoimitusketjun tietoturvan parhaat käytännöt

Lähdekoodi

• Vaadi vahva tunnistautuminen. Käytä monivaiheista tunnistautumista jokaisessa koodinhallintapalvelun tilissä.
• Suojaa päähaara. Vaadi katselmointi ennen yhdistämistä, äläkä anna kenenkään puskea suoraan julkaisuhaaraan.
• Pidä salaisuudet poissa koodista. Skannaa niitä jokaisen pushin yhteydessä ja vaihda kaikki, mikä on paljastunut.
• Käsittele työnkulkutiedostoja koodina. Putken muutos voi päästä käsiksi salaisuuksiisi, joten vaadi omistajia katselmoimaan ne.

Riippuvuudet

• Commitoi lukitustiedosto ja asenna siitä. Käytä komentoa npm ci ja sen vastineita, jotta buildit eivät ota uusia versioita käyttöön vahingossa. Lukitustiedostolla on rajansa, mutta siitä on hyvä aloittaa.
• Lisää odotusaika uusille versioille. Haitalliset julkaisut havaitaan usein pian niiden ilmestymisen jälkeen, joten kun et ota versiota käyttöön julkaisupäivänä, havaitsemiselle jää aikaa.
• Rajoita asennusskriptejä. Poista ne käytöstä, missä voit. Asennuksen yhteydessä ajettavat skriptit ovat tapa, jolla npm-madot leviävät.
• Arvioi uudet riippuvuudet. Tarkista nimi typosquattingin varalta ja katso ylläpitoa ja suosiota. OpenSSF Scorecard automatisoi osan tästä.
• Suojaa sisäiset pakettinimet. Käytä scopeja ja rekisterin asetuksia, jotta julkinen paketti ei voi korvata sisäistä dependency confusionin kautta.
• Karsi tarpeeton. Jokainen riippuvuus on taas yksi seurattava asia.

Buildi ja CI/CD

• Kiinnitä GitHub Actions täyteen commit-tiivisteeseen. Tageja voi siirtää, kuten tj-actions-murto osoitti.
• Rajoita, mitä kukin jobi voi tehdä. Anna työnkulun tokenille vain sen tarvitsemat vähimmäisoikeudet ja käytä lyhytikäisiä tunnistetietoja pitkäikäisten salaisuuksien sijaan.
• Rajoita lähtevää liikennettä. Buildi tarvitsee paketteja tunnetuista lähteistä ja julkaisee tunnettuihin paikkoihin. Estä kaikki muu, niin varastetuilla salaisuuksilla ei ole minne mennä. Katso GitHub Actionsin egress-käytäntö.
• Aja jokainen jobi uudessa, eristetyssä ympäristössä. Mitään ei pitäisi siirtyä jobista seuraavaan, kaikkein vähiten ulkopuolisen kehittäjän pull requestista.
• Käsittele välimuisteja syötteenä. Myrkytetty välimuisti säilyy buildista toiseen, ja sen palauttama sisältö jää helposti huomaamatta. Katso GitHub Actionsin välimuisti.

Koko luettelo on sivuilla CI/CD-putken tietoturvan tarkistuslista ja runnereiden tietoturvan vertailu.

Julkaisu

• Generoi SBOM jokaisesta julkaisusta, buildista käsin. Säilytä se artefaktin kanssa. Katso SBOM:n parhaat käytännöt.
• Allekirjoita artefaktit ja julkaise alkuperätiedot. Käyttäjät voivat silloin tarkistaa, mistä julkaisu tuli. SLSA määrittelee tasot.
• Buildaa julkaisut vain CI:ssä. Kannettavalta tehdyn julkaisun takana ei ole luotettavaa kirjausta.
• Käytä yhtä artefaktia testistä tuotantoon. Siirrä eteenpäin se, minkä testasit, äläkä buildaa sitä uudelleen, jotta kirjaus pysyy totena.

Julkaisun jälkeen

• Seuraa sitä, mitä toimitit. Tarkista tuettujen julkaisujen SBOM:t jatkuvasti uusia haavoittuvuuksia vasten.
• Priorisoi muullakin kuin CVSS:llä. Käytä CISA KEV:iä, EPSS:ää ja kontekstia. Katso miten haavoittuvuuksia priorisoidaan.
• Tiedä, kuinka kauan olit altis. Buildihistoria näyttää, mitkä julkaisut sisälsivät paketin ja mistä lähtien.
• Tee suunnitelma ennen kuin tarvitset sitä. Päätä, kuka hoitaa triagen, kuka korjaa ja kuka viestii asiakkaille. Katso haavoittuvuuksien hallinnan elinkaari.
• Harjoittele todellisella skenaariolla. Kysy, kuinka kauan kestäisi löytää jokainen julkaisu, jossa tietty paketti on. Jos vastaus on päiviä, aloita siitä.

Mitä tehdä ensin

Milloin	Tee tämä
Tällä viikolla	Monivaiheinen tunnistautuminen, lukitustiedostot CI:ssä, kiinnitetyt GitHub Actions -actionit, työnkulkujen tokenit vähimmäisoikeuksin
Tässä kuussa	SBOM jokaisesta julkaisubuildista, riippuvuushälytykset omistajineen, salaisuuksien skannaus
Tällä vuosineljänneksellä	Lähtevän liikenteen säännöt buildeille, toimitettujen julkaisujen seuranta, testattu reagointisuunnitelma
Seuraavaksi	Allekirjoitetut alkuperätiedot, SLSA:n tai NIST SSDF:n kattavuuden muodollinen arviointi, toimittajien SBOM:t

Mitkä näistä CRACI hoitaa

CRACI kattaa buildin ja kaiken sen jälkeen. GitHub Actions -runnerinasi se ajaa jokaisen jobin omassa eristetyssä virtuaalikoneessaan, kirjaa jokaisen jobin hakeman paketin SBOM:iin, merkitsee CI-välimuisteista palautetut paketit ja valvoo egress-käytäntöä, joka estää yhteydet, joita buildisi ei tarvitse. Sen jälkeen se tarkistaa jatkuvasti toimitetun, näyttää, mitkä buildit sisälsivät haavoittuvan paketin, ja voi estää buildeja käytäntöporteilla.

Loput jäävät muille työkaluillesi: CRACI ei skannaa lähdekoodia tai salaisuuksia, ei tunnista uusia haitallisia paketteja niiden käyttäytymisen perusteella eikä allekirjoita SBOM:eja tai alkuperätietoja. Katso ohjelmistotoimitusketjun tietoturvatyökalujen vertailu, niin näet, mikä täyttää kunkin aukon.

Ohjelmistotoimitusketjun tietoturvan parhaat käytännöt: usein kysytyt kysymykset

Miten ohjelmistotoimitusketju suojataan?

Tiedä, mitä toimitat, jokaisen julkaisubuildin SBOM:n avulla, hallitse sitä, mitä sisään tulee, lukitustiedostoilla ja arvioinnilla, suojaa buildi rajoittamalla salaisuuksia ja lähtevää liikennettä ja seuraa jatkuvasti julkaisemaasi.

Mitä pienen tiimin kannattaa tehdä ensin?

Ota käyttöön monivaiheinen tunnistautuminen, asenna CI:ssä lukitustiedostoista, kiinnitä GitHub Actions commit-tiivisteisiin ja anna työnkulkujen tokeneille vain niiden tarvitsemat vähimmäisoikeudet. Nämä vaiheet vievät päiviä ja sulkevat yleisiä hyökkäysreittejä.

Miten haitalliset paketit estetään?

Yksikään vaihe ei yksin riitä. Viivästytä uusien versioiden käyttöönottoa, rajoita asennusskriptejä ja arvioi uudet riippuvuudet. Buildien lähtevän liikenteen rajoittaminen rajaa vahinkoja, jos haitallinen paketti pääsee läpi.

Miksi GitHub Actions kannattaa kiinnittää commit-tiivisteeseen?

Koska versiotagin voi siirtää osoittamaan eri koodiin. Täysi commit-tiiviste viittaa aina samaan koodiin, joten kaapattu tagi ei pääse putkeesi.

Kuinka usein toimitusketju pitäisi arvioida?

Seurannan pitäisi olla jatkuvaa. Arvioi riippuvuuskäytäntösi, työnkulkujen oikeudet ja reagointisuunnitelmasi vähintään vuosittain ja aina, kun pinossasi on sattunut tapaus.