SBOM-ok ISO 27001, NIS2 és DORA szerinti bizonyosságszerzéshez

Péntek reggel 07:42 van, amikor Amelia, egy gyorsan növekvő fintech vállalat információbiztonsági vezetője megkapja azt a riasztást, amelyet egyetlen biztonsági vezető sem szeretne látni.

Egy széles körben használt nyílt forráskódú csomag kritikus távoli kódfuttatási sérülékenységet tartalmaz. A szoftverösszetevő-elemző eszköz szerint a komponens előfordulhat a hitelesítési szolgáltatásban, esetleg a számlázásban, és talán egy harmadik féltől származó API-adapterben is, amelyet a fizetési munkafolyamat használ. A mérnöki csapatnak időre van szüksége a megerősítéshez. A jogi terület azt kérdezi, elindult-e már a NIS2 szerinti bejelentési határidő. A DORA-program vezetője azt kérdezi, hogy az érintett szolgáltatás támogat-e kritikus vagy fontos funkciót egy pénzügyi szervezet számára. Az értékesítés azt kérdezi, akadályozza-e ez a szerződéshosszabbítást. Az igazgatóság pedig felteszi a legegyszerűbb és legnehezebb kérdést: „Érintettek vagyunk?”

Szoftveranyagjegyzék nélkül az őszinte válasz gyakran ez: „Ezt még nem tudjuk.”

2026-ban ez a válasz már nem pusztán technikai hiányosság. Irányítási gyengeség, szerződéses kockázat, auditkitettség, szabályozott szervezeteknél pedig reziliencia-probléma. Az SBOM-ok a DevSecOps-higiénia eszközeiből igazgatósági szintű bizonyítékokká váltak a szoftver-ellátási lánci bizonyosság, az ISO/IEC 27001:2022 kontrollműködés, a NIS2 szerinti kiberbiztonsági kockázatkezelés, a DORA szerinti IKT harmadik fél kockázatkezelés, a GDPR szerinti elszámoltathatóság és az ügyféloldali kellő gondosság támogatására.

A lényeg nem egyszerűen egy SBOM-fájl előállítása. A lényeg annak bizonyítása, hogy a szoftverkomponensek azonosítottak, jóváhagyottak, nyomon követettek, kockázat szerint besoroltak, javítottak, szerződésesen szabályozottak, és elszámoltatható tulajdonosokhoz visszakövethetők. Itt alakítja át a Clarysec szabályzattára, a Zenith Blueprint: az auditor 30 lépéses ütemterve és a Zenith Controls: a keresztmegfelelési útmutató a fejlesztői artefaktumot igazolható megfelelőségi bizonyítékká.

Miért váltak az SBOM-ok a szoftver-ellátási lánci bizonyosság bizonyítékaivá

Az SBOM a szoftverkomponensek nyilvántartása, beleértve a nyílt forráskódú csomagokat, kereskedelmi könyvtárakat, verziókat, forrásokat, licenceket és függőségi kapcsolatokat. Egy jól használható SBOM négy olyan kérdés megválaszolásában segít, amelyek ma már a szabályozók, ügyfelek és igazgatóságok számára is lényegesek:

1. Mi található a szoftverünkben?
2. Hol van telepítve?
3. Sérülékeny, már nem támogatott, licenc nélküli vagy nem jóváhagyott?
4. Ki felel a javításért, a kockázatcsökkentésért vagy a kockázatelfogadásért?

Ezek a kérdések közvetlenül illeszkednek a mai jogi és szabályozási elvárásokhoz.

A NIS2 számos közepes és nagy szervezetre vonatkozik az alapvető és fontos ágazatokban, beleértve a digitális infrastruktúrát, a felhőszolgáltatókat, az adatközpont-szolgáltatókat, a menedzselt szolgáltatókat, a menedzselt biztonsági szolgáltatókat, az online piactereket, a keresőmotorokat, a közösségi hálózati platformokat és bizonyos digitális szolgáltatókat. Alkalmazhatósága nemzeti kijelölés és ágazatspecifikus átültetés alapján is fennállhat. Az alkalmazási körbe tartozó szervezeteknél a NIS2 előírja, hogy az irányító testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, és felügyeljék azok végrehajtását. Az Article 21 magában foglalja az ellátási lánc biztonságát, a biztonságos beszerzést, a biztonságos fejlesztést és karbantartást, a sérülékenységek kezelését és közzétételét, az incidenskezelést, az üzletmenet-folytonosságot, az eszközkezelést, a hozzáférés-szabályozást, a kriptográfiát, az eredményesség értékelését és a kiberhigiéniát.

A 2025. január 17-től alkalmazandó DORA egységes uniós digitális működési reziliencia-keretrendszert hoz létre a pénzügyi szervezetek számára. Lefedi az IKT-kockázatkezelést, az IKT-val kapcsolatos incidensek jelentését, a rezilienciatesztelést, az IKT harmadik fél kockázatkezelést, a szerződéses megállapodásokat és a kritikus IKT harmadik fél szolgáltatók felügyeletét. A DORA elvárja, hogy a pénzügyi szervezetek azonosítsák az IKT-eszközöket, az IKT által támogatott üzleti funkciókat, a függőségeket, az összekapcsolódásokat, a sérülékenységeket, a kockázati forgatókönyveket, a változásokat és a harmadik felek által támogatott folyamatokat.

A GDPR ehhez adatvédelmi réteget ad. Ha egy sérülékeny komponens személyes adatokat kezelő rendszereket érint, a kérdés az, hogy a személyes adatokhoz hozzáfértek-e, módosíthatták-e őket, elveszhettek-e, nyilvánosságra kerülhettek-e vagy más módon kompromittálódhattak-e. Az adatkezelőknek és adatfeldolgozóknak olyan bizonyítékokra van szükségük, amelyek igazolják, hogy képesek azonosítani az érintett rendszereket, adatáramlásokat, további adatfeldolgozókat és az incidens hatását.

A NIST CSF 2.0 ugyanezt a működési modellt erősíti a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER funkciókon keresztül. Ellátási lánci kimenetei beszállítói felelősségeket, kritikusságot, szerződéses követelményeket, kellő gondosságot, felügyeletet, incidens-tervezést és a kapcsolat lezárására vonatkozó rendelkezéseket várnak el.

Amikor Amelia igazgatósága azt kérdezi, hogy a fintech vállalat érintett-e, egy SBOM-mal támogatott szervezet bizonyítékokkal tud válaszolni:

• Mely termékek és kiadások tartalmazzák a sérülékeny komponenst
• Mely telepített környezetek érintettek
• Mely ügyfelek, régiók, funkciók és adatáramlások kapcsolódnak hozzá
• Mely beszállító vagy belső tulajdonos elszámoltatható
• Mely kompenzáló kontrollok aktívak
• Kiválthatók-e NIS2, DORA, GDPR vagy szerződéses küszöbértékek
• Mely javítás, kockázatcsökkentő intézkedés, kivétel vagy kockázatelfogadás kapott jóváhagyást

Ez a különbség egy komponenslista és egy kontrollrendszer között.

Az ISO 27001:2022 az SBOM-irányítás gerince

Az ISO/IEC 27001:2022 erős alapot ad az SBOM-irányításhoz, mert irányítási rendszer szabvány, nem csupán technikai ellenőrzőlista. Pontjai előírják a szervezet kontextusának, az érdekelt feleknek, az alkalmazási területnek, a vezetői elkötelezettségnek, a szabályzatoknak, a szerepköröknek, a kockázatértékelésnek, a kockázatkezelésnek, a célkitűzéseknek, a teljesítményértékelésnek, a belső auditnak, a vezetőségi felülvizsgálatnak és a folyamatos fejlesztésnek a meghatározását.

Az SBOM-programok akkor vallanak kudarcot, amikor az IBIR-en kívül működnek. A mérnöki csapat előállíthat fájlokat, de senki sem érvényesíti a sérülékenység-javítási SLA-kat, a beszállítói kötelezettségeket, a bizonyítékmegőrzést, a kockázatelfogadást vagy az ügyféltájékoztatási szabályokat. Az ISO 27001 ezt úgy kezeli, hogy az SBOM-okat a szervezet kockázatkezelési rendszerének részévé teszi.

A 4.1–4.4. pontok alapján a szervezet meghatározza a belső és külső tényezőket, az érdekelt felek követelményeit, a jogi és szabályozási kötelezettségeket, a szerződéses elvárásokat és az IBIR alkalmazási területét. Az SBOM-bizonyosság szempontjából az alkalmazási területnek kifejezetten tartalmaznia kell:

• Az ügyfeleknek nyújtott termékeket és szolgáltatásokat
• Felhő- és SaaS-éles környezeteket
• CI/CD-folyamatokat, forráskód-adattárakat és artefaktum-regisztereket
• Nyílt forráskódú és kereskedelmi szoftverkomponenseket
• Kiszervezett fejlesztési és integrációs partnereket
• IKT harmadik fél szolgáltatókat és alvállalkozókat
• A DORA, a NIS2, a GDPR és a szerződések szerinti ügyfélbiztonsági követelményeket

Az 5.1–5.3. pontok a szoftver-ellátási lánci kockázatot vezetői kérdéssé teszik. A vezetésnek össze kell hangolnia a biztonsági célkitűzéseket az üzleti iránnyal, erőforrásokat kell biztosítania, felelősségeket kell kijelölnie és kommunikálnia kell a szabályzatot. A 6.1.2 és 6.1.3 pontok az SBOM-megállapításokat kockázatértékelési és kockázatkezelési bizonyítékká alakítják. Egy kritikus sérülékeny komponens egy internet felől elérhető hitelesítési szolgáltatásban nem pusztán jegy. Olyan kockázati forgatókönyv, amely érinti a bizalmasságot, a sértetlenséget, a rendelkezésre állást, a szerződéses kötelezettségvállalásokat, a szabályozott jelentéstételt és az operatív rezilienciát.

Az SBOM-bizonyosság szempontjából legfontosabb ISO/IEC 27001:2022 A melléklet szerinti kontrollok:

A Clarysec ezeket a kapcsolatokat ISO/IEC 27002:2022 attribútumokon keresztül képezi le a Zenith Controls rendszerben. Például a Zenith Controls az ISO/IEC 27002:2022 5.21 kontrollt, „Információbiztonság kezelése az IKT-ellátási láncban”, megelőző kontrollként kezeli, amely a bizalmasságot, a sértetlenséget és a rendelkezésre állást védi, az Identify kiberbiztonsági koncepcióhoz igazodik, és az irányítási, ökoszisztéma- és védelmi területeken működik. A 8.25 kontrollt, „Biztonságos fejlesztési életciklus”, megelőző kontrollként és a Protect funkcióhoz igazodóként kezeli. A 8.8 kontrollt, „Technikai sérülékenységek kezelése”, megelőző kontrollként, az Identify és Protect funkciókhoz igazodóként kezeli, összekapcsolva a sérülékenységkezelést az irányítással, az ökoszisztémával, a védelemmel és a védekezéssel.

Ez az átfordítás azért fontos, mert a különböző felülvizsgálók különböző kérdéseket tesznek fel. Egy ISO-auditor megkérdezheti, hogy a komponenskockázat szerepel-e az alkalmazhatósági nyilatkozatban. Egy DORA-felülvizsgáló megkérdezheti, hogy egy komponens támogat-e kritikus vagy fontos funkciót. Egy ügyfél megkérdezheti, hogy a megoldatlan sérülékenységek túllépik-e a szerződéses SLA-kat. Ugyanaz az SBOM-bizonyíték mindhárom elvárást támogathatja, ha megfelelően irányított.

A Clarysec szabályzati rétege auditkész SBOM-okhoz

Egy megbízható SBOM-programhoz szabályzati nyelvezet szükséges. A fejlesztőknek tudniuk kell, mit kell rögzíteni. A beszerzésnek tudnia kell, mit kell a beszállítóknak biztosítaniuk. A biztonsági területnek tudnia kell, mely megállapítások váltanak ki eszkalációt. A megfelelőségi területnek tudnia kell, mely bizonyítékokat kell megőrizni.

Kisebb szervezetek esetében a Biztonságos fejlesztési szabályzat – KKV hozza létre a minimálisan életképes SBOM-kontrollt:

Az ügyvezetőnek vagy egy kijelölt fejlesztőnek naprakész listát kell vezetnie valamennyi használt külső komponensről, beleértve: 6.6.2.1 Verzió és forrás 6.6.2.2 Ismert sérülékenységek vagy javításkezelési állapot 6.6.2.3 Utolsó frissítés vagy felülvizsgálat dátuma

Ez a követelmény egyszerű, de erős. Megteremti a verzióátláthatóságot, a forrás-visszakövethetőséget, a sérülékenységi állapot átláthatóságát és a felülvizsgálati ütemezést.

Az Alkalmazásbiztonsági követelmények szabályzata – KKV életciklus-felülvizsgálattal egészíti ki ezt:

Minden, alkalmazásban használt harmadik féltől származó eszközt, bővítményt vagy külső kódkönyvtárat rögzíteni kell, és évente felül kell vizsgálni biztonsági hatás és javításkezelési állapot szempontjából.

A Sérülékenység- és javításkezelési szabályzat – KKV összekapcsolja az SBOM-okat a javítási intézkedésekkel:

A fejlesztőknek nyomon kell követniük és frissíteniük kell a harmadik féltől származó könyvtárakat, például a nyílt forráskódú csomagokat.

Vállalati környezetekben a Biztonságos fejlesztési szabályzat magasabb elvárást állít:

A nyílt forráskódú vagy harmadik féltől származó kód használatát jóvá kell hagyni, nyomon kell követni és ellenőrizni kell a következőkön keresztül:

A vizsgálatot is kötelezővé teszi:

Minden harmadik féltől származó komponenst automatizált eszközökkel sérülékenységvizsgálatnak kell alávetni a bevezetés előtt és futás közben.

A kiszervezett fejlesztésnek ugyanezt a szabványt kell követnie. A Kiszervezett fejlesztési szabályzat előírja:

Nyílt forráskódú könyvtárak biztonságos használata, sérülékenységvizsgálat és jóváhagyás mellett.

A beszállítói szerződéseknek kikényszeríthető bizonyítékszolgáltatási jogokat kell tartalmazniuk. A Harmadik fél és beszállítói biztonsági szabályzat – KKV olyan szerződéses záradékokat ír elő, amelyek lefedik a bizalmasságot, a biztonsági kötelezettségeket, az incidensbejelentési határidőket, az auditálási jogokat, az alvállalkozói korlátozásokat és a biztonságos megszüntetést:

A szerződéseknek kötelező záradékokat kell tartalmazniuk a következőkről: 5.3.1 Bizalmasság és titoktartás 5.3.2 Információbiztonsági kötelezettségek 5.3.3 Adatsértési bejelentési határidők, például 24–72 órán belül 5.3.4 Auditálási jogok vagy megfelelési bizonyítékok rendelkezésre állása 5.3.5 További alvállalkozásba adás korlátozása jóváhagyás nélkül 5.3.6 Megszüntetési feltételek, beleértve az adatok biztonságos visszaszolgáltatását vagy megsemmisítését

Vállalati ügyfelek számára a harmadik fél és beszállítói biztonsági szabályzat tartalmazza:

Auditálási, ellenőrzési és biztonsági bizonyítékok kérésére vonatkozó jogok

Ha egy SaaS-szolgáltató, kiszervezett fejlesztési partner vagy kereskedelmi szoftverbeszállító nem biztosít biztonsági bizonyítékot, sérülékenységi állapotot, bejelentési kötelezettségvállalásokat vagy audit-hozzáférést, akkor a szoftver-ellátási lánci bizonyosságban vakfolt marad.

A Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat a függőségi koncentrációt mérhető rezilienciakockázattá alakítja:

Beszállítói függőségi nyilvántartás: A VMO-nak naprakész nyilvántartást kell vezetnie valamennyi kritikus beszállítóról, beleértve olyan részleteket, mint a nyújtott szolgáltatások/termékek; hogy a beszállító egyforrásos-e; rendelkezésre állnak-e alternatív beszállítók vagy helyettesíthetőségi lehetőségek; az aktuális szerződéses feltételek; valamint annak értékelése, hogy milyen hatása lenne, ha a beszállító kiesne vagy kompromittálódna. A nyilvántartásnak egyértelműen azonosítania kell a magas függőségi kockázatú beszállítókat, például azokat, amelyeknél nincs gyors alternatíva.

Ezt a nyilvántartást össze kell kapcsolni az SBOM-okkal. Ha egy kritikus könyvtár egyforrásos beszállítótól származik, szabályozott ügyfélmunkafolyamatot támogat, és nincs gyors helyettesítője, akkor nem pusztán csomag. Rezilienciafüggőség.

SBOM-fájlból operatív kontroll egy sprint alatt

Egy gyakorlati SBOM-programot egy termékvonallal és egy éles környezettel érdemes kezdeni. Nem célszerű az első napon a teljes vállalatot nyilvántartásba venni. Ha Amelia fintech vállalata az ügyfél-belépési és fizetési munkafolyamattal kezdi, a csapat ismételhető bizonyítékmodellt tud kialakítani a skálázás előtt.

1. lépés: Az SBOM alkalmazási területének meghatározása az IBIR-en belül

Hozzon létre alkalmazási területi nyilatkozatot az IBIR alkalmazási területéhez és a szabályozási hajtóerőkhöz kapcsolva:

• Termék: ügyfél-belépési és fizetési SaaS-platform
• Környezet: EU éles környezet
• Adattárak: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Build rendszerek: Git-szolgáltató, CI/CD-platform, konténerregiszter
• Bevezetés: Kubernetes-klaszter, menedzselt adatbázis, objektumtároló
• Adatok: fiókadatok, hitelesítési naplók, számlázási metaadatok, fizetési hivatkozások
• Ügyfelek: uniós pénzügyi szervezetek és kereskedelmi ügyfelek
• Szabályozási hajtóerők: ISO 27001:2022, NIS2 ügyfélbizonyosság, DORA IKT harmadik fél átvilágítás, GDPR biztonsági elszámoltathatóság

Ez összhangban van az ISO 27001 4. pont szerinti alkalmazási területi logikájával és a NIST CSF Profile alkalmazási területének meghatározásával.

2. lépés: SBOM-ok előállítása és tárolása buildeléskor

Konfigurálja a CI/CD-folyamatokat úgy, hogy minden build-artefaktumhoz, beleértve a konténerképeket is, SBOM készüljön. Általánosan használt szabványos formátumok például a CycloneDX és az SPDX. Minden SBOM-ot kontrollált bizonyítéktárban kell tárolni, a build-azonosítóhoz, a commit-hash-hez, a bevezetési nyilvántartáshoz és a kiadási verzióhoz kapcsolva.

Ez közvetlenül támogatja a Biztonságos fejlesztési szabályzat – KKV azon követelményét, hogy nyilván kell tartani a verziót, a forrást, az ismert sérülékenységet vagy javításkezelési állapotot és a felülvizsgálat dátumát.

3. lépés: Az SBOM-adatok kiegészítése kihasználhatósági és üzleti kontextussal

Ne álljon meg a csomaglistánál. Adjon hozzá operatív kockázati kontextust:

• Sérülékeny-e a komponens?
• Elérhető-e a sérülékeny funkció?
• Internet felől elérhető-e a szolgáltatás?
• Kezel-e a szolgáltatás személyes adatokat?
• Támogat-e kritikus vagy fontos funkciót egy DORA-ügyfél számára?
• Elérhető-e javítás?
• Van-e kompenzáló kontroll?
• Jóváhagyta-e a kockázatgazda a kockázatelfogadást?

Egy kritikus CVE egy kizárólag teszteléshez használt csomagban más, mint egy kritikus CVE egy éles hitelesítési szolgáltatásban. Az ISO 27001 kockázatértékelési és kockázatkezelési pontjai segítenek ezt a különbséget igazolhatóvá tenni.

4. lépés: Az SBOM-ok összekapcsolása beszállítói és kiszervezett fejlesztési kontrollokkal

Ha egy komponenst kereskedelmi beszállító vagy kiszervezett fejlesztési partner biztosít, frissítse a beszállítói nyilvántartást:

Ez támogatja a NIS2 Article 21 ellátásilánc-biztonsági követelményeit és a DORA Article 28 elvárásait az IKT harmadik fél kockázati stratégiával, kellő gondossággal, szerződéses védelmi intézkedésekkel, információs nyilvántartásokkal, audittervezéssel, megszüntetési jogokkal és kilépési stratégiákkal kapcsolatban.

5. lépés: Javítási szabályok és bizonyítékok meghatározása

A javítási SLA-kat az üzleti hatáshoz kell kötni, nem pusztán a CVSS-pontszámokhoz.

Itt válnak az SBOM-ok hasznossá a NIS2, a DORA és a GDPR szempontjából. A javítási munkafolyamatnak figyelembe kell vennie a jelentős incidens lehetőségét, a jelentős IKT-val kapcsolatos incidens hatását, a személyesadat-sértés kritériumait, a szerződéses bejelentési kötelezettségeket és az operatív reziliencia hatását.

6. lépés: Kiadási kapu hozzáadása

Bevezetés előtt a CI/CD-folyamatnak vagy a változáskezelési folyamatnak meg kell erősítenie:

• Az SBOM sikeresen előállt
• Nem maradt jóváhagyás nélküli kritikus sérülékenység
• Az új harmadik féltől származó komponensek jóváhagyottak
• A licencszabályzat ellenőrzése sikeres
• Az SCA, SAST, DAST vagy más előírt tesztelés befejeződött
• A változtatási jegy kapcsolva van
• A visszaállítási terv dokumentált a magas kockázatú kiadásokhoz

Ez az A.8.25 biztonságos fejlesztést, az A.8.29 biztonsági tesztelést és az A.8.32 változáskezelést egyetlen auditálható munkafolyamatba kapcsolja össze.

7. lépés: Kiadási bizonyítékcsomag összeállítása

Minden kiadáshoz őrizze meg:

• SBOM-fájl
• Build-azonosító és commit-hash
• SCA-vizsgálati kimenet
• Sérülékenységi elsődleges értékelési bejegyzés
• Jóváhagyott kivételek
• Változtatás-jóváhagyás
• Bevezetési nyilvántartás
• Teszteredmények
• Beszállítói bizonyíték, ha alkalmazható
• Incidens- vagy problémabejegyzés, ha a kiadás sérülékenységet javított

Amikor egy auditor megkérdezi, hogyan kezelik a harmadik féltől származó könyvtárakat éles környezetben, Amelia csapata nem Slack-szálakban keresgél. Megnyitja a kiadási bizonyítékcsomagot.

Keresztmegfelelési leképezés: egy SBOM-program, sok kötelezettség

Egy SBOM-program üzleti értéke akkor nő, ha egyszer leképezik, majd több keretrendszerben újra felhasználják. A Clarysec keresztmegfelelési megközelítése elkerüli a párhuzamos munkát azzal, hogy ugyanazokat a bizonyítékokat különböző bizonyossági nyelvekre fordítja le.

A NIS2 szerinti incidensjelentés gyorsan eszkalálódhat, ha a kihasználás súlyos működési zavart, pénzügyi veszteséget vagy jelentős vagyoni vagy nem vagyoni kárt okoz, vagy erre alkalmas. A NIS2 szakaszos jelentéstételt alkalmaz, beleértve az észleléstől számított 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést és az incidensbejelentést követő egy hónapon belüli zárójelentést. Az SBOM-ok segítenek megállapítani, hogy az érintett komponens jelen van-e, érintettek-e az ügyfélszolgáltatások, és valószínűsíthető-e határokon átnyúló hatás.

A DORA strukturált IKT-incidenséletciklust alkalmaz, beleértve az észlelést, rögzítést, besorolást, gyökérok-elemzést, eszkalációt, kommunikációs terveket, irányító testületi eszkalációt és a jelentős IKT-val kapcsolatos incidensek szabályozói jelentését. Az SBOM-bizonyíték támogatja a besorolást, mert összekapcsolja a sérülékeny komponenst az érintett ügyfelekkel, kiesési idővel, földrajzi kiterjedéssel, adatvesztéssel, szolgáltatáskritikussággal és gazdasági hatással.

A NIST CSF 2.0 hasznos nyelvezetet ad az ügyfélbizonyossághoz. A Zenith Controls az A.5.21 kontrollt olyan ellátásilánc-irányítási kimenetekhez rendeli, mint a GV.SC-05, ahol a beszállítókra vonatkozó kiberbiztonsági követelményeket meghatározzák, kommunikálják és beépítik a szerződésekbe és egyéb megállapodásokba. Az SBOM-ok, a sérülékenység-feltárás, az auditbizonyítékok és a javítási határidők megkövetelése szerződéses kontrollá válik, nem eseti kéréssé.

Hogyan ütemezi a munkát a Zenith Blueprint

A Zenith Blueprint a kontrollnyelvezetet bevezetési ütemtervvé alakítja.

A kockázatkezelési szakaszban a 14. lépés összekapcsolja a biztonságos fejlesztést, a CI/CD-kontrollokat, a függőségvizsgálatot, a változáskezelést, az incidenskezelést és a fejlesztői képzést. A működésben lévő kontrollok szakaszában a 20. lépés kifejezetten foglalkozik a harmadik féltől származó és nyílt forráskódú komponensekkel:

Ez a kontroll a harmadik féltől származó és nyílt forráskódú komponensekre is vonatkozik. Külső könyvtárakra támaszkodni bevett gyakorlat, de minden bevonás bizalmi döntés. A fejlesztőknek a függőségeket reputáció, karbantartási gyakoriság, ismert sérülékenységek és licenc- korlátozások alapján kell értékelniük. Az olyan eszközök, mint az SBOM-ok (szoftveranyagjegyzékek), egyre fontosabbak annak nyomon követéséhez, hogy mi épül be a technológiai stackbe.

A 21. lépés a biztonsági tesztelést kontextusvezéreltként kezeli, és rétegzett tesztelést javasol az üzletmenet-kritikus vagy internetnek kitett rendszerekhez, beleértve a szoftverösszetevő-elemzést harmadik féltől származó könyvtárakra, a statikus és dinamikus elemzést, a penetrációs tesztelést, a fenyegetésmodellezés ellenőrzését, a visszaélési esetek tesztelését, a fuzzingot és a manuális feltáró tesztelést.

A 23. lépés a beszállítói megállapodásokkal foglalkozik, beleértve a titoktartási kötelezettségeket, a hozzáférés-szabályozási felelősségeket, a technikai és szervezési intézkedéseket, az incidensjelentési határidőket, az auditálási jogot, az alvállalkozói kontrollokat és a szerződés lezárására vonatkozó rendelkezéseket.

A gyakorlati tanulság egyszerű. Az SBOM-oknak a kockázatkezelésben, a biztonságos fejlesztésben, a tesztelésben, a beszállítói irányításban, az incidensreagálásban és a vezetői jelentéstételben is helyük van.

Auditnézőpont: mit tesztelnek a különböző felülvizsgálók

Egy érett SBOM-programnak különböző auditstílusok mellett is meg kell állnia a helyét.

Egy ISO 27001:2022 auditor az IBIR-rel kezdi. Megkérdezi, hogy a szoftver-ellátási lánci kockázat az alkalmazási területen belül van-e, az érdekelt felek követelményei tartalmazzák-e a NIS2, DORA ügyfelek, GDPR és szerződések szerinti elvárásokat, a komponenskockázat része-e a kockázati módszertannak, az alkalmazhatósági nyilatkozat tartalmazza-e a releváns A melléklet szerinti kontrollokat, és a szabályzatokat időben következetesen végrehajtják-e. Mintát vehet egy kiadásból, és végigkövetheti a szabályzattól a CI/CD-folyamaton, SBOM-on, sérülékenységvizsgálaton, változtatás-jóváhagyáson, bevezetésen és kiadás utáni felügyeleten át.

Egy DORA-felülvizsgáló vagy pénzügyi ügyfél az operatív rezilienciára és az IKT harmadik fél kockázatra fókuszál. Megkérdezheti, mely komponensek támogatják a pénzügyi szervezet által használt szolgáltatást, a szolgáltatás támogat-e kritikus vagy fontos funkciót, hogyan dokumentálják az IKT-eszközöket és függőségeket, figyelik-e a sérülékenységeket, az éves tesztelés lefedi-e a kritikus rendszereket, és a szerződések tartalmaznak-e segítségnyújtást, auditálási jogokat, incidensbejelentést, adathelyszínt, alvállalkozásba adást és megszüntetési feltételeket.

Egy NIST CSF értékelő a kimeneteket vizsgálja. A GOVERN alatt tesztelni fogja a jogi, szabályozási, szerződéses, adatvédelmi és ellátásilánc-irányítást. Az IDENTIFY alatt eszköz-, szoftver- és szolgáltatásláthatóságot vár el. A PROTECT alatt a biztonságos fejlesztést és a CI/CD-kontrollokat teszteli. A DETECT és RESPOND alatt a sérülékenységi riasztásokat, elemzést, eszkalációt és kommunikációt vizsgálja. A RECOVER alatt azt kérdezi, hogyan érinti a komponens kompromittálódása a helyreállítást és az ügyfélkommunikációt.

Egy COBIT- vagy ISACA-stílusú auditor az irányításra, az elszámoltathatóságra, a kockázattulajdonosi felelősségre, a kontrolltervezésre és a bizonyítékok megbízhatóságára fókuszál. Tesztelheti, hogy az SBOM-ok teljesek-e, a sérülékenységi jegyek a szabályzat szerinti határidőn belül zárulnak-e, a kivételek lejárnak-e, a beszállítói bizonyítékok naprakészek-e, és a vezetés érdemi jelentést kap-e.

Gyakori SBOM-hibák, amelyeket érdemes elkerülni

Az SBOM-programok általában előre látható okokból vallanak kudarcot.

Az első hiba az SBOM-ok előállítása, de nem kontrollált bizonyítékként történő tárolása. Ha a fájlt minden build felülírja, és nem kapcsolható kiadáshoz, gyenge auditbizonyíték.

A második hiba az SBOM-ok leválasztása a sérülékenységkezelésről. Egy komponenslista elsődleges értékelés, tulajdonosi felelősség, javítási intézkedés vagy kockázatelfogadás nélkül nem bizonyítja a kontrollműködést.

A harmadik hiba a tranzitív függőségek kizárása. A sérülékenységek gyakran a közvetlen függőségi réteg alatt rejtőznek.

A negyedik hiba a kiszervezett fejlesztés folyamaton kívül hagyása. Ha egy beszállító komponensfeltárás, vizsgálati bizonyíték vagy jóváhagyási nyilvántartás nélkül szállít kódot, a szoftver-ellátási láncban nem kezelt vakfolt keletkezik.

Az ötödik hiba a beszállítói szerződések bizonyítékszolgáltatási jogok nélküli aláírása. A beszerzés aláírja a megállapodást, a mérnöki csapat használja a szolgáltatást, a biztonsági terület pedig később észleli, hogy nincs auditálási jog, nincs sérülékenység-feltárási kötelezettség, nincs alvállalkozói korlátozás és nincs kilépési támogatás.

A hatodik hiba a komponensek üzleti szolgáltatásokhoz való leképezésének hiánya. Egy sérülékeny csomag önmagában keveset jelent, amíg nem tudjuk, hogy érinti-e a hitelesítést, a fizetéseket, a jelentéskészítést, a betegadatokat, a felhőadminisztrációt, az ügyfél-belépést vagy egy szabályozott pénzügyi munkafolyamatot.

A hetedik hiba a megoldatlan kritikus sérülékenységek elrejtése a vezetés elől. A NIS2 és a DORA egyaránt kifejezetten rögzíti a vezetői elszámoltathatóságot. A kritikus komponenskockázatnak láthatónak kell lennie az irányítási fórumok számára, nem maradhat elásva a mérnöki backlogban.

Milyen a jó SBOM-program 2026-ban

Egy auditkész SBOM-programnak jól látható ismérvei vannak.

Van jóváhagyott szabályzat, amely előírja, hogy a harmadik féltől származó és nyílt forráskódú komponenseket jóvá kell hagyni, nyomon kell követni, vizsgálni kell és felül kell vizsgálni. A CI/CD-folyamat automatikusan előállítja az SBOM-okat. Az SCA-vizsgálatok bevezetés előtt és adott esetben futás közben is lefutnak. A kritikus sérülékenységek meghatározott eszkalációt váltanak ki. A kivételeknek van tulajdonosuk, lejárati dátumuk, kompenzáló kontrolljuk és kockázatelfogadásuk.

A beszállítói szerződések biztonsági kötelezettségeket, incidensbejelentési határidőket, auditálási jogokat, alvállalkozói kontrollokat és megszüntetési rendelkezéseket tartalmaznak. A kritikus beszállítókat legalább évente felülvizsgálják. A beszállítói függőségi és koncentrációs kockázatok láthatók. A kiszervezett fejlesztési csapatok ugyanazokat a biztonságos fejlesztési és komponensjóváhagyási szabályokat követik, mint a belső csapatok.

A vezetői jelentéstétel összekapcsolja a technikai kockázatot az üzleti hatással:

• Kritikus sérülékeny komponensek termékenként
• Kitettség ügyfelenként vagy szabályozott szolgáltatásonként
• SLA-n túli nyitott javítási intézkedések
• Jóváhagyott forrás nélküli komponensek
• Már nem támogatott vagy életciklusuk végére ért könyvtárak
• Beszállítói bizonyítékhiányok
• Megújításra vagy lezárásra váró kivételek
• Komponenssérülékenységekhez kapcsolódó incidensek

Ekkor szűnnek meg az SBOM-ok puszta megfelelési artefaktumnak lenni, és válnak vezetői eszközzé.

Alakítsa az SBOM-okat igazolható megfelelőségi bizonyítékká

Amikor legközelebb 07:42-kor kritikus komponensriasztás érkezik, a válasznak nem annak kell lennie: „Két órára van szükségünk, hogy kiderítsük, hol van.”

A válasznak így kell hangoznia: „Itt az érintett komponens, itt vannak a szolgáltatások, itt vannak az ügyfelek, itt a kockázati besorolás, itt a javítási terv, és itt vannak a bizonyítékok.”

A Clarysec segít megtervezni ezt a kontrollrendszert. Segítünk a szervezeteknek az SBOM alkalmazási területének meghatározásában az IBIR-en belül, az ISO 27001:2022 A melléklet szerinti kontrollok NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-jellegű auditelvárásokhoz való leképezésében, biztonságos fejlesztési és beszállítói szabályzatok bevezetésében, kiadási bizonyítékcsomagok összeállításában, valamint auditkész bizonyosság kialakításában a Zenith Controls és a Zenith Blueprint használatával.

Készen áll arra, hogy a szoftver-ellátási láncát a bizonytalanság forrásából a reziliencia bizonyítékává alakítsa?

Töltse le a releváns Clarysec szabályzatokat, használja a Zenith Blueprint megoldást a bevezetés ütemezéséhez, és a Zenith Controls megoldást a bizonyítékok ISO 27001:2022, NIS2, DORA és ügyfélbizonyossági követelmények közötti leképezéséhez. Lépjen kapcsolatba a Clarysec csapatával, hogy célzott SBOM-felkészültségi értékeléssel induljon, és gyakorlati, auditkész szoftver-ellátási lánci bizonyossági programot építsen.