Bevezetés az OSS Rebuild-be: Nyílt forráskód, felépítve tartós működésre

Publikált Matthew Suozzo, Google Open Source Security Team (GOSST) Ma örömmel jelentjük meg az OSS Rebuild-et, egy új projektet, amely az nyílt forrású csomagok ökoszisztémájának bizalmatosságának megerősítésére szolgál, az upstream anyagok reprodukálásával. Ahogy a ellátási lánc-kockázatok továbbra is a széles körben használt függőségeket célozzák, az OSS Rebuild biztonsági csapatok számára nagy teljesítményű adatokat biztosít, hogy elkerüljék a veszélyt, anélkül, hogy az upstream-fenntartók terhelődjenek. A projekt magában foglalja: Automatikus meghatározások deriválását a meglévő PyPI (Python), npm (JS/TS) és Crates.io (Rust) csomagokhoz. SLSA Provenance-t több ezer csomaghoz az általunk támogatott ökoszisztémákban, amely az SLSA Build Level 3 követelményeit teljesíti, anélkül, hogy a kiadóknak intervenne. A biztonsági csapatok számára integrálható építési megfigyelési és ellenőrző eszközök. Az infrastruktúra meghatározása, amely lehetővé teszi a szervezetek számára, hogy könnyen üzembe helyezzék a saját OSS Rebuild példányaikat, hogy újraépítsék, generálják, aláírják és terjeszték a nyílt forrású anyagokat. Kihívások Az nyílt forrású szoftver a digitális világ alapjává vált. A kritikus infrastruktusztól az napi használatú alkalmazásokig, az OSS komponensek most 77%-át teszik ki a modern alkalmazásoknak. A becsült érték meghaladja a 12 trilliót, az nyílt forrású szoftver a globális gazdaságban soha nem volt ennyire integrálva. Ugyanakkor ez a széles körű elterjedtség is vonzza a kockázatot: A korábbi nagyrahangolt ellátási lánc-kockázatok bizonyították a széles körben használt csomagok veszélyeztetésének kifinomult módszereit. Minden incidens erózióba hajt a bizalmat az nyílt ökoszisztémákban, ami bizonytalanságot teremt a fejlesztők és felhasználók között. A biztonsági közösség erre azzal reagált, hogy kezdeményezéseket indított, mint például az OpenSSF Scorecard, a pypi Trusted Publishers és az npm SLSA támogatása. Ugyanakkor nincs panacea: Minden erőfeszítés egy bizonyos aspektust célozza meg, gyakran kompromisszokkal, például a munkát a kiadóknak és fenntartóknak átadva. A célunk Az OSS Rebuild-ben az, hogy a biztonsági közösséget arra bátorítsuk, hogy mélyen megértse és ellenőrizze a saját ellátási láncait, azzal, hogy a csomagok fogyasztásának átláthatóságát megteremtsük, hasonlóan a forrás-tároló használatához. A rebuild platformunk ezt a nyitottságot megvalósítja a deklaratív építési folyam, az építési megfigyelési és a hálózati monitorozási képességeivel, amelyek az SLSA Build framework-ben részletes, tartós és megbízható biztonsági metadatot hoznak létre. Az OSS Fuzz-hoz, amely a memóriában lévő problémák detektálására szolgál, a hostolt infrastruktúra-modellt bevezetve, az OSS Rebuild hasonlóan a hostolt erőforrásokat használja a nyílt forrású biztonság problémáinak megoldására, most az nyílt forrású szoftver ellátási láncának biztonságára. A látomásunk túllépi a egyetlen ökoszisztémát: Elkötelezettek vagyunk a nyílt forrású szoftver teljes ellátási láncának átláthatóságának és biztonságának megteremtésére. A PyPI (Python), npm (JS/TS) és Crates.io (Rust) csomag-regisztrációkhoz való kezdeti támogatás, amely a legnépszerűbb csomagok többek között, csak a kezdet, a mi utazásunk. Hogyan működik az OSS Rebuild Az automatizáció és a heurisztikák segítségével meghatározunk egy potenciális build-meghatározást a célcsomaghoz, majd újraépítjük. Szemantikus módon összehasonlítjuk az eredményt a meglévő upstream-anyaggal, normalizálva mindkettőt, hogy eltávolítsuk a stabilitást, ami megakadályozza a bit-for-bit összehasonlítások sikertelenségét (pl. archív kompresszálás). Miután az anyagot reprodukáltuk, megpublikáljuk a build-meghatározást és az eredményt az SLSA Provenance-n keresztül. Ez az igazolás lehetővé teszi a felhasználók számára, hogy megbízhatóan ellenőrizzék egy csomag eredetét a forrás-történetben, megértik és ismétlik meg a build-folyamát, és testre szabhatják a build-et egy ismert működő állapotból (vagy akár még részletesebb SBOM-okat generálhatják). Az OSS Rebuild-hez, amely a PyPI, npm és Crates.io-hoz, automatizálva, a legtöbb csomag biztonságban van, anélkül, hogy felhasználó vagy fenntartó beavatkozást igényelné. Ahhoz, hogy az automatizáció teljes körűen nem reprodukálja az anyagot, manuális build-meghatározást nyújt, hogy az egész közösség a szubjektív hozzájárulásokból profitálhasson. Emellett izgatottak vagyunk attól, hogy az AI segíthet az anyagok reprodukálásában: A build és a kiadás folyamait gyakran leírják természetes nyelvi dokumentációban, amely, bár nehéz a diszkrét logika használatával, egyre hasznosabb a nyelvi modellek számára. Az eddigi kísérleteink bizonyították, hogy az megvalósítható a felfedezés és a tesztelés automatizálásában, a minimális emberi beavatkozással, még a legkomplexebb build-ek esetén is. A képességeink Az OSS Rebuild több típusú ellátási lánc-kockázatot detektál: Nem publikált forráskód - Ha a publikált csomagok kódja nem található a nyilvános forrás-tárolóban, az OSS Rebuild nem igazolja az anyagot. Valós életű támadás: solana/webjs (2024 Build Környezet-kockázat - A szabványos, minimális build-környezetek létrehozásával, amely aletes a végig monitorozást, az OSS Rebuild képes észrevenni a gyanús build-aktivitást, vagy teljesen elkerülni a sérült komponensekhez való hozzáférést. Valós életű támadás: tj-actions/changed-files (2025 Stealthy Backdoors - A kifinomult backdoor-ok, például az xz gyakran mutatnak szokatlan viselkedési mintákat a build-ek során. Az OSS Rebuild dinamikus elemzői képességei képesek észrevenni a megszokottól eltérő futtatási útvonalakat vagy gyanús műveleteket, amelyeket a manuális ellenőrzés során nehéz észrevenni. Valós életű támadás: xz-utils (2024) Az OSS Rebuild a vállalkozások és a biztonsági szakemberek számára: Megemelt metadatok, anélkül, hogy a regisztrációkat kellene megváltoztatni, a meglévő csomagokhoz adatokkal gazdagítva. Nincs szükség a saját regisztrációkra vagy a új csomag-ökoszisztémára. Megemelt SBOM-ok, a részletes build-megfigyelési információkkal, a meglévő szoftver-termelési anyagokhoz, egy teljesebb biztonsági képet. A gyorsabb válasz a kockázatokra, a vendor-hez, a patch-hez és a upstream csomagok újbontásához, azáltal, hogy a megbízható build-meghatározásunkon alapulhatunk. A kiadók és a fenntartók számára az OSS Rebuild: Erősíti a csomagok bizalmát, biztosítva, hogy a felhasználók, független módon, ellenőrizzék a csomagok build-bizalmat, függetlenül a eredeti build-képzettség. A meglévő csomagok build-igazolásait, magas minőségűvé téve, a publikáláskor, még ha a build-igazolások nem is voltak, vagy nem is voltak támogatva. Csökkenti a CI-biztonsági érzékenységet, lehetővé téve, hogy a kiadók a keret-fejlesztési munkán koncentrálhassanak. A CI-platformok komplex engedélyezési és végrehajtási modelleket használnak, és a külön, az upstream csomagok biztonságát biztosítva, a CI-környezet nem kelljen a csomagok biztonságát biztosítson. Próbálja ki! A legkönnyebb (de nem egyetlen) módja az OSS Rebuild igazolásainak megtekintéséhez, a Go-alapú, parancssori felület használata. Ezt könnyen lehet telepíteni: $ go install github.com/google/oss-rebuild/cmd/oss-rebuild@latest. Megtudhatod az SLSA Provenance-t: $ oss-rebuild get cratesio syn 2.0.39 ..vagy fedezd fel egy adott csomag újbontásait: $ oss-rebuild list pypi absl-py ..vagy építs újra a saját csomagot: $ oss-rebuild get npm lodash 4.17.20 –output=dockerfile | docker run $(docker buildx build -q -)Csatlakozz hozzánk, hogy a nyílt forrású szoftver biztonságát segítünk. Az OSS Rebuild nem csak a problémák kijavításáról szól, hanem a nyílt forrású ökoszisztémák átláthatóságának és biztonságának megteremtéséről szól. Ha fejlesztő, vállalkozás vagy biztonsági kutató, akkor örömmel fogunk együttműködni. Kövesd, oszd meg az ötleteidet és ad meg visszajelzéseket a github.com/google/oss-rebuild címen. Fedezd fel az adatokat és járulj hozzá a támogatásodhoz, hogy a kritikus ökoszisztémáid és csomagjaidat biztonságosabbá tegyed. Tanulj a SLSA Provenance-ről a slsa.dev oldalon.