Ez a blog aSupply Chain : a támadók által kihasznált gyenge láncszemek” című webináriumunk legfontosabb tanulságait ismerteti. A teljes webinárium itt tekinthető meg.
Software lánc kockázatai drámaian megnőttek, mivel a szervezetek egyre inkább támaszkodnak nyílt forráskódú komponensekre, külső csomagokra és automatizált fejlesztési folyamatokra. Az egykor ártalmatlannak tűnő apró rések ma már komoly következményekkel járnak, különösen mivel a függőségek egyre mélyülnek és nehezebb ellenőrizni őket.
Ennek a változásnak egyértelmű példája volt a közelmúltban felbukkant npm Shai-Hulud féreg és a Shai-Hulud 2.0, amelyek kompromittált csomagokon keresztül terjedtek, és néhány óra alatt több ezer downstream projektet érintettek. Az ilyen események egyértelművé teszik, hogy a szállítási lánc gyengeségei már nem maradnak korlátozott hatókörűek, hanem az egész ökoszisztémára kihatnak.
A modern szoftverek 70–90%-a nyílt forráskódú komponensekből áll, amelyek többségét a fejlesztők soha nem látják közvetlenül, így a kisebb problémák gyorsan nagy kockázatokká válhatnak. Ugyanakkor a szervezetek mindössze 15%-a érzi magát magabiztosnak a nyílt forráskódú kockázatok kezelésében. Mivel 2025-re a rosszindulatú AI-támadások 70%-a várhatóan az ellátási láncokat fogja célba venni, elengedhetetlenül fontosá vált a szoftverellátási lánc gyenge pontjainak azonosítása.
A mérnöki és biztonsági csapatok számára az előny egyszerű: ha tudják, hol vannak ezek a gyenge pontok, kevesebb meglepetés éri őket, gyorsabban tudnak reagálni, és sokkal kisebb az esélye annak, hogy a következő ellátási lánc-botrány főszereplőivé válnak.
Az SBOM-ok már nem opcionálisak
A szoftverellátási lánc kockázatainak kezeléséhez és a sebezhetőségekre való reagáláshoz a szervezeteknek világos képet kell kapniuk a szoftvercsomagjuk tartalmáról. Ennek az átláthatóságnak az alapja az SBOM (szoftver alkatrészlista), amely megteremti a szükséges átláthatóságot a komponensek kockázatainak megértéséhez és a problémák felmerülése esetén a gyors reagáláshoz.
Az SBOM egy alkalmazásban használt összes zárt és nyílt forráskódú komponens, licenc és függőség részletes leltárának tekinthető. Ez a leltár alapvető adatokat szolgáltat a átláthatóság, a megfelelőség és a kockázatkezelés szempontjából.
Ami ma még nem sebezhető vagy rosszindulatú, az holnap könnyen azzá válhat. Mivel a sebezhetőségek folyamatosan kerülnek napvilágra, beleértve a régebbi verziókat is, folyamatos figyelemmel kísérés és leltározás szükséges.
George PrichiciAlelnök, termékek, OPSWAT
SBOM kontra SCA
Fontos megkülönböztetni az SBOM-ot és az SCA-t (Software ). Az SBOM egy leltár, vagyis a komponensek listája. Az SCA pedig értékeli, hogy ezek közül a komponensek közül van-e olyan, amely sebezhető, elavult vagy kockázatos. Együttesen ezek biztosítják a szervezetek számára a tájékozott döntéshozatalhoz, a biztonsági problémákra való gyorsabb reagáláshoz és az általános kockázatkezelés megerősítéséhez szükséges információkat.
| Kategória | SBOM | SCA |
|---|---|---|
Cél | Alkatrészek leltára |
A komponensek sebezhető pontjainak azonosítása
|
Kockázatfedezés | Megfelelés és láthatóság | Biztonsági kockázatok, CVE-k, futási kockázat |
Időzítés | Telepítés előtti / beszerzés | Folyamatos / építés és futásidő |
A SolarWinds-hez hasonló támadások által részben ösztönzött globális mozgalmak ma már SBOM-okat követelnek, és olyan szervezetek, mint a CISA, az NSA és a NIST, valamint az EU és a NATO szövetséges országai szabályozási nyomást gyakorolnak, így az SBOM átláthatósága már nem opcionális, hanem alapvető elvárás minden szoftvergyártó számára.
A támadók által kihasznált 7 kritikus gyenge láncszem
A modern fejlesztések gyors üteme, valamint a harmadik felektől származó és nyílt forráskódú szoftverekre való erős támaszkodás súlyos sebezhetőségeket eredményezett. A fenyegetések szereplői hét fő gyenge pontot használnak ki:
1. Nyílt forráskód és függőségi kockázat
Amikor a fejlesztők a sebességet helyezik előtérbe, gyakran használnak nagy nyílt forráskódú könyvtárakat anélkül, hogy teljes kódellenőrzést végeznének. Egyetlen komponens is további tranzitív függőségeket eredményezhet. Ha csak a legfelső szintet figyeljük, akkor elmulaszthatjuk a rejtett tranzitív függőségekbe beépített rosszindulatú kódot.
Ez a minta az open source ökoszisztémákban folyamatosan megfigyelhető. Egy kompromittált csomag a függőségi láncokon keresztül több millió letöltést eredményezhet, mielőtt bárki is észrevenné. A kriptográfiai rosszindulatú programokat tartalmazó, nemrégiben történt npm ellátási lánc támadás pontosan bemutatja, hogyan történik ez a gyakorlatban.
Legjobb gyakorlatok:
- Vizsgálja meg az összes nyílt forráskódú csomagot és azok teljes függőségi láncait, hogy azonosítsa a sebezhetőségeket, elavult összetevőket vagy rejtett rosszindulatú programokat, mielőtt azok eljutnának a kódbázisába.
- Folyamatosan figyelje a függőségeket az idő múlásával, mivel a biztonságos komponensek kockázatosakká válhatnak, ha új CVE-k vagy rosszindulatú frissítések jelennek meg.
- Használjon megbízható nyilvántartásokat és ellenőrizze a csomagok integritását, hogy megbizonyosodjon arról, hogy a letöltött csomagokat nem manipulálták.
- Alkalmazzon olyan irányelveket, amelyek jelzik vagy blokkolják a kockázatos licenceket, hogy az összeférhetetlen vagy vírusos licencfeltételek ne kerülhessenek be a buildjeibe.
- Halassza el az újonnan közzétett csomagok használatát, amíg azok át nem kerültek ellenőrzésre, így csökkentve annak esélyét, hogy felülvizsgálatlan vagy rosszindulatú kiadások kerüljenek a környezetébe.
2. Engedélyezési kockázat
A licenceléssel kapcsolatos kérdések ma már ugyanolyan mértékben érintik a mérnöki munkát, mint a jogi területet. A vírusos licencelések, mint például a GPL, arra kényszeríthetik Önt, hogy az Ön által kifejlesztett alkalmazást ugyanazon licenc alatt tegye közzé, ami potenciálisan a vállalat saját szellemi tulajdonának (IP) elvesztéséhez vezethet. Folyamatos figyelemmel kísérésre van szükség, mivel a licencfeltételek változhatnak, még a régebbi, korábban megfelelő verziók esetében is.
Legjobb gyakorlatok:
- Használjon automatizált licenckontroll eszközt, hogy a fejlesztés korai szakaszában jelölje meg a kockázatos vagy összeférhetetlen licenceket. Ennek fontosságát részletesebben itt ismertetjük: A licenckontroll döntő szerepe az open source biztonságban.
- Folyamatosan kövesse nyomon a licencváltozásokat, hogy észrevegye azokat a változásokat, amelyek hatással lehetnek a megfelelésre vagy az IP-kockázatra.
- Blokkolja vagy vizsgálja meg a korlátozó vagy vírusos licenccel rendelkező komponenseket, mielőtt azok bekerülnének a kódbázisba.
- Az ellenőrzések és kockázatértékelések egyszerűsítése érdekében tartson naprakész nyilvántartást az összes használatban lévő licencre vonatkozóan.
3. SBOM-adatok hiányosságai vagy hiányzó SBOM-ok
Bár a szabályozás előírja az SBOM-ok megosztását, egy magas szintű lista nem elegendő. A hatékony kockázatcsökkentéshez és megelőzéshez részletes adatokra van szükség, beleértve a szerzőt, a közreműködőket, a kiadás gyakoriságát és a karbantartási állapotot.
Legjobb gyakorlatok:
- Javítsa az SBOM-jelentéseket az alkatrészek újbóli beolvasásával, hogy azok frissített licencadatokkal, sebezhetőségi állapotokkal és egyéb kritikus metaadatokkal gazdagodjanak. Ennek részletes példája itt található: CycloneDX SBOM-jelentés érvényesítése és gazdagítása.
- Az automatizált eszközök segítségével ellenőrizze és bővítse az SBOM-okat, hogy az információk teljesek, pontosak és felhasználhatók legyenek.
- A szállítóktól megkövetelni a teljes SBOM mélység biztosítását, beleértve a tranzitív függőségeket és az összes releváns metaadatot.
- Folyamatosan frissítse és figyelje az SBOM-leltárakat, ahogy a komponensek fejlődnek vagy új sebezhetőségek jelennek meg.
4. Harmadik fél beszállítók
Minden beszállító, akire támaszkodik, az ellátási lánc részévé válik. Ha elavult vagy sérült alkatrészeket szállítanak, akkor Ön is átveszi ezt a kockázatot. A teljes SBOM-ok, beleértve a tranzitív függőségeket is, lehetővé teszik, hogy gyorsan megértsük a kockázatot, ahelyett, hogy incidens esetén a beszállítókat kellene keresni. Supply Chain függőségi sebezhetőségeinek kezeléséről szóló legutóbbi bejegyzésünkben azt vizsgáljuk, hogyan erősíthetik a csapatok a folyamat ezen részét.
5. AI Supply Chain
Az AI gyors elterjedése miatt a csapatok gyakran megkerülik a szokásos korlátozásokat, ami ezt egy jelentős támadási vektorrá teszi. A támadók rosszindulatú kódot juttatnak be a gépi tanulási modellekbe, a PICO fájlokba vagy a nyílt forráskódú könyvtárakba. A typosquatting gyakori olyan környezetekben, mint a Pytorch, ahol a felhasználók rossz könyvtárat tölthetnek le, ami rosszindulatú szoftvert juttathat a rendszerbe, és teljes távoli kódvégrehajtáshoz vezethet a mérnök gépén.
6.Container
A konténerek vizsgálata nem korlátozódhat kizárólag a sebezhetőségek felkutatására. A modern biztonsági rendszereknek a nyilvánosan elérhető konténerképekben megjelenő rosszindulatú programokat, kriptovaluta-bányászokat és gyorsan terjedő fenyegetéseket is fel kell kutatniuk. Az NVIDIA Container CVE-2024-0132 legutóbbi elemzése jól mutatja, milyen könnyen lehet ezeket a problémákat figyelmen kívül hagyni.
7. Titkok és hitelesítő adatok kiszivárogtatása
Amikor a csapatok gyorsan dolgoznak, gyakran a teszteléshez a hozzáférési kulcsokat vagy hitelesítő adatokat kódolják a forráskódba. Még ha később felül is írják őket, ezek a titkos adatok gyakran megmaradnak a Git történetében, ahol a támadók könnyen megtalálhatják őket szkenneléssel. A rejtett fenyegetések leleplezése: Hogyan lehet felismerni a kódban rejlő titkos adatokat című cikk bemutatja, hogyan történik ez a kitettség, és mit tehetnek a csapatok annak megelőzésére.
A Secure Supply Chain felé vezető út
Ezeknek a fenyegetéseknek a leküzdése érdekében a biztonsági szakembereknek „shift left” szemléletmódot kell alkalmazniuk, vagyis a kiadás előtt érvényesített szabályokat már a fejlesztési ciklus korábbi szakaszában kell alkalmazni. A cél az, hogy a biztonságot a meglévő CI/CD folyamatra építsék rá. Ez az automatizált megközelítés biztosítja a szabályok érvényesítését, amikor az szükséges, anélkül, hogy ez hatással lenne a mérnöki termelékenységre.
Egy átfogó megoldásnak a következőket kell biztosítania:
- Automatizált ellátási lánc-ellenőrzés a teljes folyamat során
- A forráskód, a konténerek és a gyártók által biztosított fájlok láthatósága
- A CVE-ken túlmutató elemzés a rosszindulatú szoftverek, licencproblémák és nyilvánosságra hozott titkok felderítésére
Hogyan OPSWAT ezeknek a hiányosságoknak a megszüntetésében?
- Multiscanning a rosszindulatú szoftverek korai felMultiscanning
- Integrált CI/CD biztonsági kapuk GitHub, GitLab, TeamCity, Jenkins és mások számára
- Automatizált SBOM-generálás és sebezhetőségi térképészet
- Műtárgyak aláírása és integritásának ellenőrzése
- Titkok szkennelése és hitelesítő adatok tisztasága
Beszéljen szakértőinkkel, hogy még ma megtalálja a stackjéhez leginkább megfelelő megoldásokat.
