Google pakkus ettepaneku SLSA, et kaitsta arendamise protsessis pahatahtlike muudatuste eest

Google esitles raamistiku SLSA (Supply-chain Levels for Software Artifacts), mis koondab olemasolevaid kogemusi arendusinfotehnoloogia kaitsmiseks koodikirjutamise, testimise, koostamise ja toote levitamise etappides toimuvate rünnakute vastu.

Arendusprotsessid muutuvad üha keerulisemaks ja sõltuvaks kolmandate osapoolte tööriistadest, luues soodsa keskkonna rünnakute edasiviimiseks, mis ei keskendu haavatavuste tuvastamisele lõppproduktiles, vaid arendusprotsessi enda kompromiteerimisele (supply chain rünnakud, mille eesmärk on tavaliselt pahatahtlike muudatuste sisestamine koodikirjutamise protsessis, levitatavate komponentide ja sõltuvuste asendamine).

Raamistik arvestab 8 tüüpi rünnakutega, mis on seotud ohtudega pahatahtlike muudatuste tegemisel koodikirjutamise, koostamise, testimise ja toote levitamise etappides.

• A. Muudatuste lisamine lähtekoodi, mis sisaldavad tagaukse või varjatud vigu, mis võivad viia haavatavusteni.

  Rünnaku näide: "Hypocrite Commits" — katse edastada Linuxi tuumikusse haavatavustega patch'e.

  Pakutud kaitsemeetod: iga muudatuse sõltumatu ülevaatus kahe arendaja poolt.

• B. Lähtekoodi haldamise platvormi kompromiteerimine.

  Rünnaku näide: pahatahtlike tagauksega commit'ide sisestamine PHP projekti Git-reposiitosse pärast arendajate paroolide lekkimist.

  Pakutud kaitsemeetod: koodihalduse platvormi kaitse suurendamine (PHP puhul toimus rünnak vähe kasutusel olnud HTTPS-liidese kaudu, mis lubas muudatuste edastamist parooli abil ilma SSH-võtme kontrollimiseta, samal ajal kui paroolide hashimiseks kasutati ebaturvalist MD5).

• C. Muudatuste tegemine koodi edastamise etapis koostamis- või pideva integratsiooni süsteemi (koostatav kood ei vasta repos olevusele).

  Rünnaku näide: tagaukse sisestamine Webmini, muudaades koostamisinfrastruktuuri, mis viis repo failide asemel teiste failide kasutamiseni.

  Pakutud kaitsemeetod: koodi terviklikkuse kontrollimine ja allika identifitseerimine koostamisprotsessis. serveris.

• D. Koostamisplatvormi kompromiteerimine.

  Rünnaku näide: SolarWinds rünnak, mille käigus tagati koostamisprotsessis tagaukse sisestamine SolarWinds Orion tootesse.

  Pakutud kaitsemeetod: täiustatud turvameetmete rakendamine kogumisplatvormi jaoks.

• E. Kahjuliku koodi levitamine halva kvaliteediga sõltuvuste kaudu.

  Rünnaku näide: tagaukse lisamine populaarsetesse event-streami teekidesse, lisades kahjutu sõltuvuse, mis sisaldas kahjulikku koodi ühes selle sõltuvuse värskendustes (kahjulik muudatus polnud salvestatud git-repositooriumis, vaid esines ainult valmis MNP-paketis).

  Pakutud kaitsemeetod: SLSA nõuete rekurssiivne rakendamine kõigile sõltuvustele (event-streami korral oleks kokkupanek, mis ei vasta põhigiti repositooriumi sisule, tuvastatud).

• F. Artefaktide laadimine, mida ei ole loodud CI/CD süsteemis.

  Rünnaku näide: kahjuliku koodi lisamine CodeCov skripti, mis lubas häkkeritel juurdepääs klientide pideva integreerimise süsteemides hoitavatele andmetele.

  Pakutud kaitsemeetod: artefaktide päritolu ja terviklikkuse jälgimine (CodeCov puhul oleks tulnud tuvastada, et codecov.io veebisaidilt saadud Bash Uploader skript ei vasta projektirepositooriumi koodile).

• G. Pakettide repositooriumi kompromiteerimine.

  Rünnaku näide: uurijatel õnnestus seadistada peeglid mõnede populaarsete pakettide repositooriumide jaoks, et levitada kahjulikke pakette nende kaudu.

  Pakutud kaitsemeetod: Kontrollige, et levitatavad artefaktid on loodud deklareeritud lähtefailidest.

• H. Kasutaja segiajamise viisi kandev vale paketi installimine.

  Rünnaku näide: tüüpkoormuse kasutamine (NPM, RubyGems, PyPI) pakettide repositooriumides, mis on sarnased populaarsetele rakendustele (näiteks coffe-script kirjutamises coffee-script asemel).

Märgistatud ohtude blokeerimiseks pakub SLSA soovituste komplekti ning tööriistu metandmete automatiseerimise jaoks auditi jaoks. SLSA üldistab tavalisi rünnaku meetodeid ja tutvustab kaitse tasemeid. Iga tase esitab teatud nõuded infrastruktuurile, mis võimaldab tagada arendamisel kasutatavate artefaktide terviklikkust. Mida kõrgem on toetatav SLSA tase, seda rohkem kaitsemeetmeid on rakendatud ja seda paremini on infrastruktuur kaitstud tüüpiliste rünnakute eest.

• SLSA 1 nõuab, et kogumise protsess oleks täielikult automatiseeritud ja genereeriks metainfo („provenance“) selle kohta, kuidas artefaktid on kogutud, sealhulgas teavet algsete tekstide, sõltuvuste ja kogumise protsessi kohta (GitHub Actions jaoks on ette nähtud metainfo generaatori näide auditeerimiseks). SLSA 1 ei hõlma kuritarvitamise vastu kaitselemente, vaid tuvastab lihtsalt koodi ja pakub metainfo haldamiseks haavatavuste ja riskide analüüsi jaoks.
• SLSA 2 laiendab esimest taset nõudega kasutada versioonihaldussüsteemi ja kogumise teenuseid, mis genereerivad autentitud metainfo. SLSA 2 rakendamine võimaldab jälgida koodi päritolu ja takistab autoriseerimata muudatuste tegemist koodis, kui kasutatakse usaldusväärseid kogumise teenuseid.
• SLSA 3 kinnitab, et algsed tekstid ja kogumise platvorm vastavad standardite nõuetele, mis tagavad koodi auditeerimise võimaluse ja esitatud metainformatsiooni terviklikkuse. Eeldatakse, et auditeerijad saavad sertifitseerida platvorme vastavuse kontrollimiseks standardite nõuetele.
• SLSA 4 — kõrgeim tase, mis täiendab eelnevaid tasemeid järgmiste nõuetega:
  • Kohustuslik kõigi muudatuste läbivaatamine kahe erineva arendaja poolt.
  • Kõik kogumise sammud, kood ja sõltuvused peavad olema täielikult deklareeritud, kõik sõltuvused peavad olema eraldi välja tõmmatud ja kontrollitud, ning kogumise protsess peab toimuma ilma võrguühenduseta.
  • Korduvate kogemise protsessi rakendamine — võimalus kordata kogumise protsessi omal käel ja veenduda, et täidetav fail on koostatud esitatud algsetest tekstidest.
  
  
  Allikas: opennet.ru