SBOM pro zajištění souladu s ISO 27001, NIS2 a DORA

Je pátek 07:42, když Amelia, CISO rychle rostoucí FinTech společnosti, obdrží upozornění, které nechce vidět žádný bezpečnostní lídr.

Široce používaný open-source balíček obsahuje kritickou zranitelnost umožňující vzdálené spuštění kódu. Nástroj pro analýzu složení softwaru (SCA) uvádí, že komponenta může být v autentizační službě, možná ve fakturaci a možná také v API wrapperu třetí strany používaném v platebním pracovním postupu. Vývojový tým potřebuje čas na potvrzení. Právní oddělení se ptá, zda již začala běžet oznamovací lhůta podle NIS2. Manažer programu DORA se ptá, zda dotčená služba podporuje kritickou nebo důležitou funkci finančního subjektu. Obchodní tým se ptá, zda to zablokuje obnovu smlouvy. Správní rada klade nejjednodušší a zároveň nejtěžší otázku: „Jsme vystaveni riziku?“

Bez softwarového kusovníku zní poctivá odpověď často: „Zatím nevíme.“

V roce 2026 taková odpověď nepředstavuje pouze technickou mezeru. Je to slabina správy a řízení, smluvní riziko, auditní expozice a u regulovaných subjektů také problém odolnosti. SBOM se posunuly od hygieny DevSecOps k důkazům pro správní radu o zajištění softwarového dodavatelského řetězce, provozování opatření podle ISO/IEC 27001:2022, řízení rizik kybernetické bezpečnosti podle NIS2, řízení třetích stran v oblasti IKT podle DORA, odpovědnosti podle GDPR a zákaznické náležité péči.

Podstatou není jen vygenerovat soubor SBOM. Podstatou je prokázat, že softwarové komponenty jsou identifikovány, schváleny, monitorovány, hodnoceny podle rizika, záplatovány, smluvně řízeny a dohledatelně přiřazeny odpovědným vlastníkům. Právě zde knihovna politik Clarysec, Zenith Blueprint: roadmapa auditora ve 30 krocích a Zenith Controls: průvodce napříč požadavky na soulad proměňují vývojářský artefakt v obhajitelné důkazy o souladu.

Proč jsou SBOM dnes důkazem zajištění softwarového dodavatelského řetězce

SBOM je evidence softwarových komponent, včetně open-source balíčků, komerčních knihoven, verzí, zdrojů, licencí a vztahů mezi závislostmi. Užitečný SBOM pomáhá odpovědět na čtyři otázky, které dnes zajímají regulátory, zákazníky i správní rady:

1. Co je uvnitř našeho softwaru?
2. Kde je nasazen?
3. Je zranitelný, nepodporovaný, nelicencovaný nebo neschválený?
4. Kdo vlastní nápravu, zmírnění nebo přijetí rizika?

Tyto otázky přímo odpovídají moderním právním a regulačním očekáváním.

NIS2 se vztahuje na mnoho středních a velkých subjektů v základních a důležitých odvětvích, včetně digitální infrastruktury, poskytovatelů cloud computingu, poskytovatelů služeb datových center, poskytovatelů řízených služeb (MSP), poskytovatelů řízených bezpečnostních služeb, online tržišť, vyhledávačů, platforem sociálních sítí a některých digitálních poskytovatelů. Může se vztahovat také na základě vnitrostátního určení a odvětvové transpozice. U subjektů v rozsahu působnosti NIS2 vyžaduje, aby řídicí orgány schvalovaly opatření pro řízení rizik kybernetické bezpečnosti a dohlížely na jejich zavádění. Article 21 zahrnuje zabezpečení dodavatelského řetězce, bezpečné pořizování, bezpečný vývoj a údržbu, zvládání a oznamování zranitelností, zvládání incidentů, kontinuitu činností, správu aktiv, řízení přístupu, kryptografii, posuzování účinnosti a kybernetickou hygienu.

DORA, použitelný od 17. ledna 2025, zavádí jednotný rámec EU pro digitální provozní odolnost finančních subjektů. Pokrývá řízení rizik v oblasti IKT, hlášení incidentů souvisejících s IKT, testování odolnosti, řízení rizik třetích stran v oblasti IKT, smluvní ujednání a dohled nad kritickými poskytovateli služeb IKT z řad třetích stran. DORA očekává, že finanční subjekty budou identifikovat aktiva IKT, podnikové funkce podporované IKT, závislosti, propojení, zranitelnosti, rizikové scénáře, změny a procesy podporované třetími stranami.

GDPR přidává vrstvu ochrany soukromí. Pokud zranitelná komponenta ovlivňuje systémy zpracovávající osobní údaje, otázka zní, zda k osobním údajům mohlo být přistoupeno, zda mohly být změněny, ztraceny, zpřístupněny nebo jinak kompromitovány. Správci a zpracovatelé potřebují důkazy prokazující, že dokážou identifikovat dotčené systémy, toky dat, dílčí zpracovatele a dopad porušení zabezpečení.

NIST CSF 2.0 posiluje stejný provozní model prostřednictvím funkcí GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. Jeho výsledky pro dodavatelský řetězec očekávají odpovědnosti dodavatelů, kritičnost, smluvní požadavky, náležitou péči, monitorování, plánování incidentů a ustanovení pro ukončení vztahu.

Když se správní rada Amelie zeptá, zda je FinTech vystaven riziku, organizace opřená o SBOM dokáže odpovědět důkazy:

• Které produkty a vydání obsahují zranitelnou komponentu
• Která nasazená prostředí jsou dotčena
• Kteří zákazníci, regiony, funkce a toky dat jsou propojeny
• Který dodavatel nebo interní vlastník je odpovědný
• Která kompenzační opatření jsou aktivní
• Zda mohou být dosaženy prahové hodnoty podle NIS2, DORA, GDPR nebo smluv
• Která oprava, zmírnění, výjimka nebo přijetí rizika byly schváleny

To je rozdíl mezi seznamem komponent a systémem řízení.

ISO 27001:2022 je páteří správy SBOM

ISO/IEC 27001:2022 je silným základem pro správu SBOM, protože jde o normu systému řízení, nikoli jen o technický kontrolní seznam. Její kapitoly vyžadují, aby organizace definovaly kontext, zainteresované strany, rozsah, závazek vedení, politiku, role, posouzení rizik, ošetření rizik, cíle, hodnocení výkonnosti, interní audit, přezkoumání vedením a neustálé zlepšování.

Programy SBOM selhávají, když stojí mimo ISMS. Vývoj může generovat soubory, ale nikdo nevynucuje SLA pro nápravu zranitelností, povinnosti dodavatelů, uchovávání důkazů, přijetí rizika ani pravidla zpřístupnění zákazníkům. ISO 27001 to řeší tím, že SBOM začleňuje do systému řízení rizik organizace.

Podle kapitol 4.1 až 4.4 organizace určuje interní a externí otázky, požadavky zainteresovaných stran, právní a regulační povinnosti, smluvní očekávání a rozsah ISMS. Pro zajištění SBOM má rozsah výslovně zahrnovat:

• Produkty a služby dodávané zákazníkům
• Produkční cloudová a SaaS prostředí
• CI/CD pipeline, repozitáře zdrojového kódu a registry artefaktů
• Open-source a komerční softwarové komponenty
• Outsourcovaný vývoj a integrační partnery
• Poskytovatele IKT z řad třetích stran a subdodavatele
• Požadavky zákazníků na bezpečnost podle DORA, NIS2, GDPR a smluv

Kapitoly 5.1 až 5.3 činí z rizika softwarového dodavatelského řetězce téma pro vedení. Vedení musí sladit bezpečnostní cíle se strategickým směřováním organizace, zajistit zdroje, přiřadit odpovědnosti a komunikovat politiku. Kapitoly 6.1.2 a 6.1.3 převádějí zjištění ze SBOM na důkazy pro posouzení rizik a ošetření rizik. Kritická zranitelná komponenta v internetově dostupné autentizační službě není jen tiket. Je to rizikový scénář ovlivňující důvěrnost, integritu, dostupnost, smluvní závazky, regulační oznámení a provozní odolnost.

Nejrelevantnější opatření přílohy A ISO/IEC 27001:2022 pro zajištění SBOM jsou:

Clarysec mapuje tyto vztahy prostřednictvím atributů ISO/IEC 27002:2022 v Zenith Controls. Například Zenith Controls zachází s opatřením ISO/IEC 27002:2022 5.21 „Řízení bezpečnosti informací v dodavatelském řetězci IKT“ jako s preventivním opatřením chránícím důvěrnost, integritu a dostupnost, sladěným s konceptem kybernetické bezpečnosti Identify a působícím napříč doménami správy, ekosystému a ochrany. Opatření 8.25 „Životní cyklus bezpečného vývoje“ chápe jako preventivní a sladěné s Protect. Opatření 8.8 „Řízení technických zranitelností“ chápe jako preventivní a sladěné s Identify a Protect, čímž propojuje řízení zranitelností se správou, ekosystémem, ochranou a obranou.

Tento převod je důležitý, protože různí hodnotitelé kladou různé otázky. Auditor ISO se může ptát, zda je riziko komponent zahrnuto v Prohlášení o použitelnosti. Hodnotitel DORA se může ptát, zda komponenta podporuje kritickou nebo důležitou funkci. Zákazník se může ptát, zda nevyřešené zranitelnosti překračují smluvní SLA. Stejné důkazy SBOM mohou podpořit všechny tři požadavky, pokud jsou správně řízeny.

Vrstva politik Clarysec pro auditně připravené SBOM

Spolehlivý program SBOM potřebuje jazyk politik. Vývojáři musí vědět, co se musí zaznamenávat. Nákup musí vědět, co musí poskytovat dodavatelé. Bezpečnost musí vědět, která zjištění spouštějí eskalaci. Funkce compliance musí vědět, které důkazy se musí uchovávat.

Pro menší organizace vytváří Politika bezpečného vývoje - SME minimální životaschopné opatření SBOM:

GM nebo určený vývojář musí vést seznam všech použitých externích komponent, včetně: 6.6.2.1 Verze a zdroj 6.6.2.2 Známé zranitelnosti nebo stav záplaty 6.6.2.3 Datum poslední aktualizace nebo přezkumu

Tento požadavek je jednoduchý, ale silný. Zavádí viditelnost verzí, dohledatelnost zdrojů, stav zranitelností a periodicitu přezkumu.

Politika požadavků na zabezpečení aplikací - SME přidává přezkum životního cyklu:

Jakýkoli nástroj třetí strany, plugin nebo externí knihovna kódu použitá v aplikaci musí být zaznamenána a každoročně přezkoumána z hlediska bezpečnostního dopadu a stavu záplat.

Politika řízení zranitelností a záplat - SME propojuje SBOM s nápravou:

Vývojáři musí monitorovat a aktualizovat knihovny třetích stran (např. open-source balíčky)

Pro podniková prostředí zvyšuje Politika bezpečného vývoje očekávání:

Používání open-source kódu nebo kódu třetích stran musí být schváleno, sledováno a validováno prostřednictvím:

Zároveň stanoví povinnost skenování:

Všechny komponenty třetích stran musí být před nasazením a během běhu aplikace skenovány na zranitelnosti pomocí automatizovaných nástrojů.

Outsourcovaný vývoj musí dodržovat stejný standard. Politika outsourcovaného vývoje vyžaduje:

Bezpečné používání open-source knihoven, podmíněné skenováním zranitelností a schválením

Smlouvy s dodavateli potřebují vymahatelná práva na důkazy. Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME vyžaduje smluvní doložky pokrývající důvěrnost, bezpečnostní povinnosti, lhůty pro oznamování porušení zabezpečení, práva na audit, omezení subdodávek a bezpečné ukončení:

Smlouvy musí obsahovat povinné doložky pokrývající: 5.3.1 Důvěrnost a mlčenlivost 5.3.2 Povinnosti v oblasti bezpečnosti informací 5.3.3 Lhůty pro oznámení porušení zabezpečení dat (např. do 24–72 hodin) 5.3.4 Práva na audit nebo dostupnost důkazů o souladu 5.3.5 Omezení dalšího subdodavatelského plnění bez schválení 5.3.6 Podmínky ukončení včetně bezpečného vrácení nebo zničení dat

Pro podnikové zákazníky obsahuje Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran:

Práva na audit, kontrolu a vyžádání bezpečnostních důkazů

Pokud poskytovatel SaaS, partner outsourcovaného vývoje nebo komerční dodavatel softwaru neposkytne bezpečnostní důkazy, stav zranitelností, závazky k oznamování nebo přístup k auditu, zajištění vašeho softwarového dodavatelského řetězce má slepé místo.

Politika řízení rizik závislostí na dodavatelích převádí koncentraci závislostí na měřitelné riziko odolnosti:

Registr závislostí na dodavatelích: VMO musí udržovat aktuální registr všech kritických dodavatelů, včetně údajů, jako jsou poskytované služby/produkty; zda je dodavatel jediným zdrojem; dostupní alternativní dodavatelé nebo zastupitelnost; aktuální smluvní podmínky; a posouzení dopadu, pokud by dodavatel selhal nebo byl kompromitován. Registr musí jasně identifikovat dodavatele s vysokou mírou závislosti (např. ty, pro které neexistuje rychlá alternativa).

Tento registr má být propojen se SBOM. Pokud kritická knihovna pochází od dodavatele jako jediného zdroje, podporuje regulovaný zákaznický pracovní postup a nemá rychlou náhradu, nejde jen o balíček. Je to závislost ovlivňující odolnost.

Od souboru SBOM k provoznímu opatření během jednoho sprintu

Praktický program SBOM má začít jednou produktovou řadou a jedním produkčním prostředím. Nepokoušejte se první den evidovat celý podnik. Pokud Amelia ve své FinTech společnosti začne onboardingem zákazníků a platebním pracovním postupem, tým může před škálováním vytvořit opakovatelný model důkazů.

Krok 1: Definujte rozsah SBOM v rámci ISMS

Vytvořte prohlášení o rozsahu propojené s rozsahem ISMS a regulačními faktory:

• Produkt: SaaS platforma pro onboarding zákazníků a platby
• Prostředí: produkce v EU
• Repozitáře: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Systémy sestavení: poskytovatel Git, CI/CD platforma, registr kontejnerů
• Nasazení: Kubernetes cluster, spravovaná databáze, objektové úložiště
• Data: údaje o účtech, logy autentizace, fakturační metadata, platební reference
• Zákazníci: finanční subjekty EU a komerční zákazníci
• Regulační faktory: ISO 27001:2022, zákaznické ujištění podle NIS2, náležitá péče vůči třetím stranám v oblasti IKT podle DORA, odpovědnost za zabezpečení podle GDPR

To je v souladu s logikou rozsahu podle kapitoly 4 ISO 27001 a vymezováním profilu NIST CSF.

Krok 2: Generujte a ukládejte SBOM při sestavení

Nakonfigurujte CI/CD pipeline tak, aby generovaly SBOM pro každý artefakt sestavení, včetně obrazů kontejnerů. Běžně se používají standardní formáty jako CycloneDX a SPDX. Každý SBOM uložte do řízeného repozitáře důkazů propojeného s ID sestavení, hashem commitu, záznamem o nasazení a verzí vydání.

To přímo podporuje požadavek Politiky bezpečného vývoje - SME vést verzi, zdroj, známou zranitelnost nebo stav záplaty a datum přezkumu.

Krok 3: Obohaťte data SBOM o zneužitelnost a obchodní kontext

Nezastavujte se u seznamu balíčků. Přidejte kontext provozního rizika:

• Je komponenta zranitelná?
• Je zranitelná funkce dosažitelná?
• Je služba dostupná z internetu?
• Zpracovává služba osobní údaje?
• Podporuje kritickou nebo důležitou funkci zákazníka podle DORA?
• Je k dispozici záplata?
• Existuje kompenzační opatření?
• Schválil přijetí rizika vlastník rizika?

Kritické CVE v balíčku používaném pouze pro testování se liší od kritického CVE v produkční autentizační službě. Kapitoly ISO 27001 pro posouzení a ošetření rizik pomáhají tento rozdíl obhájit.

Krok 4: Propojte SBOM s kontrolami dodavatelů a outsourcovaného vývoje

Pokud komponentu poskytuje komerční dodavatel nebo partner outsourcovaného vývoje, aktualizujte záznam dodavatele:

To podporuje zabezpečení dodavatelského řetězce podle NIS2 Article 21 a očekávání DORA Article 28 v oblasti strategie rizik třetích stran v oblasti IKT, náležité péče, smluvních ochranných opatření, registrů informací, plánování auditů, práv na ukončení a strategií odchodu.

Krok 5: Definujte pravidla nápravy a důkazy

Svažte SLA nápravy s dopadem na činnost, nikoli pouze se skóre CVSS.

Právě zde se SBOM stávají užitečnými pro NIS2, DORA a GDPR. Pracovní postup nápravy má zohlednit potenciál významného incidentu, dopad závažného incidentu souvisejícího s IKT, kritéria porušení zabezpečení osobních údajů, smluvní oznamovací povinnosti a dopad na provozní odolnost.

Krok 6: Přidejte bránu vydání

Před nasazením vyžadujte, aby pipeline nebo proces změny potvrdil:

• SBOM byl úspěšně vygenerován
• Nezůstávají žádné neschválené kritické zranitelnosti
• Nové komponenty třetích stran jsou schváleny
• Politika licencí byla splněna
• SCA, SAST, DAST nebo jiné požadované testování je dokončeno
• Tiket změny je propojen
• Pro vysoce riziková vydání je zdokumentován plán vrácení změn

To propojuje A.8.25 bezpečný vývoj, A.8.29 bezpečnostní testování a A.8.32 řízení změn do jednoho auditovatelného pracovního postupu.

Krok 7: Vytvořte balíček důkazů vydání

Pro každé vydání uchovávejte:

• Soubor SBOM
• ID sestavení a hash commitu
• Výstup skenování SCA
• Záznam triáže zranitelností
• Schválené výjimky
• Schválení změny
• Záznam o nasazení
• Výsledky testů
• Důkazy od dodavatele, pokud jsou relevantní
• Záznam incidentu nebo problému, pokud vydání napravovalo zranitelnost

Když se auditor zeptá, jak jsou v produkci řízeny knihovny třetích stran, tým Amelie nehledá ve vláknech Slacku. Otevře balíček důkazů vydání.

Mapování napříč požadavky: jeden program SBOM, mnoho povinností

Komerční hodnota programu SBOM roste, když je jednou zmapován a opakovaně používán napříč frameworky. Přístup Clarysec k požadavkům napříč rámci eliminuje duplicitní práci tím, že stejné důkazy převádí do různých jazyků ujištění.

Hlášení incidentů podle NIS2 může probíhat rychle, pokud zneužití způsobí nebo může způsobit závažné narušení provozu, finanční ztrátu nebo značnou hmotnou či nehmotnou újmu. NIS2 používá postupné hlášení, včetně včasného varování do 24 hodin od zjištění, oznámení incidentu do 72 hodin a závěrečné zprávy do jednoho měsíce od oznámení incidentu. SBOM pomáhají určit, zda je dotčená komponenta přítomna, zda jsou ovlivněny zákaznické služby a zda je pravděpodobný přeshraniční dopad.

DORA používá strukturovaný životní cyklus incidentů v oblasti IKT, včetně detekce, záznamu, klasifikace, analýzy kořenové příčiny, eskalace, komunikačních plánů, eskalace na řídicí orgán a regulačního oznámení závažných incidentů souvisejících s IKT. Důkazy SBOM podporují klasifikaci, protože propojují zranitelnou komponentu s dotčenými klienty, nedostupností, geografickým rozsahem, ztrátami dat, kritičností služby a ekonomickým dopadem.

NIST CSF 2.0 přidává užitečný jazyk pro zákaznické ujištění. Zenith Controls mapuje A.5.21 na výsledky správy dodavatelského řetězce, jako je GV.SC-05, kde jsou požadavky na kybernetickou bezpečnost dodavatelů stanoveny, komunikovány a začleněny do smluv a dalších dohod. Požadování SBOM, oznamování zranitelností, auditních důkazů a lhůt nápravy se stává smluvním opatřením, nikoli ad hoc žádostí.

Jak Zenith Blueprint řadí práci

Zenith Blueprint převádí jazyk opatření do implementační roadmapy.

Ve fázi řízení rizik krok 14 propojuje bezpečný vývoj, kontroly CI/CD, skenování závislostí, řízení změn, zvládání incidentů a školení vývojářů. Ve fázi Opatření v praxi krok 20 výslovně řeší komponenty třetích stran a open-source komponenty:

Toto opatření se vztahuje také na komponenty třetích stran a open-source komponenty. Spoléhání se na externí knihovny je standardní praxe, ale každé jejich zařazení je rozhodnutím o důvěře. Vývojáři mají hodnotit závislosti podle reputace, frekvence údržby, známých zranitelností a licenčních omezení. Nástroje jako SBOM (Software Bill of Materials) jsou stále důležitější pro sledování toho, co je vloženo ve vašem stacku.

Krok 21 rámuje bezpečnostní testování jako řízené kontextem a doporučuje vícevrstvé testování pro kritické pro podnikání nebo internetově vystavené systémy, včetně analýzy složení softwaru pro knihovny třetích stran, statické a dynamické analýzy, penetračního testování, validace modelování hrozeb, testování případů zneužití, fuzzingu a manuálního exploračního testování.

Krok 23 řeší smlouvy s dodavateli, včetně povinností zachování důvěrnosti, odpovědností za řízení přístupu, technických a organizačních opatření, lhůt hlášení incidentů, práva na audit, kontrol subdodavatelů a ustanovení pro konec smlouvy.

Praktické poučení je jednoduché. SBOM patří do řízení rizik, bezpečného vývoje, testování, správy dodavatelů, reakce na incidenty a reportingu vedení.

Auditní pohled: co budou různí hodnotitelé testovat

Vyspělý program SBOM musí obstát v různých stylech auditu.

Auditor ISO 27001:2022 začne u ISMS. Bude se ptát, zda je riziko softwarového dodavatelského řetězce v rozsahu, zda požadavky zainteresovaných stran zahrnují NIS2, zákazníky DORA, GDPR a smlouvy, zda je riziko komponent součástí metodiky rizik, zda Prohlášení o použitelnosti obsahuje relevantní opatření přílohy A a zda jsou politiky průběžně zaváděny. Může vybrat jedno vydání a sledovat ho od politiky přes pipeline, SBOM, sken zranitelností, schválení změny, nasazení až po monitorování po vydání.

Hodnotitel DORA nebo finanční zákazník se zaměří na provozní odolnost a riziko třetích stran v oblasti IKT. Může se ptát, které komponenty podporují službu používanou finančním subjektem, zda služba podporuje kritickou nebo důležitou funkci, jak jsou dokumentována aktiva a závislosti IKT, zda jsou zranitelnosti monitorovány, zda každoroční testování pokrývá kritické systémy a zda smlouvy obsahují podporu, práva na audit, oznamování incidentů, umístění dat, subdodávky a podmínky ukončení.

Hodnotitel NIST CSF bude hledat výsledky. V rámci GOVERN bude testovat právní, regulační, smluvní, soukromí a správu dodavatelského řetězce. V rámci IDENTIFY bude očekávat viditelnost aktiv, softwaru a služeb. V rámci PROTECT bude testovat bezpečný vývoj a kontroly pipeline. V rámci DETECT a RESPOND bude zkoumat upozornění na zranitelnosti, analýzu, eskalaci a komunikaci. V rámci RECOVER se zeptá, jak kompromitace komponenty ovlivňuje obnovu a komunikaci se zákazníky.

Auditor ve stylu COBIT nebo ISACA se zaměří na správu a řízení, odpovědnost, vlastnictví rizik, návrh opatření a spolehlivost důkazů. Může testovat, zda jsou SBOM úplné, zda se tikety zranitelností uzavírají v souladu s politikou, zda výjimky expirují, zda jsou důkazy od dodavatelů aktuální a zda vedení dostává smysluplný reporting.

Častá selhání SBOM, kterým je třeba se vyhnout

Programy SBOM obvykle selhávají z předvídatelných důvodů.

Prvním selháním je generování SBOM bez jejich ukládání jako řízených důkazů. Pokud se soubor při každém sestavení přepíše a nelze jej propojit s vydáním, jde o slabý auditní důkaz.

Druhým selháním je oddělení SBOM od řízení zranitelností. Seznam komponent bez triáže, vlastnictví, nápravy nebo přijetí rizika neprokazuje fungování opatření.

Třetím selháním je vyloučení tranzitivních závislostí. Zranitelnosti se často skrývají pod vrstvou přímých závislostí.

Čtvrtým selháním je ponechání outsourcovaného vývoje mimo proces. Pokud dodavatel dodává kód bez zpřístupnění komponent, důkazů o skenování nebo záznamů o schválení, softwarový dodavatelský řetězec má neřízené slepé místo.

Pátým selháním je uzavírání smluv s dodavateli bez práv na důkazy. Nákup podepíše smlouvu, vývoj začne službu používat a bezpečnost později zjistí, že neexistuje právo na audit, povinnost oznamovat zranitelnosti, omezení subdodavatelů ani podpora při ukončení.

Šestým selháním je nepropojení komponent s obchodními službami. Zranitelný balíček znamená málo, dokud nevíte, zda ovlivňuje autentizaci, platby, reporting, data pacientů, správu cloudu, onboarding zákazníků nebo regulovaný finanční pracovní postup.

Sedmým selháním je skrývání nevyřešených kritických zranitelností před vedením. NIS2 i DORA výslovně stanoví odpovědnost vedení. Kritické riziko komponent má být viditelné ve fórech správy a řízení, nikoli pohřbené v backlogu vývoje.

Jak vypadá dobrý stav v roce 2026

Auditně připravený program SBOM má viditelné znaky.

Existuje schválená politika vyžadující, aby komponenty třetích stran a open-source komponenty byly schvalovány, sledovány, skenovány a přezkoumávány. CI/CD pipeline automaticky generuje SBOM. Skeny SCA běží před nasazením a tam, kde je to relevantní, i za běhu. Kritické zranitelnosti spouštějí definovanou eskalaci. Výjimky mají vlastníky, data expirace, kompenzační opatření a přijetí rizika.

Smlouvy s dodavateli obsahují bezpečnostní povinnosti, lhůty pro oznamování porušení zabezpečení, práva na audit, kontroly subdodavatelů a ustanovení o ukončení. Kritičtí dodavatelé jsou přezkoumáváni alespoň jednou ročně. Rizika závislosti na dodavatelích a koncentrace jsou viditelná. Týmy outsourcovaného vývoje dodržují stejná pravidla bezpečného vývoje a schvalování komponent jako interní týmy.

Reporting vedení propojuje technické riziko s dopadem na činnost:

• Kritické zranitelné komponenty podle produktu
• Expozice podle zákazníka nebo regulované služby
• Otevřená náprava po SLA
• Komponenty bez schváleného zdroje
• Nepodporované knihovny nebo knihovny po ukončení životního cyklu
• Mezery v důkazech od dodavatelů
• Výjimky čekající na obnovení nebo uzavření
• Incidenty propojené se zranitelnostmi komponent

Tehdy SBOM přestávají být artefaktem souladu a stávají se nástrojem řízení.

Proměňte SBOM v obhajitelné důkazy o souladu

Až příště v 07:42 dorazí upozornění na kritickou komponentu, odpověď nemá znít: „Potřebujeme dvě hodiny, abychom zjistili, kde je.“

Má znít: „Zde je dotčená komponenta, zde jsou služby, zde jsou zákazníci, zde je hodnocení rizika, zde je plán nápravy a zde jsou důkazy.“

Clarysec vám může pomoci navrhnout takový systém řízení. Pomáháme organizacím definovat rozsah SBOM v rámci ISMS, mapovat opatření přílohy A ISO 27001:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 a auditorská očekávání ve stylu COBIT, zavádět politiky bezpečného vývoje a dodavatelů, vytvářet balíčky důkazů vydání a připravovat auditně připravené ujištění pomocí Zenith Controls a Zenith Blueprint.

Jste připraveni proměnit svůj softwarový dodavatelský řetězec ze zdroje nejistoty v důkaz odolnosti?

Stáhněte si relevantní politiky Clarysec, použijte Zenith Blueprint k seřazení implementace a Zenith Controls k mapování důkazů napříč ISO 27001:2022, NIS2, DORA a požadavky zákaznického ujištění. Kontaktujte Clarysec a začněte cíleným posouzením připravenosti SBOM, na jehož základě vybudujete praktický, auditně připravený program zajištění softwarového dodavatelského řetězce.