Google kynnti SLSA (Supply-chain Levels for Software Artifacts) ramma, sem dregur saman núverandi reynslu af því að vernda þróunarinnviði fyrir árásum sem gerðar eru á því stigi að skrifa kóða, prófa, setja saman og dreifa vöru.
Þróunarferlar verða sífellt flóknari og háðir verkfærum þriðja aðila, sem skapar hagstæð skilyrði fyrir framgangi árása sem tengjast ekki því að bera kennsl á og nýta veikleika í endanlegri vöru, heldur því að skerða þróunarferlið sjálft (árásir á birgðakeðju, venjulega miða að því að kynna skaðlegar breytingar á því að skrifa kóða, skipta út dreifðum íhlutum og ósjálfstæði).
Ramminn tekur mið af 8 tegundum árása sem tengjast hótuninni um að gera skaðlegar breytingar á stigi kóðaþróunar, samsetningar, prófunar og dreifingar vörunnar.
- A. Þar á meðal breytingar á frumkóðanum sem innihalda bakdyr eða faldar villur sem leiða til veikleika.
Dæmi um árás: „Hræsni skuldbindingar“ - tilraun til að kynna plástra með varnarleysi inn í Linux kjarnann.
Öryggisaðferð sem mælt er með: óháð endurskoðun tveggja þróunaraðila á hverri breytingu.
- B. Málamiðlun á frumkóðastýringarvettvangi.
Dæmi um árás: innspýting skaðlegra skuldbindinga með bakdyrum inn í Git geymslu PHP verkefnis eftir að lykilorðum þróunaraðila var lekið.
Tillaga að verndaraðferð: Aukið öryggi kóðastjórnunarvettvangsins (í tilviki PHP var árásin gerð í gegnum lítið notað HTTPS viðmót, sem gerði kleift að senda breytingar við innskráningu með lykilorði án þess að athuga SSH lykilinn, þrátt fyrir sú staðreynd að óáreiðanlegur MD5 var notaður til að hassa lykilorð).
- C. Gera breytingar á stigi flutnings kóða yfir í byggingu eða samfellda samþættingarkerfi (kóði sem passar ekki við kóðann úr geymslunni er byggður).
Dæmi um árás: Að sprauta bakdyrum inn í Webmin með því að gera breytingar á byggingarinnviðum, sem leiðir til notkunar á kóðaskrám sem eru frábrugðnar skránum í geymslunni.
Fyrirhuguð verndaraðferð: Athugun á heilleika og auðkenning á uppruna kóðans á samsetningarþjóninum.
- D. Málamiðlun samsetningarvettvangsins.
Dæmi um árás: SolarWinds árásin, þar sem uppsetning bakdyra inn í SolarWinds Orion vöruna var tryggð á samsetningarstigi.
Fyrirhuguð verndaraðferð: innleiðing háþróaðra öryggisráðstafana fyrir samsetningarvettvanginn.
- E. Kynning á skaðlegum kóða með lággæða ósjálfstæði.
Dæmi um árás: innleiðing bakdyra í vinsæla atburðarstraumsafnið með því að bæta við skaðlausri ósjálfstæði og setja síðan skaðlegan kóða inn í eina af uppfærslum þessarar ósjálfstæðis (hin illgjarn breyting endurspeglaðist ekki í git geymslunni, en var aðeins til staðar í fullunnum MNP pakkanum).
Tillaga að verndaraðferð: beita endurkvæmt SLSA kröfum á allar ósjálfstæðir (ef um atburðastreymi er að ræða, myndi athugun leiða í ljós samsetningu kóða sem samsvarar ekki innihaldi aðal Git geymslunnar).
- F. Hlaða upp gripum sem ekki eru búnir til í CI/CD kerfinu.
Dæmi um árás: að bæta skaðlegum kóða við CodeCov forskriftina, sem gerði árásarmönnum kleift að vinna út upplýsingar sem geymdar eru í samfelldu samþættingarkerfi viðskiptavina.
Fyrirhuguð verndaraðferð: stjórn á uppruna og heilleika gripa (í tilviki CodeCov gæti komið í ljós að Bash Uploader handritið sem sent er frá codecov.io vefsíðunni samsvarar ekki kóðanum úr verkefnageymslunni).
- G. Málamiðlun pakkageymslunnar.
Dæmi um árás: Rannsakendur gátu sett upp spegla af nokkrum vinsælum pakkageymslum til að dreifa illgjarnum pakka í gegnum þær.
Tillaga að verndaraðferð: Staðfesting á því að dreifðu gripirnir séu settir saman úr uppgefnu frumkóðanum.
- H. Að rugla notandanum til að setja upp rangan pakka.
Dæmi um árás: Notkun prentvilla (NPM, RubyGems, PyPI) til að setja pakka í geymslur sem eru svipaðar skriflega og vinsæl forrit (til dæmis kaffi-skrift í stað kaffi-skrift).
Til að koma í veg fyrir merktar hótanir, býður SLSA upp á ráðleggingar, auk verkfæra til að gera sjálfvirka gerð endurskoðunarlýsigagna. SLSA tekur saman algengar árásaraðferðir og kynnir hugmyndina um öryggislög. Hvert stig setur ákveðnar kröfur um innviði til að tryggja heilleika gripanna sem notaðir eru við þróun. Því hærra sem studd SLSA stigið er, því meiri vernd er innleidd og því betra er innviði varið gegn algengum árásum.
- SLSA 1 krefst þess að smíðaferlið sé að fullu sjálfvirkt og framleiði lýsigögn („uppruni“) um hvernig gripir eru smíðaðir, þar á meðal upplýsingar um heimildir, ósjálfstæði og smíðaferlið (dæmi um lýsigagnarafall fyrir endurskoðun er veitt fyrir GitHub Actions). SLSA 1 inniheldur ekki þætti verndar gegn skaðlegum breytingum, heldur auðkennir einfaldlega kóða og veitir lýsigögn fyrir varnarleysisstjórnun og áhættugreiningu.
- SLSA 2 - stækkar fyrsta stigið með því að krefjast notkunar á útgáfustýringu og samsetningarþjónustu sem býr til staðfest lýsigögn. Notkun SLSA 2 gerir þér kleift að rekja uppruna kóðans og kemur í veg fyrir óviðkomandi breytingar á kóðanum ef um er að ræða trausta byggingarþjónustu.
- SLSA 3 - staðfestir að frumkóði og byggingarvettvangur uppfylli kröfur staðla sem tryggja getu til að endurskoða kóðann og tryggja heilleika lýsigagnanna sem veitt eru. Gert er ráð fyrir að endurskoðendur geti vottað vettvang gegn kröfum staðlanna.
- SLSA 4 er hæsta stigið og bætir við fyrri stigin með eftirfarandi kröfum:
- Lögboðin endurskoðun á öllum breytingum af tveimur mismunandi hönnuðum.
- Öll byggingarskref, kóða og ósjálfstæði verða að vera að fullu lýst yfir, öll ósjálfstæði verða að vera sérstaklega dregin út og staðfest og smíðaferlið verður að fara fram án nettengingar.
- Með því að nota endurtekið byggingarferli geturðu endurtekið byggingarferlið sjálfur og tryggt að keyrslan sé byggð upp úr frumkóðanum sem gefinn er upp.
Heimild: opennet.ru