A Google bevezette az SLSA (Supply-chain Levels for Software Artifacts) keretrendszert, amely összefoglalja a fejlesztői infrastruktúra védelmében meglévő tapasztalatokat a kódírás, a tesztelés, az összeállítás és a termék terjesztése során végrehajtott támadásokkal szemben.
A fejlesztési folyamatok egyre összetettebbé válnak, és külső eszközöktől függenek, ami kedvező feltételeket teremt a támadások előretöréséhez, amelyek nem a végtermék sebezhetőségeinek feltárásával és kihasználásával, hanem magának a fejlesztési folyamatnak a veszélyeztetésével kapcsolatosak (ellátási lánc támadások, amelyek általában a rosszindulatú változtatások bevezetése a kódírás folyamatában, az elosztott összetevők és függőségek helyettesítése).
A keretrendszer 8 fajta támadást vesz figyelembe, amelyek a rosszindulatú változtatások veszélyével kapcsolatosak a termék kódfejlesztésének, összeállításának, tesztelésének és terjesztésének szakaszában.
- V. Beleértve a forráskód olyan módosításait, amelyek biztonsági résekhez vezető hátsó ajtókat vagy rejtett hibákat tartalmaznak.
Példa támadásra: „Hypocrite Commits” – kísérlet a Linux kernel sebezhető pontjainak javítására.
Javasolt biztonsági módszer: minden változtatás független felülvizsgálata két fejlesztő által.
- B. A forráskód-vezérlő platform kompromisszuma.
Példa támadásra: rosszindulatú commitok bejuttatása egy hátsó ajtóval egy PHP-projekt Git-tárházába, miután fejlesztői jelszavak kiszivárogtak.
Javasolt védelmi mód: A kódkezelő platform fokozottabb biztonsága (a PHP esetében a támadást egy keveset használt HTTPS interfészen keresztül hajtották végre, amely lehetővé tette a változtatások elküldését jelszóval történő bejelentkezéskor az SSH kulcs ellenőrzése nélkül az a tény, hogy a megbízhatatlan MD5-öt használták a jelszavak kivonatára).
- C. Változások végrehajtása a kód átvitelének szakaszában a build-be vagy a folyamatos integrációs rendszerbe (amely nem egyezik a tárolóból származó kóddal).
Példa támadásra: Hátsó ajtó beillesztése a Webminbe az összeépítési infrastruktúra módosításával, ami a lerakatban lévő fájloktól eltérő kódfájlok használatát eredményezi.
Javasolt védelmi módszer: Az integritás ellenőrzése és a kód forrásának azonosítása az összeállítási szerveren.
- D. Az összeszerelő platform kompromisszuma.
Példa támadásra: a SolarWinds támadás, melynek során az összeszerelési szakaszban biztosították egy hátsó ajtó telepítését a SolarWinds Orion termékbe.
Javasolt védelmi módszer: fejlett biztonsági intézkedések bevezetése az összeszerelő platformon.
- E. Rosszindulatú kódok népszerűsítése alacsony minőségű függőségek révén.
Példa egy támadásra: egy hátsó ajtó bevezetése a népszerű eseményfolyam-könyvtárba egy ártalmatlan függőség hozzáadásával, majd rosszindulatú kód beillesztésével a függőség egyik frissítésébe (a rosszindulatú változás nem tükröződött a git tárolóban, de csak a kész MNP-csomagban van jelen).
Javasolt védelmi módszer: rekurzív módon alkalmazza az SLSA-követelményeket minden függőségre (eseményfolyam esetén az ellenőrzés feltárja a kód összeállítását, amely nem felel meg a fő Git-tár tartalmának).
- F. Nem a CI/CD rendszerben létrehozott műtermékek feltöltése.
Példa támadásra: rosszindulatú kód hozzáadása a CodeCov szkripthez, amely lehetővé tette a támadók számára, hogy kivonják az ügyfelek folyamatos integrációs rendszerkörnyezetében tárolt információkat.
Javasolt védelmi módszer: a műtermékek forrásának és integritásának ellenőrzése (a CodeCov esetében kiderülhet, hogy a codecov.io webhelyről küldött Bash Uploader szkript nem egyezik a projekttárból származó kóddal).
- G. A csomagtároló kompromittálása.
Példa támadásra: A kutatók képesek voltak néhány népszerű csomagtároló tükrét telepíteni, hogy rosszindulatú csomagokat terjeszthessenek rajtuk.
Javasolt védelmi módszer: Annak ellenőrzése, hogy az elosztott melléktermékek a deklarált forráskódokból állnak-e össze.
- H. A felhasználó megzavarása a rossz csomag telepítésével.
Példa támadásra: typosquatting (NPM, RubyGems, PyPI) használata olyan csomagok tárolására, amelyek írása hasonló a népszerű alkalmazásokhoz (például coffe-script a coffee-script helyett).
A megjelölt fenyegetések blokkolásához az SLSA egy sor ajánlást, valamint a megfigyelési metaadatok létrehozásának automatizálására szolgáló eszközöket kínál. Az SLSA összefoglalja a gyakori támadási módszereket, és bevezeti a biztonsági rétegek fogalmát. Mindegyik szint bizonyos infrastrukturális követelményeket ír elő a fejlesztés során használt műtermékek integritásának biztosítása érdekében. Minél magasabb a támogatott SLSA-szint, annál több védelmet valósítanak meg, és annál jobban védett az infrastruktúra a gyakori támadásokkal szemben.
- Az SLSA 1 megköveteli, hogy az összeállítási folyamat teljesen automatizált legyen, és metaadatokat („eredetet”) állítson elő a műtermékek felépítéséről, beleértve a forrásokra, a függőségekre és az összeállítási folyamatra vonatkozó információkat (a GitHub-műveletekhez egy példa metaadat-generátor áll rendelkezésre az auditáláshoz). Az SLSA 1 nem tartalmazza a rosszindulatú módosítások elleni védelem elemeit, hanem egyszerűen azonosítja a kódot, és metaadatokat biztosít a sebezhetőség kezeléséhez és a kockázatelemzéshez.
- SLSA 2 – kiterjeszti az első szintet azáltal, hogy megköveteli a hitelesített metaadatokat generáló verziófelügyeleti és összeállítási szolgáltatások használatát. Az SLSA 2 használata lehetővé teszi a kód eredetének nyomon követését, és megbízható build szolgáltatások esetén megakadályozza a kód jogosulatlan módosításait.
- SLSA 3 – megerősíti, hogy a forráskód és az összeállítási platform megfelel a szabványok követelményeinek, amelyek garantálják a kód auditálását és a szolgáltatott metaadatok integritását. Feltételezzük, hogy az auditorok tanúsíthatják a platformokat a szabványok követelményei szerint.
- Az SLSA 4 a legmagasabb szint, amely kiegészíti a korábbi szinteket a következő követelményekkel:
- Az összes módosítás kötelező felülvizsgálata két különböző fejlesztő által.
- Minden felépítési lépést, kódot és függőséget teljesen deklarálni kell, minden függőséget külön kell kibontani és ellenőrizni, és az összeállítási folyamatot offline kell végrehajtani.
- Az ismételhető összeállítási folyamat használatával megismételheti az összeállítási folyamatot, és gondoskodhat arról, hogy a végrehajtható fájl a megadott forráskódból épüljön fel.
Forrás: opennet.ru