SBOM kaip ISO 27001, NIS2 ir DORA užtikrinimo įrodymai

Penktadienį 07:42 Amelia, sparčiai augančios fintech įmonės vyriausioji informacijos saugumo vadovė (CISO), gauna įspėjimą, kurio nenori matyti nė vienas saugumo vadovas.

Plačiai naudojamame atvirojo kodo pakete nustatytas kritinis nuotolinio kodo vykdymo pažeidžiamumas. Programinės įrangos sudėties analizė (SCA) rodo, kad komponentas gali būti autentifikavimo paslaugoje, galbūt atsiskaitymų modulyje ir, tikėtina, trečiosios šalies API integraciniame komponente, naudojamame mokėjimų darbo eigoje. Inžinerijos komandai reikia laiko tai patvirtinti. Teisininkai klausia, ar jau pradėjo tiksėti NIS2 pranešimo terminas. DORA programos vadovas klausia, ar paveikta paslauga palaiko finansų subjekto kritinę arba svarbią funkciją. Pardavimų komanda klausia, ar tai blokuos sutarties pratęsimą. Valdyba užduoda paprasčiausią ir sunkiausią klausimą: „Ar esame paveikti?“

Be programinės įrangos komponentų sąrašo sąžiningas atsakymas dažnai būna: „Dar nežinome.“

2026 m. toks atsakymas nebėra vien techninė spraga. Tai valdysenos silpnybė, sutartinė rizika, audito rizika ir, reglamentuojamiems subjektams, atsparumo problema. SBOM iš DevSecOps higienos priemonės tapo valdybos lygmens programinės įrangos tiekimo grandinės užtikrinimo, ISO/IEC 27001:2022 kontrolės priemonių veikimo, NIS2 kibernetinio saugumo rizikos valdymo, DORA IRT trečiųjų šalių valdysenos, GDPR atskaitomybės ir klientų deramo patikrinimo įrodymais.

Svarbiausia ne vien sugeneruoti SBOM failą. Svarbiausia pagrįsti, kad programinės įrangos komponentai yra identifikuoti, patvirtinti, stebimi, įvertinti pagal riziką, ištaisyti, sutartiškai valdomi ir atsekami iki atskaitingų savininkų. Būtent čia Clarysec politikų biblioteka, Zenith Blueprint: auditoriaus 30 žingsnių gairės ir Zenith Controls: kryžminės atitikties vadovas kūrėjų artefaktą paverčia pagrįstais atitikties įrodymais.

Kodėl SBOM dabar yra programinės įrangos tiekimo grandinės užtikrinimo įrodymai

SBOM yra programinės įrangos komponentų inventorius, apimantis atvirojo kodo paketus, komercines bibliotekas, versijas, šaltinius, licencijas ir priklausomybių ryšius. Naudingas SBOM padeda atsakyti į keturis klausimus, kurie dabar rūpi reguliuotojams, klientams ir valdyboms:

1. Kas yra mūsų programinėje įrangoje?
2. Kur tai įdiegta?
3. Ar tai pažeidžiama, nebepalaikoma, nelicencijuota arba nepatvirtinta?
4. Kas atsakingas už taisomuosius veiksmus, rizikos mažinimą arba rizikos priėmimą?

Šie klausimai tiesiogiai siejasi su šiuolaikiniais teisiniais ir reglamentavimo lūkesčiais.

NIS2 taikoma daugeliui vidutinių ir didelių subjektų esminiuose ir svarbiuose sektoriuose, įskaitant skaitmeninę infrastruktūrą, debesijos paslaugų teikėjus, duomenų centrų paslaugų teikėjus, valdomų paslaugų teikėjus (MSP), valdomų saugumo paslaugų teikėjus, internetines prekyvietes, paieškos sistemas, socialinių tinklų platformas ir tam tikrus skaitmeninių paslaugų teikėjus. Ji taip pat gali būti taikoma pagal nacionalinį priskyrimą ir sektoriui būdingą perkėlimą į nacionalinę teisę. Į taikymo sritį patenkantiems subjektams NIS2 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones ir prižiūrėtų jų įgyvendinimą. Article 21 apima tiekimo grandinės saugumą, saugų įsigijimą, saugų kūrimą ir priežiūrą, pažeidžiamumų tvarkymą ir atskleidimą, incidentų valdymą, veiklos tęstinumą, turto valdymą, prieigos kontrolę, kriptografiją, veiksmingumo vertinimą ir kibernetinę higieną.

DORA, taikomas nuo 2025 m. sausio 17 d., nustato vienodą ES skaitmeninės veiklos atsparumo sistemą finansų subjektams. Jis apima IRT rizikos valdymą, su IRT susijusių incidentų pranešimą, atsparumo testavimą, IRT trečiųjų šalių rizikos valdymą, sutartinius susitarimus ir kritinių IRT trečiųjų šalių paslaugų teikėjų priežiūrą. DORA tikisi, kad finansų subjektai identifikuos IRT turtą, IRT palaikomas verslo funkcijas, priklausomybes, tarpusavio sąsajas, pažeidžiamumus, rizikos scenarijus, pakeitimus ir trečiųjų šalių palaikomus procesus.

GDPR prideda privatumo sluoksnį. Jei pažeidžiamas komponentas veikia sistemas, tvarkančias asmens duomenis, klausimas tampa toks: ar asmens duomenys galėjo būti pasiekti, pakeisti, prarasti, atskleisti arba kitaip kompromituoti. Valdytojams ir tvarkytojams reikia įrodymų, rodančių, kad jie gali identifikuoti paveiktas sistemas, duomenų srautus, subtvarkytojus ir pažeidimo poveikį.

NIST CSF 2.0 tą patį veiklos modelį sustiprina per GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER. Tiekimo grandinės rezultatai numato tiekėjų atsakomybes, kritiškumą, sutartinius reikalavimus, deramą rūpestingumą, stebėseną, incidentų planavimą ir santykių pabaigos nuostatas.

Kai Amelia valdyba klausia, ar fintech įmonė yra paveikta, SBOM besiremianti organizacija gali atsakyti įrodymais:

• Kurie produktai ir išleidimai turi pažeidžiamą komponentą
• Kurios įdiegtos aplinkos yra paveiktos
• Kurie klientai, regionai, funkcijos ir duomenų srautai yra susiję
• Kuris tiekėjas arba vidinis savininkas yra atskaitingas
• Kurios kompensuojančios kontrolės priemonės yra aktyvios
• Ar gali būti pasiekti NIS2, DORA, GDPR arba sutartiniai slenksčiai
• Koks pataisymas, rizikos mažinimas, išimtis arba rizikos priėmimas yra patvirtintas

Tai ir yra skirtumas tarp komponentų sąrašo ir kontrolės sistemos.

ISO 27001:2022 yra SBOM valdysenos pagrindas

ISO/IEC 27001:2022 yra tvirtas SBOM valdysenos pagrindas, nes tai valdymo sistemos standartas, o ne vien techninis kontrolinis sąrašas. Jo punktai reikalauja, kad organizacijos apibrėžtų kontekstą, suinteresuotąsias šalis, taikymo sritį, vadovybės įsipareigojimą, politiką, vaidmenis, rizikos vertinimą, rizikos tvarkymą, tikslus, veiklos rezultatų vertinimą, vidaus auditą, vadovybės peržiūrą ir nuolatinį tobulinimą.

SBOM programos žlunga, kai jos veikia už ISVS ribų. Inžinerijos komanda gali generuoti failus, tačiau niekas neužtikrina pažeidžiamumų taisymo SLA, tiekėjų įsipareigojimų, įrodymų saugojimo, rizikos priėmimo ar klientų informavimo taisyklių. ISO 27001 tai išsprendžia paversdamas SBOM organizacijos rizikos valdymo sistemos dalimi.

Pagal 4.1–4.4 punktus organizacija nustato vidinius ir išorinius veiksnius, suinteresuotųjų šalių reikalavimus, teisines ir reglamentavimo prievoles, sutartinius lūkesčius ir ISVS taikymo sritį. SBOM užtikrinimui taikymo sritis turėtų aiškiai apimti:

• Klientams teikiamus produktus ir paslaugas
• Debesijos ir SaaS produkcines aplinkas
• CI/CD grandines, pirminio kodo saugyklas ir artefaktų registrus
• Atvirojo kodo ir komercinės programinės įrangos komponentus
• Išorės kūrimo ir integracijos partnerius
• IRT trečiųjų šalių paslaugų teikėjus ir subtiekėjus
• Klientų saugumo reikalavimus pagal DORA, NIS2, GDPR ir sutartis

5.1–5.3 punktai programinės įrangos tiekimo grandinės riziką paverčia vadovybės klausimu. Vadovybė turi suderinti saugumo tikslus su veiklos kryptimi, suteikti išteklius, priskirti atsakomybes ir komunikuoti politiką. 6.1.2 ir 6.1.3 punktai SBOM išvadas paverčia rizikos vertinimo ir rizikos tvarkymo įrodymais. Kritinis pažeidžiamas komponentas internetu pasiekiamoje autentifikavimo paslaugoje nėra tik darbo užduotis. Tai rizikos scenarijus, veikiantis konfidencialumą, vientisumą, prieinamumą, sutartinius įsipareigojimus, pranešimą reguliuotojui ir skaitmeninės veiklos atsparumą.

Svarbiausios ISO/IEC 27001:2022 A priedo kontrolės priemonės SBOM užtikrinimui yra:

Clarysec šiuos ryšius susieja per ISO/IEC 27002:2022 atributus Zenith Controls priemonėje. Pavyzdžiui, Zenith Controls ISO/IEC 27002:2022 kontrolės priemonę 5.21 „Informacijos saugumo valdymas IRT tiekimo grandinėje“ vertina kaip prevencinę, saugančią konfidencialumą, vientisumą ir prieinamumą, suderintą su Identify kibernetinio saugumo sąvoka ir veikiančią valdysenos, ekosistemos ir apsaugos srityse. Kontrolės priemonę 8.25 „Saugus programinės įrangos kūrimo gyvavimo ciklas“ ji vertina kaip prevencinę ir suderintą su Protect. Kontrolės priemonę 8.8 „Techninių pažeidžiamumų valdymas“ ji vertina kaip prevencinę ir suderintą su Identify bei Protect, susiedama pažeidžiamumų valdymą su valdysena, ekosistema, apsauga ir gynyba.

Šis susiejimas svarbus, nes skirtingi vertintojai užduoda skirtingus klausimus. ISO auditorius gali klausti, ar komponentų rizika įtraukta į Taikomumo pareiškimą. DORA tikrintojas gali klausti, ar komponentas palaiko kritinę arba svarbią funkciją. Klientas gali klausti, ar neišspręsti pažeidžiamumai viršija sutartinius SLA. Tie patys SBOM įrodymai gali pagrįsti visus tris atvejus, jei jie tinkamai valdomi.

Clarysec politikų sluoksnis auditui tinkamiems SBOM

Patikimai SBOM programai reikia politikos formuluočių. Kūrėjai turi žinoti, ką privaloma registruoti. Pirkimų funkcija turi žinoti, ką privalo pateikti tiekėjai. Saugumo komanda turi žinoti, kurios išvados inicijuoja eskalavimą. Atitikties funkcija turi žinoti, kuriuos įrodymus privaloma saugoti.

Mažesnėms organizacijoms Saugaus kūrimo politika - SME sukuria minimaliai pakankamą SBOM kontrolę:

Generalinis vadovas arba paskirtas kūrėjas privalo tvarkyti visų naudojamų išorinių komponentų sąrašą, įskaitant: 6.6.2.1 Versiją ir šaltinį 6.6.2.2 Žinomus pažeidžiamumus arba pataisų būseną 6.6.2.3 Paskutinio atnaujinimo arba peržiūros datą

Šis reikalavimas paprastas, bet reikšmingas. Jis nustato versijų matomumą, šaltinio atsekamumą, pažeidžiamumų būseną ir peržiūros periodiškumą.

Taikomųjų programų saugumo reikalavimų politika - SME papildo gyvavimo ciklo peržiūrą:

Bet kuri taikomojoje programoje naudojama trečiosios šalies priemonė, papildinys arba išorinė kodo biblioteka turi būti registruojama ir kasmet peržiūrima dėl poveikio saugumui ir pataisų būsenos.

Pažeidžiamumų ir pataisų valdymo politika - SME susieja SBOM su taisomaisiais veiksmais:

Kūrėjai privalo stebėti ir atnaujinti trečiųjų šalių bibliotekas, pvz., atvirojo kodo paketus

Įmonės masto aplinkoms Saugaus kūrimo politika kelia aukštesnį lūkestį:

Atvirojo kodo arba trečiųjų šalių kodo naudojimas turi būti patvirtintas, stebimas ir validuojamas per:

Ji taip pat skenavimą padaro privalomą:

Visi trečiųjų šalių komponentai turi būti skenuojami dėl pažeidžiamumų prieš diegimą ir eksploatacijos metu, naudojant automatizuotas priemones.

Išorės kūrimas turi laikytis to paties standarto. Išorės kūrimo politika reikalauja:

Saugiai naudoti atvirojo kodo bibliotekas, taikant pažeidžiamumų skenavimą ir patvirtinimą

Tiekėjų sutartims reikia įgyvendinamų teisių į įrodymus. Trečiųjų šalių ir tiekėjų saugumo politika - SME reikalauja sutartinių nuostatų, apimančių konfidencialumą, saugumo įsipareigojimus, pranešimų apie pažeidimus terminus, audito teises, subtiekimo apribojimus ir saugų nutraukimą:

Sutartyse turi būti privalomos nuostatos, apimančios: 5.3.1 Konfidencialumą ir neatskleidimą 5.3.2 Informacijos saugumo įsipareigojimus 5.3.3 Pranešimų apie duomenų saugumo pažeidimus terminus, pvz., per 24–72 valandas 5.3.4 Audito teises arba atitikties įrodymų prieinamumą 5.3.5 Tolesnio subtiekimo apribojimus be patvirtinimo 5.3.6 Nutraukimo sąlygas, įskaitant saugų duomenų grąžinimą arba sunaikinimą

Įmonės klientams Trečiųjų šalių ir tiekėjų saugumo politika apima:

Teises audituoti, tikrinti ir prašyti saugumo įrodymų

Jei SaaS teikėjas, išorės kūrimo partneris arba komercinės programinės įrangos tiekėjas nepateikia saugumo įrodymų, pažeidžiamumų būsenos, pranešimo įsipareigojimų arba audito prieigos, jūsų programinės įrangos tiekimo grandinės užtikrinime lieka akloji zona.

Tiekėjų priklausomybės rizikos valdymo politika priklausomybės koncentraciją paverčia išmatuojama atsparumo rizika:

Tiekėjų priklausomybės registras: tiekėjų valdymo funkcija (VMO) privalo tvarkyti atnaujintą visų kritinių tiekėjų registrą, įskaitant tokią informaciją kaip teikiamos paslaugos / produktai; ar tiekėjas yra vienintelis šaltinis; galimi alternatyvūs tiekėjai arba pakeičiamumas; galiojančios sutarties sąlygos; ir poveikio vertinimas, jei tiekėjas nustotų veikti arba būtų kompromituotas. Registre turi būti aiškiai nurodyti didelės priklausomybės tiekėjai, pvz., tie, kuriems nėra greitos alternatyvos.

Šis registras turi būti susietas su SBOM. Jei kritinė biblioteka gaunama iš vienintelio tiekėjo, palaiko reglamentuojamo kliento darbo eigą ir neturi greito pakaitalo, tai nėra tik paketas. Tai atsparumo priklausomybė.

Nuo SBOM failo iki operacinės kontrolės priemonės per vieną sprintą

Praktinė SBOM programa turėtų prasidėti nuo vienos produktų linijos ir vienos produkcinės aplinkos. Nebandykite pirmą dieną inventorizuoti visos įmonės. Jei Amelia fintech įmonė pradeda nuo klientų įvedimo ir mokėjimų darbo eigos, komanda gali sukurti pakartojamą įrodymų modelį prieš plėsdama apimtį.

1 žingsnis. Apibrėžkite SBOM taikymo sritį ISVS viduje

Sukurkite taikymo srities aprašą, susietą su jūsų ISVS taikymo sritimi ir reglamentavimo veiksniais:

• Produktas: klientų įvedimo ir mokėjimų SaaS platforma
• Aplinka: ES produkcinė aplinka
• Saugyklos: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Kūrimo sistemos: Git teikėjas, CI/CD platforma, konteinerių registras
• Diegimas: Kubernetes klasteris, valdoma duomenų bazė, objektinė saugykla
• Duomenys: paskyrų duomenys, autentifikavimo žurnalai, atsiskaitymų metaduomenys, mokėjimų nuorodos
• Klientai: ES finansų subjektai ir komerciniai klientai
• Reglamentavimo veiksniai: ISO 27001:2022, NIS2 klientų užtikrinimas, DORA IRT trečiųjų šalių deramas patikrinimas, GDPR saugumo atskaitomybė

Tai suderinama su ISO 27001 4 punkto taikymo srities logika ir NIST CSF profilio apimties nustatymu.

2 žingsnis. Generuokite ir saugokite SBOM kūrimo metu

Sukonfigūruokite CI/CD grandines taip, kad kiekvienam surinkimo artefaktui, įskaitant konteinerių atvaizdus, būtų generuojamas SBOM. Dažnai naudojami standartiniai formatai, tokie kaip CycloneDX ir SPDX. Kiekvieną SBOM saugokite kontroliuojamoje įrodymų saugykloje, susietoje su surinkimo identifikatoriumi, pakeitimo maišos reikšme, diegimo įrašu ir išleidimo versija.

Tai tiesiogiai palaiko Saugaus kūrimo politika - SME reikalavimą tvarkyti versiją, šaltinį, žinomą pažeidžiamumą arba pataisų būseną ir peržiūros datą.

3 žingsnis. Papildykite SBOM duomenis išnaudojamumo ir verslo kontekstu

Nesustokite ties paketų sąrašu. Pridėkite operacinės rizikos kontekstą:

• Ar komponentas yra pažeidžiamas?
• Ar pažeidžiama funkcija pasiekiama?
• Ar paslauga pasiekiama internetu?
• Ar paslauga tvarko asmens duomenis?
• Ar ji palaiko kritinę arba svarbią funkciją DORA klientui?
• Ar yra pataisa?
• Ar yra kompensuojanti kontrolės priemonė?
• Ar rizikos savininkas patvirtino rizikos priėmimą?

Kritinė CVE tik testavimui skirtame pakete skiriasi nuo kritinės CVE produkcinėje autentifikavimo paslaugoje. ISO 27001 rizikos vertinimo ir tvarkymo punktai padeda šį skirtumą pagrįsti.

4 žingsnis. Susiekite SBOM su tiekėjų ir išorės kūrimo kontrolės priemonėmis

Jei komponentą teikia komercinis tiekėjas arba išorės kūrimo partneris, atnaujinkite tiekėjo įrašą:

Tai palaiko NIS2 Article 21 tiekimo grandinės saugumą ir DORA Article 28 lūkesčius dėl IRT trečiųjų šalių rizikos strategijos, deramo rūpestingumo, sutartinių apsaugos priemonių, informacijos registrų, audito planavimo, nutraukimo teisių ir pasitraukimo strategijų.

5 žingsnis. Apibrėžkite taisomųjų veiksmų taisykles ir įrodymus

Taisomųjų veiksmų SLA susiekite su verslo poveikiu, o ne vien su CVSS balais.

Čia SBOM tampa naudingi NIS2, DORA ir GDPR. Taisomųjų veiksmų darbo eiga turėtų įvertinti reikšmingo incidento potencialą, reikšmingo su IRT susijusio incidento poveikį, asmens duomenų saugumo pažeidimo kriterijus, sutartinius pranešimo įsipareigojimus ir poveikį skaitmeninės veiklos atsparumui.

6 žingsnis. Įtraukite išleidimo vartus

Prieš diegimą reikalaukite, kad CI/CD grandinė arba pakeitimų procesas patvirtintų:

• SBOM sėkmingai sugeneruotas
• Neliko nepatvirtintų kritinių pažeidžiamumų
• Nauji trečiųjų šalių komponentai patvirtinti
• Licencijų politika įvykdyta
• SCA, SAST, DAST arba kitas privalomas testavimas užbaigtas
• Pakeitimo užklausa susieta
• Didelės rizikos išleidimams dokumentuotas grąžinimo į ankstesnę būseną planas

Tai sujungia A.8.25 saugų kūrimą, A.8.29 saugumo testavimą ir A.8.32 pakeitimų valdymą į vieną audituojamą darbo eigą.

7 žingsnis. Sudarykite išleidimo įrodymų paketą

Kiekvienam išleidimui saugokite:

• SBOM failą
• Surinkimo identifikatorių ir pakeitimo maišos reikšmę
• SCA skenavimo išvestį
• Pažeidžiamumų pirminio įvertinimo įrašą
• Patvirtintas išimtis
• Pakeitimo patvirtinimą
• Diegimo įrašą
• Testavimo rezultatus
• Tiekėjo įrodymus, jei taikoma
• Incidento arba problemos įrašą, jei išleidimas pašalino pažeidžiamumą

Kai auditorius klausia, kaip trečiųjų šalių bibliotekos valdomos produkcinėje aplinkoje, Amelia komanda neieško atsakymų Slack gijose. Ji atidaro išleidimo įrodymų paketą.

Kryžminės atitikties susiejimas: viena SBOM programa, daug įsipareigojimų

Komercinė SBOM programos vertė didėja, kai ji vieną kartą susiejama ir pakartotinai naudojama keliose sistemose. Clarysec kryžminės atitikties požiūris padeda išvengti darbo dubliavimo, tuos pačius įrodymus perkeliamas į skirtingas užtikrinimo kalbas.

NIS2 incidentų pranešimas gali vykti greitai, kai išnaudojimas sukelia arba gali sukelti rimtą veiklos sutrikimą, finansinius nuostolius arba didelę materialinę ar nematerialinę žalą. NIS2 taiko etapais vykdomą pranešimą, įskaitant ankstyvąjį įspėjimą per 24 valandas nuo sužinojimo, pranešimą apie incidentą per 72 valandas ir galutinę ataskaitą per vieną mėnesį nuo pranešimo apie incidentą. SBOM padeda nustatyti, ar paveiktas komponentas naudojamas, ar paveiktos klientų paslaugos ir ar tikėtinas tarpvalstybinis poveikis.

DORA taiko struktūrizuotą IRT incidentų gyvavimo ciklą, įskaitant aptikimą, registravimą, klasifikavimą, pagrindinės priežasties analizę, eskalavimą, komunikacijos planus, eskalavimą valdymo organui ir pranešimą reguliuotojui apie reikšmingus su IRT susijusius incidentus. SBOM įrodymai palaiko klasifikavimą, nes susieja pažeidžiamą komponentą su paveiktais klientais, prastova, geografine aprėptimi, duomenų praradimu, paslaugos kritiškumu ir ekonominiu poveikiu.

NIST CSF 2.0 suteikia naudingą kalbą klientų užtikrinimui. Zenith Controls susieja A.5.21 su tiekimo grandinės valdysenos rezultatais, tokiais kaip GV.SC-05, kai kibernetinio saugumo reikalavimai tiekėjams yra nustatyti, komunikuoti ir integruoti į sutartis bei kitus susitarimus. Reikalauti SBOM, pažeidžiamumų atskleidimo, audito įrodymų ir taisomųjų veiksmų terminų tampa sutartine kontrolės priemone, o ne ad hoc prašymu.

Kaip Zenith Blueprint sudėlioja darbų seką

Zenith Blueprint kontrolės priemonių kalbą paverčia įgyvendinimo veiksmų planu.

Rizikos valdymo etape 14 žingsnis susieja saugų kūrimą, CI/CD kontrolės priemones, priklausomybių skenavimą, pakeitimų valdymą, incidentų valdymą ir kūrėjų mokymus. Kontrolės priemonių veikimo etape 20 žingsnis aiškiai kalba apie trečiųjų šalių ir atvirojo kodo komponentus:

Ši kontrolės priemonė taip pat taikoma trečiųjų šalių ir atvirojo kodo komponentams. Naudotis išorinėmis bibliotekomis yra įprasta praktika, tačiau kiekvienas įtraukimas yra pasitikėjimo sprendimas. Kūrėjai turėtų vertinti priklausomybes pagal reputaciją, priežiūros dažnumą, žinomus pažeidžiamumus ir licencijų apribojimus. Tokios priemonės kaip SBOM (programinės įrangos komponentų sąrašai) tampa vis svarbesnės, siekiant sekti, kas įterpta į jūsų technologijų paketą.

21 žingsnis saugumo testavimą pateikia kaip priklausantį nuo konteksto ir rekomenduoja sluoksniuotą testavimą verslui kritinėms arba internetu pasiekiamoms sistemoms, įskaitant programinės įrangos sudėties analizę trečiųjų šalių bibliotekoms, statinę ir dinaminę analizę, įsiskverbimo testavimą, grėsmių modeliavimo validavimą, netinkamo naudojimo scenarijų testavimą, fuzzing ir rankinį tiriamąjį testavimą.

23 žingsnis apima tiekėjų susitarimus, įskaitant konfidencialumo įsipareigojimus, prieigos kontrolės atsakomybes, technines ir organizacines priemones, incidentų pranešimo terminus, teisę atlikti auditą, subtiekėjų kontrolės priemones ir sutarties pabaigos nuostatas.

Praktinė pamoka paprasta. SBOM priklauso rizikos valdymui, saugiam kūrimui, testavimui, tiekėjų valdysenai, reagavimui į incidentus ir vadovybei teikiamoms ataskaitoms.

Audito perspektyva: ką tikrins skirtingi vertintojai

Brandžiai SBOM programai reikia atlaikyti skirtingus audito stilius.

ISO 27001:2022 auditorius pradės nuo ISVS. Jis klaus, ar programinės įrangos tiekimo grandinės rizika patenka į taikymo sritį, ar suinteresuotųjų šalių reikalavimai apima NIS2, DORA klientus, GDPR ir sutartis, ar komponentų rizika yra rizikos metodikos dalis, ar Taikomumo pareiškimas apima atitinkamas A priedo kontrolės priemones ir ar politikos laikui bėgant yra įgyvendinamos. Auditorius gali atrinkti vieną išleidimą ir atsekti jį nuo politikos iki CI/CD grandinės, SBOM, pažeidžiamumų skenavimo, pakeitimo patvirtinimo, diegimo ir stebėsenos po išleidimo.

DORA tikrintojas arba finansų klientas sutelks dėmesį į skaitmeninės veiklos atsparumą ir IRT trečiųjų šalių riziką. Jis gali klausti, kurie komponentai palaiko finansų subjekto naudojamą paslaugą, ar paslauga palaiko kritinę arba svarbią funkciją, kaip dokumentuojamas IRT turtas ir priklausomybės, ar pažeidžiamumai stebimi, ar kasmetinis testavimas apima kritines sistemas ir ar sutartyse numatyta pagalba, audito teisės, pranešimas apie incidentus, duomenų vieta, subtiekimas ir nutraukimo sąlygos.

NIST CSF vertintojas ieškos rezultatų. Pagal GOVERN jis tikrins teisinę, reglamentavimo, sutartinę, privatumo ir tiekimo grandinės valdyseną. Pagal IDENTIFY jis tikėsis turto, programinės įrangos ir paslaugų matomumo. Pagal PROTECT jis tikrins saugų kūrimą ir CI/CD grandinių kontrolės priemones. Pagal DETECT ir RESPOND jis nagrinės pažeidžiamumų įspėjimus, analizę, eskalavimą ir komunikaciją. Pagal RECOVER jis klaus, kaip komponento kompromitavimas veikia atkūrimą ir komunikaciją su klientais.

COBIT arba ISACA stiliaus auditorius sutelks dėmesį į valdyseną, atskaitomybę, rizikos savininkystę, kontrolės priemonių projektavimą ir įrodymų patikimumą. Jis gali tikrinti, ar SBOM yra išsamūs, ar pažeidžiamumų užduotys uždaromos pagal politiką, ar išimtys baigia galioti, ar tiekėjų įrodymai yra aktualūs ir ar vadovybė gauna prasmingas ataskaitas.

Dažnos SBOM klaidos, kurių reikia vengti

SBOM programos paprastai žlunga dėl nuspėjamų priežasčių.

Pirmoji klaida – SBOM generavimas, bet nesaugojimas kaip kontroliuojamų įrodymų. Jei failas perrašomas kiekvieno surinkimo metu ir negali būti susietas su išleidimu, tai silpni audito įrodymai.

Antroji klaida – SBOM atskyrimas nuo pažeidžiamumų valdymo. Komponentų sąrašas be pirminio įvertinimo, savininkystės, taisomųjų veiksmų arba rizikos priėmimo neįrodo kontrolės priemonių veikimo.

Trečioji klaida – tranzityvinių priklausomybių neįtraukimas. Pažeidžiamumai dažnai slepiasi žemiau tiesioginių priklausomybių sluoksnio.

Ketvirtoji klaida – išorės kūrimo palikimas už proceso ribų. Jei tiekėjas pristato kodą be komponentų atskleidimo, skenavimo įrodymų arba patvirtinimo įrašų, programinės įrangos tiekimo grandinėje lieka nevaldoma akloji zona.

Penktoji klaida – tiekėjų sutarčių pasirašymas be teisių į įrodymus. Pirkimai pasirašo susitarimą, inžinerija naudoja paslaugą, o saugumo komanda vėliau nustato, kad nėra audito teisės, pažeidžiamumų atskleidimo pareigos, subtiekėjų apribojimo ir pasitraukimo pagalbos.

Šeštoji klaida – komponentų nesusiejimas su verslo paslaugomis. Pažeidžiamas paketas mažai ką reiškia, kol nežinote, ar jis veikia autentifikavimą, mokėjimus, ataskaitų teikimą, pacientų duomenis, debesijos administravimą, klientų įvedimą ar reglamentuojamą finansinę darbo eigą.

Septintoji klaida – neišspręstų kritinių pažeidžiamumų slėpimas nuo vadovybės. NIS2 ir DORA aiškiai nustato vadovybės atskaitomybę. Kritinė komponentų rizika turi būti matoma valdysenos forumuose, o ne paslėpta inžinerijos darbų sąrašuose.

Kaip atrodo geras lygis 2026 m.

Auditui tinkama SBOM programa turi aiškius požymius.

Yra patvirtinta politika, reikalaujanti, kad trečiųjų šalių ir atvirojo kodo komponentai būtų patvirtinti, sekami, skenuojami ir peržiūrimi. CI/CD grandinė automatiškai generuoja SBOM. SCA skenavimai vykdomi prieš diegimą ir eksploatacijos metu, kai taikoma. Kritiniai pažeidžiamumai inicijuoja apibrėžtą eskalavimą. Išimtys turi savininkus, galiojimo pabaigos datas, kompensuojančias kontrolės priemones ir rizikos priėmimą.

Tiekėjų sutartyse numatyti saugumo įsipareigojimai, pranešimų apie pažeidimus terminai, audito teisės, subtiekėjų kontrolės priemonės ir nutraukimo nuostatos. Kritiniai tiekėjai peržiūrimi bent kartą per metus. Tiekėjų priklausomybės ir koncentracijos rizikos yra matomos. Išorės kūrimo komandos laikosi tų pačių saugaus kūrimo ir komponentų patvirtinimo taisyklių kaip vidinės komandos.

Vadovybės ataskaitos susieja techninę riziką su verslo poveikiu:

• Kritiniai pažeidžiami komponentai pagal produktą
• Ekspozicija pagal klientą arba reglamentuojamą paslaugą
• Neužbaigti taisomieji veiksmai virš SLA
• Komponentai be patvirtinto šaltinio
• Nebepalaikomos arba gyvavimo ciklo pabaigą pasiekusios bibliotekos
• Tiekėjų įrodymų spragos
• Išimtys, laukiančios atnaujinimo arba uždarymo
• Incidentai, susieti su komponentų pažeidžiamumais

Tuomet SBOM nustoja būti atitikties artefaktu ir tampa valdymo priemone.

Paverskite SBOM pagrįstais atitikties įrodymais

Kitą kartą, kai kritinio komponento įspėjimas pasieks 07:42, atsakymas neturėtų būti: „Mums reikia dviejų valandų išsiaiškinti, kur jis yra.“

Atsakymas turėtų būti: „Štai paveiktas komponentas, štai paslaugos, štai klientai, štai rizikos įvertinimas, štai taisomųjų veiksmų planas ir štai įrodymai.“

Clarysec gali padėti suprojektuoti tokią kontrolės sistemą. Padedame organizacijoms apibrėžti SBOM taikymo sritį ISVS viduje, susieti ISO 27001:2022 A priedo kontrolės priemones su NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT stiliaus audito lūkesčiais, įgyvendinti saugaus kūrimo ir tiekėjų politikas, sudaryti išleidimo įrodymų paketus ir pasirengti auditui tinkamam užtikrinimui naudojant Zenith Controls ir Zenith Blueprint.

Ar esate pasirengę savo programinės įrangos tiekimo grandinę iš neapibrėžtumo šaltinio paversti atsparumo įrodymu?

Atsisiųskite aktualias Clarysec politikas, naudokite Zenith Blueprint įgyvendinimo sekai sudėlioti ir Zenith Controls įrodymams susieti su ISO 27001:2022, NIS2, DORA ir klientų užtikrinimo reikalavimais. Susisiekite su Clarysec, kad pradėtumėte nuo tikslinio SBOM pasirengimo vertinimo ir sukurtumėte praktišką, auditui tinkamą programinės įrangos tiekimo grandinės užtikrinimo programą.