Google esitteli SLSA-kehyksen (Supply-chain Levels for Software Artifacts), joka tiivistää olemassa olevan kokemuksen kehitysinfrastruktuurin suojaamisesta hyökkäyksiltä koodin kirjoittamisen, testauksen, kokoamisen ja tuotteen jakeluvaiheessa.
Kehitysprosessit ovat yhä monimutkaisempia ja riippuvaisempia kolmansien osapuolien työkaluista, mikä luo suotuisat olosuhteet sellaisten hyökkäysten etenemiselle, jotka eivät liity lopputuotteen haavoittuvuuksien tunnistamiseen ja hyödyntämiseen, vaan itse kehitysprosessin vaarantamiseen (toimitusketjuhyökkäykset, jotka yleensä kohdistuvat haitallisten muutosten tekeminen koodin kirjoitusprosessiin, hajautettujen komponenttien korvaamiseen ja riippuvuuksiin).
Kehys ottaa huomioon 8 tyyppistä hyökkäystä, jotka liittyvät haitallisten muutosten uhkaan tuotteen koodin kehitys-, kokoonpano-, testaus- ja jakeluvaiheessa.
- A. Mukaan lukien muutokset lähdekoodiin, jotka sisältävät takaovia tai piilotettuja virheitä, jotka johtavat haavoittuvuuksiin.
Esimerkki hyökkäyksestä: Hypocrite Commits - yritys edistää Linux-ytimeen haavoittuvuuksia sisältäviä korjaustiedostoja.
Suositeltu suojausmenetelmä: kahden kehittäjän riippumaton tarkastus jokaisesta muutoksesta.
- B. Lähdekoodin ohjausalustan kompromissi.
Esimerkki hyökkäyksestä: haitallisten sitoumusten lisääminen takaovella PHP-projektin Git-varastoon kehittäjien salasanojen vuotamisen jälkeen.
Suositeltu suojausmenetelmä: Koodinhallintaalustan turvallisuuden lisääminen (PHP:n tapauksessa hyökkäys tehtiin vähän käytetyn HTTPS-rajapinnan kautta, joka mahdollisti muutosten lähettämisen salasanalla kirjautuessa ilman SSH-avainta tarkistamatta se, että epäluotettavaa MD5:tä käytettiin salasanojen hajauttamiseen).
- C. Muutosten tekeminen koodin siirtovaiheessa koontijärjestelmään tai jatkuvaan integrointijärjestelmään (rakennettu koodi, joka ei vastaa arkiston koodia).
Esimerkki hyökkäyksestä: Takaoven lisääminen Webminiin tekemällä muutoksia rakennusinfrastruktuuriin, mikä johtaa kooditiedostojen käyttöön, jotka eroavat arkiston tiedostoista.
Ehdotettu suojausmenetelmä: Eheyden tarkistaminen ja koodin lähteen tunnistaminen kokoonpanopalvelimella.
- D. Kokoonpanoalustan kompromissi.
Esimerkki hyökkäyksestä: SolarWinds-hyökkäys, jonka aikana SolarWinds Orion -tuotteeseen varmistettiin takaoven asennus kokoonpanovaiheessa.
Ehdotettu suojausmenetelmä: edistyneiden turvatoimenpiteiden toteuttaminen kokoonpanoalustalle.
- E. Haitallisen koodin mainostaminen heikkolaatuisten riippuvuuksien kautta.
Esimerkki hyökkäyksestä: takaoven lisääminen suosittuun tapahtumavirtakirjastoon lisäämällä harmiton riippuvuus ja sisällyttämällä sitten haitallinen koodi johonkin tämän riippuvuuden päivityksestä (haitallinen muutos ei näkynyt git-tietovarastossa, mutta läsnä vain valmiissa MNP-pakkauksessa).
Ehdotettu suojausmenetelmä: sovelletaan rekursiivisesti SLSA-vaatimuksia kaikkiin riippuvuuksiin (tapahtumavirran tapauksessa tarkistus paljastaisi koodin kokoonpanon, joka ei vastaa Git-päätietovaraston sisältöä).
- F. Muiden kuin CI/CD-järjestelmässä luotujen artefaktien lataaminen.
Esimerkki hyökkäyksestä: haitallisen koodin lisääminen CodeCov-komentosarjaan, jonka avulla hyökkääjät pystyivät poimimaan asiakkaan jatkuvaan integrointijärjestelmään tallennettuja tietoja.
Ehdotettu suojausmenetelmä: artefaktien lähteen ja eheyden hallinta (CodeCovin tapauksessa saattaa ilmetä, että codecov.io-verkkosivustolta lähetetty Bash Uploader -skripti ei vastaa projektivaraston koodia).
- G. Pakettivaraston vaarantaminen.
Esimerkki hyökkäyksestä: Tutkijat pystyivät ottamaan käyttöön joidenkin suosittujen pakettivarastojen peilejä levittääkseen haitallisia paketteja niiden kautta.
Ehdotettu suojausmenetelmä: Varmistetaan, että hajautetut artefaktit on käännetty ilmoitetuista lähdekoodeista.
- H. Käyttäjän hämmentäminen asentamaan väärä paketti.
Esimerkki hyökkäyksestä: typosquattingin (NPM, RubyGems, PyPI) käyttäminen pakettien sijoittamiseen arkistoihin, jotka ovat kirjoitettuja samankaltaisia kuin suosittuja sovelluksia (esimerkiksi coffe-script coffee-scriptin sijaan).
Ilmoitettujen uhkien estämiseksi SLSA tarjoaa joukon suosituksia sekä työkaluja tarkastuksen metatietojen luomisen automatisoimiseksi. SLSA tekee yhteenvedon yleisistä hyökkäysmenetelmistä ja esittelee suojauskerrosten käsitteen. Jokainen taso asettaa tiettyjä infrastruktuurivaatimuksia kehityksessä käytettyjen esineiden eheyden varmistamiseksi. Mitä korkeampi tuettu SLSA-taso, sitä enemmän suojauksia toteutetaan ja sitä paremmin infrastruktuuri on suojattu yleisiltä hyökkäyksiltä.
- SLSA 1 edellyttää, että koontiprosessi on täysin automatisoitu ja että se tuottaa metadataa ("alkuperä") artefaktien rakentamisesta, mukaan lukien tiedot lähteistä, riippuvuuksista ja koontiprosessista (GitHub Actionsille tarjotaan esimerkki metadatan luontiohjelmasta). SLSA 1 ei sisällä suojaelementtejä haitallisilta muokkauksilta, vaan se yksinkertaisesti tunnistaa koodin ja tarjoaa metatietoja haavoittuvuuksien hallintaa ja riskianalyysiä varten.
- SLSA 2 - laajentaa ensimmäistä tasoa vaatimalla versionhallinta- ja kokoonpanopalveluiden käyttöä, jotka luovat todennettuja metatietoja. SLSA 2:n käyttö mahdollistaa koodin alkuperän jäljittämisen ja estää koodin luvattoman muuttamisen luotettujen koontipalveluiden tapauksessa.
- SLSA 3 - vahvistaa, että lähdekoodi ja rakennusalusta täyttävät standardien vaatimukset, jotka takaavat koodin tarkastamisen ja toimitettujen metatietojen eheyden. Oletetaan, että tilintarkastajat voivat sertifioida alustat standardien vaatimusten mukaisesti.
- SLSA 4 on korkein taso, joka täydentää aikaisempia tasoja seuraavilla vaatimuksilla:
- Kahden eri kehittäjän kaikkien muutosten pakollinen tarkistus.
- Kaikki rakennusvaiheet, koodi ja riippuvuudet on ilmoitettava täysin, kaikki riippuvuudet on purettava ja tarkistettava erikseen ja koontiprosessi on suoritettava offline-tilassa.
- Toistettavan koontiprosessin avulla voit toistaa koontiprosessin itse ja varmistaa, että suoritettava tiedosto on rakennettu toimitetusta lähdekoodista.
Lähde: opennet.ru