A fejlesztők a hatékonyság és az időmegtakarítás érdekében rendszeresen használnak harmadik féltől származó kódot alkalmazásaik elkészítéséhez. Ez a külső komponensekre, különösen a nyílt forráskódú szoftverekre (OSS) való támaszkodás azonban jelentős kockázatokat rejt magában, beleértve a sebezhetőségeket és a licencelési problémákat. A GitHub 2023-as felmérése szerint a fejlesztők 31%-a tartja a második legfontosabb feladatának a biztonsági sebezhetőségek megtalálását és javítását, közvetlenül a kódírás után (32%).
Következésképpen sok szervezet aggódik az OSS-re való támaszkodás miatt, mivel az gyakran a hackerek célpontja. A szervezeteknek kihívást jelent a szoftverellátási láncban megnövekedett sebezhetőség, valamint annak megértése, hogy a közelmúltban elkövetett, nagy nyilvánosságot kapott támadások nyomán hogyan lehet hatékonyan csökkenteni a kockázatot.
Az ESG kutatási jelentéséből kiderül, hogy a szervezetek 91%-a tapasztalt szoftverellátási láncbeli incidenst az elmúlt 12 hónapban. A leggyakoribb incidensek közé tartoznak:
Az olyan kiemelkedő sebezhetőségek, mint a Log4J, a Curl, az Apache Struts és az OpenSSL, mind számos működési károkat okoztak. Ezek rávilágítanak arra, hogy milyen súlyos hatással jár a szervezetekre, ha a szoftverellátási lánc egyetlen gyenge pontját kihasználják. Ezekre a növekvő kockázatokra válaszul a szabályozó szervek világszerte hangsúlyt fektetnek a szoftverek átláthatóságára és biztonságára. Az elfogadás egy Software Bill of Materials (SBOM) a szoftverellátási lánc kockázatainak kezelésében kulcsfontosságú stratégiává válik.
Az SBOM-rendeletek lendületet kapnak
Az SBOM-szabályozások egyre szélesebb körben elterjedtek. Számos kormány tett közzé ajánlásokat az SBOM végrehajtására vonatkozóan. Az Egyesült Államokban az SBOM-ajánlásokat számos kormányzati iránymutatás tartalmazza, többek között:
2023-ban a CISA három kulcsfontosságú dokumentumot adott ki az SBOM elfogadásának előmozdítása érdekében. Ezek az SBOM használatának kiterjesztésére, az új technológiák és alkalmazások feltárására, valamint a közösségi együttműködés előmozdítására összpontosítottak.
Európában az EU Kiberbiztonsági Ügynöksége (ENISA) közzétette az "Irányelvek a tárgyak internetének Supply Chain biztosításához" című dokumentumot, amely értékes betekintést nyújt a szervezeteknek a kiberbiztonság javításához és a szoftverekkel kapcsolatos ellátási lánc kockázatainak kezeléséhez.
Más országok is kiadtak hasonló iránymutatásokat, többek között:
Azt tanácsolja a szervezeteknek, hogy használják a SBOM-okat az általuk használt szoftverkomponensekkel kapcsolatos kockázatok felmérésére, valamint az említett komponensek sebezhetőségének azonosítására és kezelésére.
Az "Információbiztonsági kézikönyv: Guidelines for Software Development" (Iránymutatások a Software ) című dokumentumban az ACSC azt javasolja, hogy az SBOM-okat használják a kiberellátási lánc átláthatóságának fokozására, megkönnyítve az alkalmazásokban használt egyes szoftverkomponensekhez kapcsolódó biztonsági kockázatok azonosítását és kezelését.
Hogyan teszi szükségessé a PCI DSS az SBOM generálását?
Felismerve a fizetési kártyák adatait érintő növekvő kockázatokat, a Payment Card Industry Data Security Standard (PCI DSS) a SBOM bevezetésének egyik hajtóerejévé vált. A legújabb verzió, a PCI DSS 4.0 előírja az SBOM-ok használatát, kiemelve azok kritikus szerepét az érzékeny adatok védelmében. A szoftverkomponensek részletes leltárának biztosításával az SBOM-ok lehetővé teszik a szervezetek számára a sebezhetőségek proaktív azonosítását és kezelését, csökkentve ezzel a költséges adatszegések és pénzügyi veszteségek kockázatát.
A 2004-ben létrehozott PCI DSS egy átfogó biztonsági szabvány, amelyet a hitelkártyaadatok védelmére terveztek. A hitelkártya-tranzakciókat kezelő vállalkozások számára szigorú követelményeket határoz meg, az évente feldolgozott tranzakciók mennyiségéhez igazodva. A PCI DSS v4.0 2022-es kiadása jelentős változásokat vezetett be, beleértve a SBOM-felhatalmazást is, a fejlődő fenyegetések kezelése érdekében. A PCI DSS v4.0-nak való megfelelés 2024 áprilisáig kötelező, a konkrét követelményeket 2025. március 31-ig fokozatosan vezetik be.
Forrás: PCI DSS V4.0 at a Glance
Az SBOM-ok kötelezővé tételével a PCI DSS lehetővé teszi a szervezetek számára, hogy átfogó képet kapjanak szoftveres ökoszisztémájukról, és így proaktívan azonosíthassák és kezelhessék a sebezhetőségeket. Ez a megközelítés jelentősen csökkenti a költséges adatszegések és pénzügyi veszteségek kockázatát.
A PCI DSS újabb, 4.0.1-es verziója 24 közepén jelent meg. Ez azt jelenti, hogy a korábbi, 4.0-s verzió 2024. december 31. után már nem lesz érvényes. Az új verzió azonban nem ad hozzá vagy töröl el szabályokat, és nem változtatja meg a határidőket. Ezért az SBOM-követelményekre vonatkozó információk ebben a blogban a 4.0 és a 4.0.1 verzióra egyaránt vonatkoznak.
A PCI DSS 6.3.2. követelményének való megfelelés
A PCI DSS v4.0-ban szereplő SBOM-követelmény a PCI DSS legutóbbi kiadásában a PCI DSS szélesebb körű fejlesztésének része. A 4.0 verzióban hozzáadott 64 új követelmény részeként bevezetett SBOM-követelmény kifejezetten arra vonatkozik, hogy a szervezeteknek leltárt kell vezetniük a szoftverkomponensekről, különös tekintettel a testreszabott és egyedi szoftverekre.
Ez a követelmény a PCI DSS 6. követelménye alá tartozik, amely előírja a biztonságos rendszerek és alkalmazások létrehozását és fenntartását erős biztonsági intézkedések bevezetésével, valamint a sebezhetőségi értékelések és frissítések rendszeres elvégzésével. Ez a követelmény alapvető fontosságú a szoftverek sebezhetőségéből eredő kockázatok csökkentése és a kártyabirtokosok adatainak védelme szempontjából. A 6. szakasz öt fő területet fed le:
- 6.1 A biztonságos rendszerek és szoftverek fejlesztésére és karbantartására szolgáló folyamatok és mechanizmusok meghatározása és megértése.
- 6.2 A testreszabott és egyedi szoftverek fejlesztése biztonságosan történik.
- 6.3 A biztonsági réseket azonosítják és kezelik.
- 6.4 A nyilvános webes alkalmazások védve vannak a támadások ellen.
- 6.5 Az összes rendszerösszetevőt érintő változtatásokat biztonságosan kezelik.
Konkrétabban, a 6.3.2. követelmény egy fontos frissítés, amely több olyan jogsértésből adódott, amikor a harmadik féltől származó komponensek sebezhetőségei vagy a harmadik féltől származó komponensek szolgáltatóinak sérülései a kártyabirtokosok adatainak veszélyeztetéséhez vezettek. A követelmény a következőképpen szól:
6.3.2.b Vizsgálja meg a szoftverdokumentációt, beleértve a harmadik féltől származó szoftverkomponenseket integráló egyedi és testreszabott szoftvereket is, és hasonlítsa össze a leltárral annak ellenőrzése érdekében, hogy a leltár tartalmazza-e az egyedi és testreszabott szoftvereket és a harmadik féltől származó szoftverkomponenseket.
A szervezeteknek alaposan dokumentálniuk és kezelniük kell az alkalmazásaikban használt egyedi komponenseket és szolgáltatásokat. Míg ezen információk egy részét eddig is lefedték az adatáramlási diagramok, az új követelmények sokkal részletesebb dokumentációt követelnek meg. Ezeknek a részleteknek a nyomon követése kihívást jelenthet, mivel az összetevők frissülnek és változnak. Célszerű egy szabványos sablont használni ezen információk rögzítésére. Emellett egyes forráskód-tárházak, például a GIT, kínálhatnak olyan eszközöket, amelyekkel exportálható a használatban lévő komponensek listája. A leltárnak legalább a következőket kell tartalmaznia:
- Alkalmazáskomponensek (jellemzően tárolási projektek)
- Harmadik féltől származó összetevők listája
- Az alkalmazásfüggőségek listája (pl. Tomcat, Jboss, .NET, Middleware)
- Az engedélyezett fizetési oldal szkriptek listája
Hogyan segíthet az OPSWAT SBOM a PCI DSS követelményeinek teljesítésében?
A szabályozás egyre inkább megköveteli az SBOM-ok alkalmazását a szoftverellátási lánc biztonságának biztosítása érdekében. A szervezetek azonban nehezen tudnak pontos leltárt készíteni szoftverkódjaik összetételéről.
Forrás: EGS Report 2024
A pontos és átfogó SBOM-ok létrehozása azonban jelentős kihívást jelent a szervezetek számára. Ezek a dokumentumok megkövetelik a szoftverkomponensek aprólékos leltározását, ami részletes információkat igényel azok eredetéről, verzióiról és kölcsönös függőségeiről. Pontos SBOM-ok nélkül a szervezetek nehezen tudják hatékonyan azonosítani, értékelni és csökkenteni a szoftverellátási láncukban rejlő kockázatokat.
Iránymutatások az SBOM-ok létrehozásához
OPSWAT Az SBOM automatizálja az SBOM-ok létrehozását mind a kód, mind a konténerek esetében, növelve a biztonságot és segítve a szoftverellátási láncban a jogszabályi megfelelőséget.
- Minden komponens és függőség azonosítása
Azonosítsa pontosan az összes szoftverkomponenst, beleértve a nyílt forráskódú és a harmadik féltől származó könyvtárakat, valamint azok verzióit és függőségeit. Ez képezi a megbízható SBOM alapját. - OSS kockázatok értékelése
Értékelje az OSS-összetevőkkel kapcsolatos potenciális kockázatokat. Vegye figyelembe az olyan tényezőket, mint a licenceknek való megfelelés, a biztonsági sebezhetőségek és a karbantartási állapot. A komponensek rangsorolása a szoftver szempontjából kritikus fontosságuk alapján. - OSS sebezhetőségek keresése
Használja a sebezhetőségi vizsgálatot és a SBOM-generáló eszközöket az OSS-összetevők ismert sebezhetőségeinek azonosítására. A sebezhetőségek rangsorolása a súlyosságuk és a szoftverre gyakorolt potenciális hatásuk alapján.
az OPSWAT SBOM használata
OPSWAT Az SBOM automatizálja az SBOM-ok létrehozását mind a kód, mind a konténerek esetében, növelve a biztonságot és segítve a szoftverellátási láncban a jogszabályi megfelelőséget.
Íme, hogyan használhatja az OPSWAT SBOM-ot az SBOM-ok hatékony létrehozásához:
az OPSWAT SBOM az alkalmazáson belül használt összes nyílt forráskódú könyvtár és komponens leltárának biztosításával segít a függőségi sebezhetőségek kezelésében a szoftverellátási láncban, lehetővé téve a felhasználók számára az alkalmazások sebezhetőségének hatékony azonosítását és javítását.
A sebezhetőségek azonosítása mellett az OPSWAT SBOM az egyes szoftverkomponensekhez kapcsolódó licenceket is érvényesíti. Ez biztosítja a licencfeltételeknek való megfelelést, és elkerüli a lehetséges jogi buktatókat. Tudjon meg többet a licencfelismerés döntő szerepéről az OSS-ben.
OPSWAT A SBOM több mint 10 programozási nyelvet támogat, köztük a Java, JavaScript, Go, PHP és Python nyelveket. Ez a széleskörű támogatás biztosítja a vulnerability detection átfogó elérhetőségét a különböző szoftverfejlesztési ökoszisztémákban.
Meg nem felelés esetén kiszabott szankciók
Azok a szervezetek, amelyek nem felelnek meg a PCI DSS szabványoknak, beleértve a SBOM követelményt is, havi 5000 és 100 000 dollár közötti pénzbírsággal sújthatók. Ezek a bírságok idővel növekedhetnek, ha a megfelelési problémák megoldatlanok maradnak.
A pénzügyi szankciók mellett a PCI DSS-nek való meg nem felelés jelentős jogi és működési kihívásokhoz vezethet. A jogi következmények között peres eljárások, védekezési költségek és jelentős kártérítések szerepelhetnek. Ezen túlmenően a megfelelés elmulasztása olyan szövetségi ügynökségek, mint a Szövetségi Kereskedelmi Bizottság (FTC) által végzett ellenőrzéseket válthat ki, amelyek további büntetéseket vonhatnak maguk után.
Következő lépések a PCI DSS 4.0 megfelelés érdekében
Az SBOM integrálása a PCI DSS 4.0 keretrendszerbe kulcsfontosságú változást jelent a biztonságosabb szoftverellátási lánc felé. Az olyan fejlett eszközök, mint az OPSWAT SBOM kihasználásával a szervezetek hatékonyan kezelhetik a nyílt forráskódú kockázatokat, javíthatják a jogszabályi megfelelőséget, és védelmet nyújthatnak a költséges adatszegések ellen.
Az SBOM-ok használata már nem lehetőség, hanem szükségszerűség. A szoftverfüggőségek megértését és kezelését célzó proaktív lépésekkel a szervezetek olyan szilárd biztonsági alapot építhetnek, amely védi a működésüket és növeli az ügyfelek bizalmát.
Javítsa a biztonságát
Posture with OPSWAT
Érdekel a nyílt forráskódú
függőségek kezelését most.
