SBOM pre auditné uistenie podľa ISO 27001, NIS2 a DORA

Je piatok 07:42, keď Amelia, CISO rýchlo rastúcej fintechovej spoločnosti, dostane upozornenie, ktoré nechce vidieť žiadny bezpečnostný líder.

Široko používaný open-source balík obsahuje kritickú zraniteľnosť umožňujúcu vzdialené spustenie kódu. Nástroj na analýzu zloženia softvéru uvádza, že komponent sa môže nachádzať v autentifikačnej službe, možno vo fakturácii a možno aj v integračnej knižnici tretej strany pre API používanej v platobnom pracovnom toku. Vývojový tím potrebuje čas na potvrdenie. Právne oddelenie sa pýta, či už začala plynúť oznamovacia lehota podľa NIS2. Manažér programu DORA sa pýta, či dotknutá služba podporuje kritickú alebo dôležitú funkciu finančného subjektu. Obchodné oddelenie sa pýta, či to zablokuje obnovenie zmluvy. Predstavenstvo kladie najjednoduchšiu a zároveň najťažšiu otázku: „Sme vystavení riziku?“

Bez softvérového kusovníka často znie poctivá odpoveď: „Zatiaľ nevieme.“

V roku 2026 už takáto odpoveď nie je iba technickou medzerou. Je to slabina v správe a riadení, zmluvné riziko, auditná expozícia a pri regulovaných subjektoch aj problém odolnosti. SBOM sa posunuli z oblasti hygieny DevSecOps na úroveň dôkazového materiálu pre predstavenstvo v oblasti uistenia dodávateľského reťazca softvéru, prevádzky kontrol ISO/IEC 27001:2022, riadenia kybernetických rizík podľa NIS2, riadenia tretích strán v oblasti IKT podľa DORA, zodpovednosti podľa GDPR a zákazníckej náležitej starostlivosti.

Kľúčom nie je len vygenerovať súbor SBOM. Kľúčom je preukázať, že softvérové komponenty sú identifikované, schválené, monitorované, hodnotené podľa rizika, záplatované, zmluvne riadené a sledovateľné voči zodpovedným vlastníkom. Práve tu knižnica politík Clarysec, Zenith Blueprint: 30-kroková cestovná mapa audítora a Zenith Controls: príručka krížového súladu menia vývojársky artefakt na obhájiteľné dôkazy súladu.

Prečo sú SBOM dnes dôkazom uistenia dodávateľského reťazca softvéru

SBOM je evidencia softvérových komponentov vrátane open-source balíkov, komerčných knižníc, verzií, zdrojov, licencií a vzťahov závislostí. Užitočný SBOM pomáha odpovedať na štyri otázky, ktoré dnes zaujímajú regulátorov, zákazníkov aj predstavenstvá:

1. Čo sa nachádza v našom softvéri?
2. Kde je to nasadené?
3. Je to zraniteľné, nepodporované, nelicencované alebo neschválené?
4. Kto vlastní nápravu, zmiernenie rizika alebo akceptáciu rizika?

Tieto otázky priamo zodpovedajú moderným právnym a regulačným očakávaniam.

NIS2 sa vzťahuje na mnohé stredné a veľké subjekty v základných a dôležitých sektoroch vrátane digitálnej infraštruktúry, poskytovateľov cloud computingu, poskytovateľov služieb dátových centier, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb, online trhovísk, vyhľadávačov, platforiem sociálnych sietí a niektorých digitálnych poskytovateľov. Môže sa uplatniť aj na základe vnútroštátneho určenia a sektorovo špecifickej transpozície. Pre subjekty v rozsahu pôsobnosti NIS2 vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík a dohliadali na ich implementáciu. Article 21 zahŕňa bezpečnosť dodávateľského reťazca, bezpečné obstarávanie, bezpečný vývoj a údržbu, riešenie a zverejňovanie zraniteľností, riešenie incidentov, kontinuitu činností, správu aktív, riadenie prístupu, kryptografiu, posúdenie účinnosti a kybernetickú hygienu.

DORA, uplatniteľné od 17. januára 2025, vytvára jednotný rámec digitálnej prevádzkovej odolnosti EÚ pre finančné subjekty. Zahŕňa riadenie rizík IKT, nahlasovanie incidentov súvisiacich s IKT, testovanie odolnosti, riadenie rizík tretích strán v oblasti IKT, zmluvné dojednania a dohľad nad kritickými externými poskytovateľmi IKT. DORA očakáva, že finančné subjekty budú identifikovať IKT aktíva, podnikové funkcie podporované IKT, závislosti, prepojenia, zraniteľnosti, rizikové scenáre, zmeny a procesy podporované tretími stranami.

GDPR pridáva vrstvu ochrany súkromia. Ak zraniteľný komponent ovplyvňuje systémy spracúvajúce osobné údaje, otázka znie, či mohlo dôjsť k neoprávnenému prístupu k osobným údajom, ich zmene, strate, zverejneniu alebo inému kompromitovaniu. Prevádzkovatelia a sprostredkovatelia potrebujú dôkazy, že vedia identifikovať dotknuté systémy, toky údajov, ďalších sprostredkovateľov a vplyv porušenia ochrany osobných údajov.

NIST CSF 2.0 posilňuje rovnaký prevádzkový model prostredníctvom funkcií GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. Jeho výsledky pre dodávateľský reťazec očakávajú zodpovednosti dodávateľov, kritickosť, zmluvné požiadavky, náležitú starostlivosť, monitorovanie, plánovanie incidentov a ustanovenia pre ukončenie vzťahu.

Keď sa predstavenstvo Ameliinej fintechovej spoločnosti opýta, či je organizácia vystavená riziku, organizácia podporená SBOM vie odpovedať dôkazmi:

• Ktoré produkty a vydania obsahujú zraniteľný komponent
• Ktoré nasadené prostredia sú dotknuté
• Ktorí zákazníci, regióny, funkcie a toky údajov sú prepojené
• Ktorý dodávateľ alebo interný vlastník je zodpovedný
• Ktoré kompenzačné kontroly sú aktívne
• Či môžu byť aktivované prahové hodnoty podľa NIS2, DORA, GDPR alebo zmlúv
• Ktorá oprava, zmiernenie, výnimka alebo akceptácia rizika bola schválená

To je rozdiel medzi zoznamom komponentov a systémom kontrol.

ISO 27001:2022 je základom správy a riadenia SBOM

ISO/IEC 27001:2022 je silným základom pre správu a riadenie SBOM, pretože ide o normu systému manažérstva, nie iba o technický kontrolný zoznam. Jej kapitoly vyžadujú, aby organizácie definovali kontext, zainteresované strany, rozsah, záväzok vedenia, politiku, roly, posúdenie rizík, ošetrenie rizík, ciele, hodnotenie výkonnosti, vnútorný audit, preskúmanie manažmentom a neustále zlepšovanie.

Programy SBOM zlyhávajú, keď stoja mimo ISMS. Vývojový tím môže generovať súbory, ale nikto nepresadzuje SLA pre nápravu zraniteľností, povinnosti dodávateľov, uchovávanie dôkazov, akceptáciu rizika ani pravidlá zverejňovania voči zákazníkom. ISO 27001 to rieši tým, že SBOM sa stávajú súčasťou systému riadenia rizík organizácie.

Podľa kapitol 4.1 až 4.4 organizácia určuje interné a externé otázky, požiadavky zainteresovaných strán, zákonné a regulačné povinnosti, zmluvné očakávania a rozsah ISMS. Pre uistenie SBOM má rozsah výslovne zahŕňať:

• Produkty a služby dodávané zákazníkom
• Produkčné cloudové a SaaS prostredia
• CI/CD pipeline, zdrojové repozitáre a registre artefaktov
• Open-source a komerčné softvérové komponenty
• Outsourcovaný vývoj a integračných partnerov
• Externých poskytovateľov IKT a subdodávateľov
• Požiadavky zákazníkov na bezpečnosť podľa DORA, NIS2, GDPR a zmlúv

Kapitoly 5.1 až 5.3 robia z rizika dodávateľského reťazca softvéru tému vedenia. Manažment musí zosúladiť bezpečnostné ciele so smerovaním organizácie, poskytnúť zdroje, priradiť zodpovednosti a komunikovať politiku. Kapitoly 6.1.2 a 6.1.3 premieňajú zistenia zo SBOM na dôkazy posúdenia rizík a ošetrenia rizík. Kritický zraniteľný komponent v autentifikačnej službe prístupnej z internetu nie je len tiket. Je to rizikový scenár ovplyvňujúci dôvernosť, integritu, dostupnosť, zmluvné záväzky, regulačné oznamovanie a prevádzkovú odolnosť.

Najrelevantnejšie kontroly prílohy A ISO/IEC 27001:2022 pre uistenie SBOM sú:

Clarysec mapuje tieto vzťahy cez atribúty ISO/IEC 27002:2022 v Zenith Controls. Napríklad Zenith Controls chápe kontrolu ISO/IEC 27002:2022 5.21 „Riadenie informačnej bezpečnosti v dodávateľskom reťazci IKT“ ako preventívnu, chrániacu dôvernosť, integritu a dostupnosť, zosúladenú s konceptom kybernetickej bezpečnosti Identify a pôsobiacu naprieč oblasťami správy a riadenia, ekosystému a ochrany. Kontrolu 8.25 „Životný cyklus bezpečného vývoja“ chápe ako preventívnu a zosúladenú s Protect. Kontrolu 8.8 „Riadenie technických zraniteľností“ chápe ako preventívnu a zosúladenú s Identify a Protect, čím prepája riadenie zraniteľností so správou a riadením, ekosystémom, ochranou a obranou.

Tento preklad medzi rámcami je dôležitý, pretože rôzni preskúmavatelia kladú rôzne otázky. Audítor ISO sa môže pýtať, či je riziko komponentov zahrnuté vo Vyhlásení o uplatniteľnosti. Preskúmavateľ DORA sa môže pýtať, či komponent podporuje kritickú alebo dôležitú funkciu. Zákazník sa môže pýtať, či nevyriešené zraniteľnosti prekračujú zmluvné SLA. Tie isté dôkazy SBOM môžu podporiť všetky tri pohľady, ak sú správne riadené.

Vrstva politík Clarysec pre SBOM pripravené na audit

Spoľahlivý program SBOM potrebuje jazyk politík. Vývojári musia vedieť, čo sa má zaznamenávať. Obstarávanie musí vedieť, čo majú poskytovať dodávatelia. Bezpečnostný tím musí vedieť, ktoré zistenia spúšťajú eskaláciu. Funkcia súladu musí vedieť, ktoré dôkazy sa majú uchovávať.

Pre menšie organizácie vytvára Politika bezpečného vývoja – MSP minimálnu životaschopnú kontrolu SBOM:

GM alebo určený vývojár musí viesť zoznam všetkých použitých externých komponentov vrátane: 6.6.2.1 Verzie a zdroja 6.6.2.2 Známych zraniteľností alebo stavu záplaty 6.6.2.3 Dátumu poslednej aktualizácie alebo preskúmania

Táto požiadavka je jednoduchá, ale účinná. Zavádza viditeľnosť verzie, sledovateľnosť zdroja, stav zraniteľnosti a rytmus preskúmania.

Politika požiadaviek na bezpečnosť aplikácií – MSP pridáva preskúmanie životného cyklu:

Každý nástroj tretej strany, plugin alebo externá knižnica kódu použitá v aplikácii musí byť zaznamenaná a každoročne preskúmaná z hľadiska bezpečnostného vplyvu a stavu záplatovania.

Politika riadenia zraniteľností a záplat – MSP prepája SBOM s nápravou:

Vývojári musia monitorovať a aktualizovať knižnice tretích strán (napr. open-source balíky)

Pre podnikové prostredia Politika bezpečného vývoja zvyšuje očakávanie:

Používanie open-source kódu alebo kódu tretích strán musí byť schválené, sledované a validované prostredníctvom:

Zároveň stanovuje povinné skenovanie:

Všetky komponenty tretích strán musia byť pred nasadením a počas behu aplikácie skenované na zraniteľnosti pomocou automatizovaných nástrojov.

Outsourcovaný vývoj musí dodržiavať rovnaký štandard. Politika outsourcovaného vývoja vyžaduje:

Bezpečné používanie open-source knižníc podliehajúce skenovaniu zraniteľností a schváleniu

Dodávateľské zmluvy potrebujú vymáhateľné práva na dôkazy. Politika bezpečnosti tretích strán a dodávateľov – MSP vyžaduje zmluvné doložky pokrývajúce dôvernosť, bezpečnostné povinnosti, lehoty oznámenia porušenia ochrany osobných údajov, práva na audit, obmedzenia subdodávok a bezpečné ukončenie:

Zmluvy musia obsahovať povinné ustanovenia pokrývajúce: 5.3.1 Dôvernosť a mlčanlivosť 5.3.2 Povinnosti v oblasti informačnej bezpečnosti 5.3.3 Lehoty oznámenia porušenia ochrany osobných údajov (napr. do 24 – 72 hodín) 5.3.4 Práva na audit alebo dostupnosť dôkazov súladu 5.3.5 Obmedzenia ďalších subdodávok bez schválenia 5.3.6 Podmienky ukončenia vrátane bezpečného vrátenia alebo zničenia údajov

Pre podnikových zákazníkov Politika bezpečnosti tretích strán a dodávateľov obsahuje:

Práva na audit, kontrolu a vyžiadanie bezpečnostných dôkazov

Ak poskytovateľ SaaS, partner pre outsourcovaný vývoj alebo komerčný dodávateľ softvéru neposkytne bezpečnostné dôkazy, stav zraniteľností, záväzky oznámenia alebo prístup k auditu, uistenie vášho dodávateľského reťazca softvéru má slepé miesto.

Politika riadenia rizík závislosti od dodávateľov premieňa koncentráciu závislostí na merateľné riziko odolnosti:

Register závislostí od dodávateľov: VMO vedie aktuálny register všetkých kritických dodávateľov vrátane podrobností, ako sú poskytované služby/produkty; či je dodávateľ jediným zdrojom; dostupní alternatívni dodávatelia alebo nahraditeľnosť; aktuálne zmluvné podmienky; a posúdenie vplyvu, ak by dodávateľ zlyhal alebo bol kompromitovaný. Register musí jasne identifikovať dodávateľov s vysokou mierou závislosti (napr. tých, pre ktorých neexistuje rýchla alternatíva).

Tento register má byť prepojený so SBOM. Ak kritická knižnica pochádza od dodávateľa typu sole-source, podporuje regulovaný zákaznícky pracovný tok a nemá rýchlu náhradu, nejde iba o balík. Ide o závislosť ovplyvňujúcu odolnosť.

Od súboru SBOM k prevádzkovej kontrole v jednom sprinte

Praktický program SBOM má začať jedným produktovým portfóliom a jedným produkčným prostredím. Nepokúšajte sa inventarizovať celý podnik v prvý deň. Ak Ameliina fintechová spoločnosť začne procesom nástupu zákazníkov a platobným pracovným tokom, tím môže pred škálovaním vytvoriť opakovateľný dôkazový model.

Krok 1: Definujte rozsah SBOM v rámci ISMS

Vytvorte vyhlásenie o rozsahu prepojené s rozsahom ISMS a regulačnými dôvodmi:

• Produkt: SaaS platforma pre nástup zákazníkov a platby
• Prostredie: produkcia v EÚ
• Repozitáre: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Build systémy: poskytovateľ Git, CI/CD platforma, register kontajnerov
• Nasadenie: Kubernetes klaster, spravovaná databáza, objektové úložisko
• Údaje: údaje účtov, autentifikačné logy, fakturačné metadáta, platobné referencie
• Zákazníci: finančné subjekty EÚ a komerční zákazníci
• Regulačné dôvody: ISO 27001:2022, zákaznícke uistenie podľa NIS2, náležitá starostlivosť voči tretím stranám v oblasti IKT podľa DORA, zodpovednosť za bezpečnosť podľa GDPR

Toto je v súlade s logikou rozsahu podľa kapitoly 4 ISO 27001 a s určovaním rozsahu profilu NIST CSF.

Krok 2: Vytvárajte a ukladajte SBOM pri zostavení

Nakonfigurujte CI/CD pipeline tak, aby vytvárali SBOM pre každý artefakt zostavenia vrátane obrazov kontajnerov. Bežne sa používajú štandardné formáty ako CycloneDX a SPDX. Každý SBOM uložte do riadeného úložiska dôkazov prepojeného s ID zostavenia, hashom commitu, záznamom o nasadení a verziou vydania.

Toto priamo podporuje požiadavku Politiky bezpečného vývoja – MSP viesť verziu, zdroj, známu zraniteľnosť alebo stav záplaty a dátum preskúmania.

Krok 3: Obohaťte údaje SBOM o zneužiteľnosť a kontext organizácie

Nezastavte sa pri zozname balíkov. Doplňte prevádzkový rizikový kontext:

• Je komponent zraniteľný?
• Je zraniteľná funkcia dosiahnuteľná?
• Je služba prístupná z internetu?
• Spracúva služba osobné údaje?
• Podporuje kritickú alebo dôležitú funkciu zákazníka DORA?
• Je dostupná záplata?
• Existuje kompenzačná kontrola?
• Bola akceptácia rizika schválená vlastníkom rizika?

Kritická CVE v balíku používanom iba na testovanie je odlišná od kritickej CVE v produkčnej autentifikačnej službe. Kapitoly ISO 27001 o posúdení rizík a ošetrení rizík pomáhajú túto odlišnosť obhájiteľne zdokumentovať.

Krok 4: Prepojte SBOM s kontrolami dodávateľov a outsourcovaného vývoja

Ak komponent poskytuje komerčný dodávateľ alebo partner pre outsourcovaný vývoj, aktualizujte záznam dodávateľa:

Toto podporuje bezpečnosť dodávateľského reťazca podľa NIS2 Article 21 a očakávania DORA Article 28 týkajúce sa stratégie riadenia rizík tretích strán v oblasti IKT, náležitej starostlivosti, zmluvných ochranných opatrení, registrov informácií, plánovania auditov, práv na ukončenie a stratégií ukončenia.

Krok 5: Definujte pravidlá nápravy a dôkazy

Prepojte SLA nápravy s vplyvom na činnosť organizácie, nielen so skóre CVSS.

Práve tu sa SBOM stávajú užitočnými pre NIS2, DORA a GDPR. Pracovný tok nápravy má zohľadňovať potenciál významného incidentu, vplyv významného incidentu súvisiaceho s IKT, kritériá porušenia ochrany osobných údajov, zmluvné oznamovacie povinnosti a vplyv na prevádzkovú odolnosť.

Krok 6: Pridajte bránu vydania

Pred nasadením vyžadujte, aby pipeline alebo proces zmeny potvrdil:

• SBOM bol úspešne vytvorený
• Nezostali žiadne kritické neschválené zraniteľnosti
• Nové komponenty tretích strán sú schválené
• Licenčná politika bola splnená
• SCA, SAST, DAST alebo iné požadované testovanie je dokončené
• Tiket zmeny je prepojený
• Plán vrátenia zmien je zdokumentovaný pre vysoko rizikové vydania

Toto prepája A.8.25 bezpečný vývoj, A.8.29 bezpečnostné testovanie a A.8.32 riadenie zmien do jedného pracovného toku vhodného na audit.

Krok 7: Vytvorte dôkazový balík vydania

Pre každé vydanie uchovávajte:

• Súbor SBOM
• ID zostavenia a hash commitu
• Výstup skenu SCA
• Záznam triáže zraniteľností
• Schválené výnimky
• Schválenie zmeny
• Záznam o nasadení
• Výsledky testov
• Dôkazy od dodávateľa, ak sú relevantné
• Záznam incidentu alebo problému, ak vydanie odstraňovalo zraniteľnosť

Keď sa audítor opýta, ako sa v produkcii riadia knižnice tretích strán, Ameliin tím nehľadá narýchlo vo vláknach na Slacku. Otvorí dôkazový balík vydania.

Mapovanie krížového súladu: jeden program SBOM, mnoho povinností

Komerčná hodnota programu SBOM rastie, keď je raz namapovaný a opakovane použitý naprieč rámcami. Prístup krížového súladu Clarysec zabraňuje duplicitnej práci tým, že tie isté dôkazy prekladá do rôznych jazykov uistenia.

Nahlasovanie incidentov podľa NIS2 môže postupovať rýchlo, keď zneužitie spôsobí alebo je schopné spôsobiť vážne prevádzkové narušenie, finančnú stratu alebo značnú materiálnu či nemateriálnu ujmu. NIS2 používa fázované oznamovanie vrátane včasného varovania do 24 hodín od zistenia, oznámenia incidentu do 72 hodín a záverečnej správy do jedného mesiaca od oznámenia incidentu. SBOM pomáhajú určiť, či je dotknutý komponent prítomný, či sú ovplyvnené zákaznícke služby a či je pravdepodobný cezhraničný vplyv.

DORA používa štruktúrovaný životný cyklus incidentov IKT vrátane detekcie, zaznamenania, klasifikácie, analýzy koreňovej príčiny, eskalácie, komunikačných plánov, eskalácie na riadiaci orgán a regulačného oznámenia významných incidentov súvisiacich s IKT. Dôkazy SBOM podporujú klasifikáciu, pretože prepájajú zraniteľný komponent s dotknutými klientmi, výpadkom, geografickým rozsahom, stratami údajov, kritickosťou služby a ekonomickým vplyvom.

NIST CSF 2.0 pridáva užitočný jazyk pre zákaznícke uistenie. Zenith Controls mapuje A.5.21 na výsledky správy dodávateľského reťazca, ako je GV.SC-05, kde sú požiadavky kybernetickej bezpečnosti na dodávateľov stanovené, komunikované a integrované do zmlúv a iných dohôd. Vyžadovanie SBOM, zverejňovania zraniteľností, auditných dôkazov a lehôt nápravy sa tak stáva zmluvnou kontrolou, nie ad hoc požiadavkou.

Ako Zenith Blueprint postupne usporadúva prácu

Zenith Blueprint mení jazyk kontrol na implementačnú cestovnú mapu.

Vo fáze riadenia rizík krok 14 prepája bezpečný vývoj, CI/CD kontroly, skenovanie závislostí, riadenie zmien, riešenie incidentov a školenie vývojárov. Vo fáze Kontroly v praxi je krok 20 explicitný v otázke komponentov tretích strán a open-source komponentov:

Táto kontrola sa vzťahuje aj na komponenty tretích strán a open-source komponenty. Spoliehanie sa na externé knižnice je štandardnou praxou, ale každé zahrnutie je rozhodnutím o dôvere. Vývojári majú hodnotiť závislosti podľa reputácie, frekvencie údržby, známych zraniteľností a licenčných obmedzení. Nástroje ako SBOM (Software Bill of Materials) sú čoraz dôležitejšie na sledovanie toho, čo je vložené vo vašom technologickom stacku.

Krok 21 rámcuje bezpečnostné testovanie ako závislé od kontextu a odporúča vrstvené testovanie pre systémy kritické pre činnosť organizácie alebo systémy vystavené internetu vrátane analýzy zloženia softvéru pre knižnice tretích strán, statickej a dynamickej analýzy, penetračného testovania, validácie modelovania hrozieb, testovania prípadov zneužitia, fuzzingu a manuálneho exploratívneho testovania.

Krok 23 rieši dodávateľské zmluvy vrátane povinností zachovávať dôvernosť, zodpovedností za riadenie prístupu, technických a organizačných opatrení, lehôt nahlasovania incidentov, práva na audit, kontrol subdodávateľov a ustanovení ku koncu zmluvy.

Praktické poučenie je jednoduché. SBOM patria do riadenia rizík, bezpečného vývoja, testovania, správy a riadenia dodávateľov, reakcie na incidenty a manažérskeho reportingu.

Auditný pohľad: čo budú testovať rôzni preskúmavatelia

Zrelý program SBOM musí obstáť pri rôznych štýloch auditu.

Audítor ISO 27001:2022 začne pri ISMS. Bude sa pýtať, či je riziko dodávateľského reťazca softvéru v rozsahu, či požiadavky zainteresovaných strán zahŕňajú NIS2, zákazníkov DORA, GDPR a zmluvy, či je riziko komponentov súčasťou metodiky rizík, či Vyhlásenie o uplatniteľnosti zahŕňa relevantné kontroly prílohy A a či sú politiky priebežne implementované. Môže vybrať jedno vydanie a sledovať ho od politiky cez pipeline, SBOM, sken zraniteľností, schválenie zmeny, nasadenie a monitorovanie po vydaní.

Preskúmavateľ DORA alebo finančný zákazník sa zameria na prevádzkovú odolnosť a riziko tretích strán v oblasti IKT. Môže sa pýtať, ktoré komponenty podporujú službu používanú finančným subjektom, či služba podporuje kritickú alebo dôležitú funkciu, ako sú dokumentované IKT aktíva a závislosti, či sa monitorujú zraniteľnosti, či ročné testovanie pokrýva kritické systémy a či zmluvy obsahujú asistenciu, práva na audit, oznamovanie incidentov, umiestnenie údajov, subdodávky a podmienky ukončenia.

Posudzovateľ NIST CSF bude hľadať výsledky. V rámci GOVERN bude testovať právnu, regulačnú, zmluvnú správu a riadenie, ako aj správu a riadenie ochrany súkromia a dodávateľov. V rámci IDENTIFY bude očakávať viditeľnosť aktív, softvéru a služieb. V rámci PROTECT bude testovať bezpečný vývoj a kontroly pipeline. V rámci DETECT a RESPOND preskúma upozornenia na zraniteľnosti, analýzu, eskaláciu a komunikáciu. V rámci RECOVER sa bude pýtať, ako kompromitácia komponentu ovplyvňuje obnovu a komunikáciu so zákazníkmi.

Audítor v štýle COBIT alebo ISACA sa zameria na správu a riadenie, zodpovednosť, vlastníctvo rizika, návrh kontrol a spoľahlivosť dôkazov. Môže testovať, či sú SBOM úplné, či sa tikety zraniteľností uzatvárajú podľa politiky, či výnimky expirovali, či sú dôkazy od dodávateľov aktuálne a či manažment dostáva zmysluplné reporty.

Bežné zlyhania SBOM, ktorým sa treba vyhnúť

Programy SBOM zvyčajne zlyhávajú z predvídateľných dôvodov.

Prvým zlyhaním je generovanie SBOM bez ich ukladania ako riadených dôkazov. Ak sa súbor pri každom zostavení prepíše a nemožno ho prepojiť s vydaním, ide o slabý auditný dôkaz.

Druhým zlyhaním je oddelenie SBOM od riadenia zraniteľností. Zoznam komponentov bez triáže, vlastníctva, nápravy alebo akceptácie rizika nepreukazuje prevádzku kontroly.

Tretím zlyhaním je vylúčenie tranzitívnych závislostí. Zraniteľnosti sa často skrývajú pod vrstvou priamych závislostí.

Štvrtým zlyhaním je ponechanie outsourcovaného vývoja mimo procesu. Ak dodávateľ dodá kód bez zverejnenia komponentov, dôkazov o skenovaní alebo záznamov schválenia, dodávateľský reťazec softvéru má neriadené slepé miesto.

Piatym zlyhaním je podpisovanie dodávateľských zmlúv bez práv na dôkazy. Obstarávanie podpíše dohodu, vývojový tím začne používať službu a bezpečnostný tím neskôr zistí, že neexistuje právo na audit, povinnosť zverejniť zraniteľnosť, obmedzenie subdodávateľov ani podpora pri ukončení.

Šiestym zlyhaním je nezmapovanie komponentov na podnikové služby. Zraniteľný balík znamená málo, kým neviete, či ovplyvňuje autentifikáciu, platby, reportovanie, údaje pacientov, správu cloudu, nástup zákazníkov alebo regulovaný finančný pracovný tok.

Siedmym zlyhaním je skrývanie nevyriešených kritických zraniteľností pred vedením. NIS2 aj DORA výslovne stanovujú zodpovednosť manažmentu. Kritické riziko komponentov má byť viditeľné vo fórach správy a riadenia, nie ukryté v backlogoch vývojového tímu.

Ako vyzerá dobrý stav v roku 2026

Program SBOM pripravený na audit má viditeľné znaky.

Existuje schválená politika vyžadujúca, aby komponenty tretích strán a open-source komponenty boli schválené, sledované, skenované a preskúmavané. CI/CD pipeline automaticky vytvára SBOM. SCA skeny sa spúšťajú pred nasadením a počas behu aplikácie, ak je to relevantné. Kritické zraniteľnosti spúšťajú definovanú eskaláciu. Výnimky majú vlastníkov, dátumy expirácie, kompenzačné kontroly a akceptáciu rizika.

Dodávateľské zmluvy obsahujú bezpečnostné povinnosti, lehoty oznámenia porušenia ochrany osobných údajov, práva na audit, kontroly subdodávok a ustanovenia o ukončení. Kritickí dodávatelia sa preskúmavajú aspoň raz ročne. Riziká závislosti od dodávateľov a koncentrácie sú viditeľné. Tímy outsourcovaného vývoja dodržiavajú rovnaké pravidlá bezpečného vývoja a schvaľovania komponentov ako interné tímy.

Manažérsky reporting prepája technické riziko s vplyvom na činnosť organizácie:

• Kritické zraniteľné komponenty podľa produktu
• Expozícia podľa zákazníka alebo regulovanej služby
• Otvorená náprava po prekročení SLA
• Komponenty bez schváleného zdroja
• Nepodporované knižnice alebo knižnice na konci životnosti
• Medzery v dôkazoch od dodávateľov
• Výnimky čakajúce na obnovu alebo uzavretie
• Incidenty prepojené so zraniteľnosťami komponentov

Vtedy SBOM prestávajú byť artefaktom súladu a stávajú sa nástrojom riadenia.

Premeňte SBOM na obhájiteľné dôkazy súladu

Keď nabudúce o 07:42 príde upozornenie na kritický komponent, odpoveď nemá znieť: „Potrebujeme dve hodiny, aby sme zistili, kde sa nachádza.“

Má znieť: „Toto je dotknutý komponent, toto sú služby, toto sú zákazníci, toto je hodnotenie rizika, toto je plán nápravy a toto sú dôkazy.“

Clarysec vám môže pomôcť navrhnúť takýto systém kontrol. Pomáhame organizáciám definovať rozsah SBOM v rámci ISMS, mapovať kontroly prílohy A ISO 27001:2022 na očakávania auditov podľa NIS2, DORA, GDPR, NIST CSF 2.0 a štýlu COBIT, implementovať politiky bezpečného vývoja a dodávateľov, vytvárať dôkazové balíky vydaní a pripraviť uistenie pripravené na audit pomocou Zenith Controls a Zenith Blueprint.

Ste pripravení premeniť svoj dodávateľský reťazec softvéru zo zdroja neistoty na dôkaz odolnosti?

Stiahnite si relevantné politiky Clarysec, použite Zenith Blueprint na zoradenie implementácie a Zenith Controls na mapovanie dôkazov naprieč ISO 27001:2022, NIS2, DORA a požiadavkami zákazníckeho uistenia. Kontaktujte Clarysec a začnite cieleným posúdením pripravenosti SBOM, aby ste vybudovali praktický program uistenia dodávateľského reťazca softvéru pripravený na audit.