SBOM-i kot podlaga za zagotovila pri ISO 27001, NIS2 in DORA

V petek ob 07:42 Amelia, vodja informacijske varnosti hitro rastočega fintech podjetja, prejme opozorilo, ki si ga ne želi videti noben varnostni vodja.

Široko uporabljan odprtokodni paket ima kritično ranljivost za oddaljeno izvajanje kode. Orodje za analizo sestave programske opreme kaže, da je komponenta morda prisotna v storitvi za avtentikacijo, morda v obračunavanju in morda tudi v API-vmesniku tretje osebe, ki ga uporablja plačilni proces. Inženirska ekipa potrebuje čas za potrditev. Pravna služba sprašuje, ali je začel teči rok za obvestilo po NIS2. Vodja programa DORA sprašuje, ali prizadeta storitev podpira kritično ali pomembno funkcijo finančnega subjekta. Prodaja sprašuje, ali bo to blokiralo podaljšanje pogodbe. Upravni odbor postavi najpreprostejše in najtežje vprašanje: »Ali smo izpostavljeni?«

Brez kosovnice programske opreme je pošten odgovor pogosto: »Tega še ne vemo.«

Leta 2026 tak odgovor ni več samo tehnična vrzel. Je slabost upravljanja, pogodbeno tveganje, izpostavljenost pri presoji in, za regulirane subjekte, vprašanje odpornosti. SBOM-i so se iz prakse higiene DevSecOps premaknili med dokazila na ravni upravnega odbora za zagotavljanje zaupanja v dobavno verigo programske opreme, delovanje kontrol ISO/IEC 27001:2022, upravljanje tveganj kibernetske varnosti po NIS2, upravljanje tveganj tretjih oseb IKT po DORA, odgovornost po GDPR in skrbni pregled naročnikov.

Ključ ni samo ustvarjanje datoteke SBOM. Ključno je dokazati, da so komponente programske opreme identificirane, odobrene, spremljane, ocenjene glede tveganja, posodobljene s popravki, pogodbeno urejene in sledljive do odgovornih lastnikov. Tu knjižnica politik Clarysec, Zenith Blueprint: 30-koračni časovni načrt za presojevalce in Zenith Controls: vodnik za skladnost med okviri razvijalski artefakt pretvorijo v zagovorljiva dokazila o skladnosti.

Zakaj so SBOM-i danes dokazila za zagotavljanje zaupanja v dobavno verigo programske opreme

SBOM je popis komponent programske opreme, vključno z odprtokodnimi paketi, komercialnimi knjižnicami, različicami, viri, licencami in razmerji odvisnosti. Uporaben SBOM pomaga odgovoriti na štiri vprašanja, ki so danes pomembna regulatorjem, naročnikom in upravnim odborom:

1. Kaj je v naši programski opremi?
2. Kje je uvedeno?
3. Ali je ranljivo, nepodprto, nelicencirano ali neodobreno?
4. Kdo je odgovoren za odpravo, ublažitev ali sprejem tveganja?

Ta vprašanja se neposredno preslikajo v sodobna pravna in regulativna pričakovanja.

NIS2 velja za številne srednje in velike subjekte v bistvenih in pomembnih sektorjih, vključno z digitalno infrastrukturo, ponudniki storitev računalništva v oblaku, ponudniki storitev podatkovnih centrov, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev, spletnimi tržnicami, iskalniki, platformami družbenih omrežij in nekaterimi digitalnimi ponudniki. Velja lahko tudi na podlagi nacionalne določitve in sektorskega prenosa v nacionalno pravo. Za zavezance v področju uporabe NIS2 zahteva, da organi upravljanja odobrijo ukrepe za upravljanje tveganj kibernetske varnosti in nadzirajo njihovo izvajanje. Article 21 vključuje varnost dobavne verige, varno pridobivanje, varen razvoj in vzdrževanje, obravnavo in razkrivanje ranljivosti, obravnavanje incidentov, neprekinjeno poslovanje, upravljanje sredstev, nadzor dostopa, kriptografijo, ocenjevanje učinkovitosti in kibernetsko higieno.

DORA, ki se uporablja od 17. januarja 2025, vzpostavlja enoten okvir EU za digitalno operativno odpornost finančnih subjektov. Zajema upravljanje tveganj IKT, poročanje o incidentih, povezanih z IKT, testiranje odpornosti, upravljanje tveganj tretjih oseb IKT, pogodbene ureditve in nadzor nad kritičnimi ponudniki storitev IKT tretjih oseb. DORA od finančnih subjektov pričakuje, da identificirajo IKT-sredstva, poslovne funkcije, podprte z IKT, odvisnosti, medsebojne povezave, ranljivosti, scenarije tveganj, spremembe in procese, ki jih podpirajo tretje osebe.

GDPR doda plast varstva zasebnosti. Če ranljiva komponenta vpliva na sisteme, ki obdelujejo osebne podatke, postane ključno vprašanje, ali bi bili osebni podatki lahko dostopani, spremenjeni, izgubljeni, razkriti ali drugače kompromitirani. Upravljavci in obdelovalci potrebujejo dokazila, da lahko identificirajo prizadete sisteme, tokove podatkov, podobdelovalce in vpliv kršitve.

NIST CSF 2.0 krepi isti operativni model prek funkcij GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER. Njegovi rezultati za dobavno verigo zahtevajo odgovornosti dobaviteljev, kritičnost, pogodbene zahteve, skrbni pregled, spremljanje, načrtovanje incidentov in določila ob zaključku odnosa.

Ko Ameliin upravni odbor vpraša, ali je fintech podjetje izpostavljeno, lahko organizacija, podprta s SBOM, odgovori z dokazili:

• Kateri produkti in izdaje vsebujejo ranljivo komponento
• Katera uvedena okolja so prizadeta
• Kateri naročniki, regije, funkcije in tokovi podatkov so povezani
• Kateri dobavitelj ali notranji lastnik je odgovoren
• Katere kompenzacijske kontrole so aktivne
• Ali se lahko sprožijo pragovi po NIS2, DORA, GDPR ali pogodbah
• Kateri popravek, ublažitev, izjema ali sprejem tveganja je bil odobren

To je razlika med seznamom komponent in sistemom kontrol.

ISO 27001:2022 je hrbtenica upravljanja SBOM

ISO/IEC 27001:2022 je močna podlaga za upravljanje SBOM, ker je standard sistema upravljanja in ne zgolj tehnični kontrolni seznam. Njegove klavzule od organizacij zahtevajo opredelitev konteksta, zainteresiranih strani, obsega, zavezanosti vodstva, politike, vlog, ocene tveganja, obravnave tveganja, ciljev, vrednotenja uspešnosti, notranje presoje, vodstvenega pregleda in nenehnega izboljševanja.

Programi SBOM ne uspejo, kadar so zunaj ISMS. Inženiring lahko ustvarja datoteke, vendar nihče ne uveljavlja rokov SLA za odpravo ranljivosti, obveznosti dobaviteljev, hrambe dokazil, sprejema tveganja ali pravil razkritja naročnikom. ISO 27001 to popravi tako, da SBOM-e vključi v sistem upravljanja tveganj organizacije.

V skladu s klavzulami 4.1 do 4.4 organizacija določi notranja in zunanja vprašanja, zahteve zainteresiranih strani, zakonske in regulativne obveznosti, pogodbena pričakovanja ter obseg ISMS. Za zagotavljanje zaupanja s SBOM mora obseg izrecno vključevati:

• Produkte in storitve, dobavljene naročnikom
• Produkcijska okolja v oblaku in SaaS
• CI/CD cevovode, repozitorije izvorne kode in registre artefaktov
• Odprtokodne in komercialne komponente programske opreme
• Zunanji razvoj in integracijske partnerje
• Ponudnike IKT tretjih oseb in podizvajalce
• Varnostne zahteve naročnikov po DORA, NIS2, GDPR in pogodbah

Klavzule 5.1 do 5.3 tveganje dobavne verige programske opreme postavijo na raven vodstva. Vodstvo mora varnostne cilje uskladiti s poslovno usmeritvijo, zagotoviti vire, dodeliti odgovornosti in komunicirati politiko. Klavzuli 6.1.2 in 6.1.3 ugotovitve SBOM pretvorita v dokazila o oceni tveganja in obravnavi tveganja. Kritična ranljiva komponenta v avtentikacijski storitvi, dostopni iz interneta, ni zgolj zahtevek. Je scenarij tveganja, ki vpliva na zaupnost, celovitost, razpoložljivost, pogodbene zaveze, regulativno poročanje in operativno odpornost.

Najpomembnejše kontrole iz Priloge A standarda ISO/IEC 27001:2022 za zagotavljanje zaupanja s SBOM so:

Clarysec te odnose preslika prek atributov ISO/IEC 27002:2022 v Zenith Controls. Na primer, Zenith Controls kontrolo ISO/IEC 27002:2022 5.21, »Upravljanje informacijske varnosti v dobavni verigi IKT«, obravnava kot preventivno, namenjeno zaščiti zaupnosti, celovitosti in razpoložljivosti, usklajeno s konceptom kibernetske varnosti Identify ter delujočo na področjih upravljanja, ekosistema in zaščite. Kontrolo 8.25, »Življenjski cikel varnega razvoja«, obravnava kot preventivno in usklajeno s Protect. Kontrolo 8.8, »Upravljanje tehničnih ranljivosti«, obravnava kot preventivno in usklajeno z Identify in Protect, pri čemer upravljanje ranljivosti povezuje z upravljanjem, ekosistemom, zaščito in obrambo.

Ta prevod je pomemben, ker različni pregledovalci postavljajo različna vprašanja. Presojevalec ISO lahko vpraša, ali je tveganje komponent vključeno v Izjavo o uporabnosti. Pregledovalec DORA lahko vpraša, ali komponenta podpira kritično ali pomembno funkcijo. Naročnik lahko vpraša, ali nerešene ranljivosti presegajo pogodbene SLA. Ista dokazila SBOM lahko podprejo vse tri, če so pravilno upravljana.

Plast politik Clarysec za SBOM-e, pripravljene za presojo

Zanesljiv program SBOM potrebuje jezik politike. Razvijalci morajo vedeti, kaj je treba evidentirati. Nabava mora vedeti, kaj morajo zagotoviti dobavitelji. Varnost mora vedeti, katere ugotovitve sprožijo eskalacijo. Funkcija skladnosti mora vedeti, katera dokazila je treba hraniti.

Za manjše organizacije Politika varnega razvoja - SME vzpostavlja minimalno izvedljivo kontrolo SBOM:

Generalni direktor ali imenovani razvijalec mora vzdrževati seznam vseh uporabljenih zunanjih komponent, vključno z: 6.6.2.1 različico in virom 6.6.2.2 znanimi ranljivostmi ali stanjem popravkov 6.6.2.3 datumom zadnje posodobitve ali pregleda

Ta zahteva je preprosta, vendar močna. Vzpostavlja vidnost različic, sledljivost vira, stanje ranljivosti in kadenco pregledov.

Politika zahtev za varnost aplikacij - SME doda pregled življenjskega cikla:

Vsako orodje tretje osebe, vtičnik ali zunanja knjižnica kode, uporabljena v aplikaciji, mora biti evidentirana in vsako leto pregledana glede varnostnega vpliva in stanja popravkov.

Politika upravljanja ranljivosti in popravkov - SME poveže SBOM-e z odpravo:

Razvijalci morajo spremljati in posodabljati knjižnice tretjih oseb (npr. odprtokodne pakete)

Za podjetniška okolja Politika varnega razvoja zviša pričakovanja:

Uporaba odprtokodne kode ali kode tretjih oseb mora biti odobrena, sledena in preverjena prek:

Obvezno določa tudi skeniranje:

Vse komponente tretjih oseb morajo biti pred uvedbo in med izvajanjem skenirane za ranljivosti z avtomatiziranimi orodji.

Zunanji razvoj mora slediti istemu standardu. Politika zunanjega razvoja zahteva:

Varna uporaba odprtokodnih knjižnic, ki je predmet skeniranja ranljivosti in odobritve

Pogodbe z dobavitelji potrebujejo izvršljive pravice do dokazil. Politika varnosti tretjih oseb in dobaviteljev - SME zahteva pogodbene klavzule, ki zajemajo zaupnost, varnostne obveznosti, roke za obvestila o kršitvah, pravice do presoje, omejitve podizvajanja in varno prenehanje:

Pogodbe morajo vključevati obvezne klavzule, ki zajemajo: 5.3.1 zaupnost in nerazkrivanje 5.3.2 obveznosti informacijske varnosti 5.3.3 roke za obvestila o kršitvah varnosti osebnih podatkov (npr. v 24–72 urah) 5.3.4 pravice do presoje ali razpoložljivost dokazil o skladnosti 5.3.5 omejitve nadaljnjega podizvajanja brez odobritve 5.3.6 pogoje prenehanja, vključno z varnim vračilom ali uničenjem podatkov

Za podjetniške naročnike Politika varnosti tretjih oseb in dobaviteljev vključuje:

Pravice do presoje, pregleda in zahteve po varnostnih dokazilih

Če ponudnik SaaS, partner za zunanji razvoj ali komercialni dobavitelj programske opreme ne zagotovi varnostnih dokazil, stanja ranljivosti, zavez za obveščanje ali dostopa za presojo, ima vaše zagotavljanje zaupanja v dobavno verigo programske opreme slepo pego.

Politika upravljanja tveganj odvisnosti od dobaviteljev pretvori koncentracijo odvisnosti v merljivo tveganje odpornosti:

Register odvisnosti od dobaviteljev: VMO mora vzdrževati ažuren register vseh kritičnih dobaviteljev, vključno s podatki, kot so zagotovljene storitve/produkti; ali je dobavitelj edini vir; razpoložljivi alternativni dobavitelji ali zamenljivost; veljavni pogodbeni pogoji; in ocena vpliva, če bi dobavitelj odpovedal ali bil kompromitiran. Register mora jasno identificirati dobavitelje z visoko stopnjo odvisnosti (npr. tiste, za katere ni hitre alternative).

Ta register mora biti povezan s SBOM-i. Če kritična knjižnica prihaja od dobavitelja, ki je edini vir, podpira reguliran proces naročnika in nima hitrega nadomestila, to ni samo paket. Je odvisnost, pomembna za odpornost.

Od datoteke SBOM do operativne kontrole v enem sprintu

Praktičen program SBOM se mora začeti z eno produktno linijo in enim produkcijskim okoljem. Ne poskušajte prvi dan popisati celotnega podjetja. Če Ameliino fintech podjetje začne z uvajanjem strank in plačilnim procesom, lahko ekipa pred širitvijo vzpostavi ponovljiv model dokazil.

1. korak: opredelite obseg SBOM znotraj ISMS

Ustvarite izjavo o obsegu, povezano z obsegom ISMS in regulativnimi dejavniki:

• Produkt: platforma SaaS za uvajanje strank in plačila
• Okolje: produkcija v EU
• Repozitoriji: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Sistemi za gradnjo: ponudnik Git, platforma CI/CD, register vsebnikov
• Uvedba: gruča Kubernetes, upravljana podatkovna baza, objektna shramba
• Podatki: podatki računov, dnevniki avtentikacije, obračunski metapodatki, plačilne reference
• Naročniki: finančni subjekti EU in komercialni naročniki
• Regulativni dejavniki: ISO 27001:2022, zagotavljanje zaupanja naročnikom po NIS2, skrbni pregled tretjih oseb IKT po DORA, odgovornost za varnost po GDPR

To je usklajeno z logiko obsega iz klavzule 4 standarda ISO 27001 in določanjem obsega profila NIST CSF.

2. korak: ustvarite in hranite SBOM-e ob času gradnje

Konfigurirajte CI/CD cevovode tako, da ustvarijo SBOM za vsak artefakt gradnje, vključno s slikami vsebnikov. Pogosto se uporabljajo standardni formati, kot sta CycloneDX in SPDX. Vsak SBOM shranite v nadzorovan repozitorij dokazil za presojo, povezan z identifikatorjem gradnje, zgoščeno vrednostjo potrditve, zapisom o uvedbi in različico izdaje.

To neposredno podpira zahtevo Politike varnega razvoja - SME za vzdrževanje različice, vira, znane ranljivosti ali stanja popravka in datuma pregleda.

3. korak: obogatite podatke SBOM z izkoriščljivostjo in poslovnim kontekstom

Ne ustavite se pri seznamu paketov. Dodajte operativni kontekst tveganja:

• Ali je komponenta ranljiva?
• Ali je ranljiva funkcija dosegljiva?
• Ali je storitev dostopna iz interneta?
• Ali storitev obdeluje osebne podatke?
• Ali podpira kritično ali pomembno funkcijo za naročnika DORA?
• Ali je popravek na voljo?
• Ali obstaja kompenzacijska kontrola?
• Ali je lastnik tveganja odobril sprejem tveganja?

Kritična CVE v paketu, ki se uporablja samo za testiranje, se razlikuje od kritične CVE v produkcijski avtentikacijski storitvi. Klavzule ISO 27001 o oceni tveganja in obravnavi tveganja pomagajo to razliko zagovorljivo utemeljiti.

4. korak: povežite SBOM-e s kontrolami dobaviteljev in zunanjega razvoja

Če komponento zagotavlja komercialni dobavitelj ali partner za zunanji razvoj, posodobite evidenco dobavitelja:

To podpira varnost dobavne verige po NIS2 Article 21 in pričakovanja DORA Article 28 glede strategije za tveganja tretjih oseb IKT, skrbnega pregleda, pogodbenih varoval, registrov informacij, načrtovanja presoj, pravic do odpovedi in izstopnih strategij.

5. korak: določite pravila odprave in dokazila

Roke SLA za odpravo vežite na poslovni vpliv, ne samo na ocene CVSS.

Tu SBOM-i postanejo uporabni za NIS2, DORA in GDPR. Delovni tok odprave mora upoštevati možnost pomembnega incidenta, vpliv večjega incidenta, povezanega z IKT, merila za kršitev varnosti osebnih podatkov, pogodbene obveznosti obveščanja in vpliv na operativno odpornost.

6. korak: dodajte kontrolno točko izdaje

Pred uvedbo mora cevovod ali proces sprememb potrditi:

• SBOM je bil uspešno ustvarjen
• Ni preostalih kritičnih neodobrenih ranljivosti
• Nove komponente tretjih oseb so odobrene
• Politika licenc je bila uspešno preverjena
• SCA, SAST, DAST ali drugo zahtevano testiranje je končano
• Zahtevek za spremembo je povezan
• Načrt povrnitve je dokumentiran za izdaje z visokim tveganjem

To poveže A.8.25 varen razvoj, A.8.29 varnostno testiranje in A.8.32 upravljanje sprememb v en sam preverljiv delovni tok.

7. korak: pripravite paket dokazil izdaje

Za vsako izdajo hranite:

• Datoteko SBOM
• Identifikator gradnje in zgoščeno vrednost potrditve
• Izhod skeniranja SCA
• Zapis triaže ranljivosti
• Odobrene izjeme
• Odobritev spremembe
• Zapis o uvedbi
• Rezultate testiranja
• Dokazila dobaviteljev, kadar je to ustrezno
• Zapis incidenta ali problema, če je izdaja odpravila ranljivost

Ko presojevalec vpraša, kako se v produkciji upravljajo knjižnice tretjih oseb, Ameliina ekipa ne išče po nitih v Slacku. Odpre paket dokazil izdaje.

Preslikava skladnosti med okviri: en program SBOM, številne obveznosti

Komercialna vrednost programa SBOM se poveča, ko je enkrat preslikan in nato ponovno uporabljen čez različne okvire. Clarysecov pristop skladnosti med okviri preprečuje podvajanje dela tako, da ista dokazila prevede v različne jezike zagotavljanja zaupanja.

Poročanje o incidentih po NIS2 lahko poteka hitro, kadar izkoriščanje povzroči ali je zmožno povzročiti resno operativno motnjo, finančno izgubo ali znatno materialno ali nematerialno škodo. NIS2 uporablja fazno poročanje, vključno z zgodnjim opozorilom v 24 urah od seznanitve, obvestilom o incidentu v 72 urah in končnim poročilom v enem mesecu od obvestila o incidentu. SBOM-i pomagajo ugotoviti, ali je prizadeta komponenta prisotna, ali so prizadete storitve za naročnike in ali je čezmejni vpliv verjeten.

DORA uporablja strukturiran življenjski cikel incidentov IKT, vključno z odkrivanjem, evidentiranjem, razvrščanjem, analizo temeljnega vzroka, eskalacijo, komunikacijskimi načrti, eskalacijo organu upravljanja in regulativnim poročanjem za večje incidente, povezane z IKT. Dokazila SBOM podpirajo razvrščanje, ker ranljivo komponento povežejo s prizadetimi strankami, izpadom, geografskim obsegom, izgubami podatkov, kritičnostjo storitve in gospodarskim vplivom.

NIST CSF 2.0 doda uporaben jezik za zagotavljanje zaupanja naročnikom. Zenith Controls preslika A.5.21 v rezultate upravljanja dobavne verige, kot je GV.SC-05, kjer so zahteve kibernetske varnosti za dobavitelje določene, komunicirane in vključene v pogodbe ter druge dogovore. Zahtevati SBOM-e, razkritje ranljivosti, dokazila za presojo in roke za odpravo tako postane pogodbena kontrola, ne ad hoc zahteva.

Kako Zenith Blueprint zaporedno uredi delo

Zenith Blueprint jezik kontrol pretvori v časovni načrt implementacije.

V fazi upravljanja tveganj 14. korak poveže varen razvoj, CI/CD kontrole, skeniranje odvisnosti, upravljanje sprememb, obravnavanje incidentov in usposabljanje razvijalcev. V fazi Controls in Action je 20. korak izrecen glede komponent tretjih oseb in odprtokodnih komponent:

Ta kontrola velja tudi za komponente tretjih oseb in odprtokodne komponente. Zanašanje na zunanje knjižnice je standardna praksa, vendar je vsaka vključitev odločitev o zaupanju. Razvijalci morajo oceniti odvisnosti glede na ugled, pogostost vzdrževanja, znane ranljivosti in licenčne omejitve. Orodja, kot so SBOM-i (kosovnice programske opreme), so vse pomembnejša za sledenje temu, kaj je vgrajeno v vaš sklad.

21. korak obravnava varnostno testiranje kot odvisno od konteksta in priporoča večplastno testiranje za poslovno kritične sisteme ali sisteme, izpostavljene internetu, vključno z analizo sestave programske opreme za knjižnice tretjih oseb, statično in dinamično analizo, penetracijskim testiranjem, validacijo modeliranja groženj, testiranjem primerov neprimerne uporabe, fuzzingom in ročnim raziskovalnim testiranjem.

22. korak obravnava sporazume z dobavitelji, vključno z obveznostmi glede zaupnosti, odgovornostmi za nadzor dostopa, tehničnimi in organizacijskimi ukrepi, roki za poročanje o incidentih, pravico do presoje, kontrolami podizvajalcev in določili ob izteku pogodbe.

Praktično sporočilo je preprosto. SBOM-i sodijo v upravljanje tveganj, varen razvoj, testiranje, upravljanje dobaviteljev, odziv na incidente in poročanje vodstvu.

Pogled presojevalca: kaj bodo preverjali različni pregledovalci

Zrel program SBOM mora vzdržati različne presojevalske pristope.

Presojevalec ISO 27001:2022 bo začel pri ISMS. Vprašal bo, ali je tveganje dobavne verige programske opreme v obsegu, ali zahteve zainteresiranih strani vključujejo NIS2, naročnike DORA, GDPR in pogodbe, ali je tveganje komponent del metodologije tveganj, ali Izjava o uporabnosti vključuje ustrezne kontrole iz Priloge A in ali se politike skozi čas izvajajo. Lahko vzorči eno izdajo in ji sledi od politike do cevovoda, SBOM, skeniranja ranljivosti, odobritve spremembe, uvedbe in spremljanja po izdaji.

Pregledovalec DORA ali finančni naročnik se bo osredotočil na operativno odpornost in tveganja tretjih oseb IKT. Vprašal bo lahko, katere komponente podpirajo storitev, ki jo uporablja finančni subjekt, ali storitev podpira kritično ali pomembno funkcijo, kako so dokumentirana IKT-sredstva in odvisnosti, ali se ranljivosti spremljajo, ali letno testiranje zajema kritične sisteme in ali pogodbe vključujejo pomoč, pravice do presoje, obveščanje o incidentih, lokacijo podatkov, podizvajanje in pogoje prenehanja.

Ocenjevalec NIST CSF bo iskal rezultate. V okviru GOVERN bo preverjal pravno, regulativno, pogodbeno, zasebnostno in dobaviteljsko upravljanje. V okviru IDENTIFY bo pričakoval vidnost sredstev, programske opreme in storitev. V okviru PROTECT bo preverjal varen razvoj in kontrole cevovoda. V okviru DETECT in RESPOND bo pregledal opozorila o ranljivostih, analizo, eskalacijo in komuniciranje. V okviru RECOVER bo vprašal, kako kompromitacija komponente vpliva na obnovitev in komuniciranje z naročniki.

Presojevalec v slogu COBIT ali ISACA se bo osredotočil na upravljanje, odgovornost, lastništvo tveganj, zasnovo kontrol in zanesljivost dokazil. Preveri lahko, ali so SBOM-i popolni, ali se zahtevki za ranljivosti zapirajo v skladu s politiko, ali izjeme potečejo, ali so dokazila dobaviteljev ažurna in ali vodstvo prejema smiselna poročila.

Pogoste napake pri SBOM, ki se jim je treba izogniti

Programi SBOM običajno ne uspejo iz predvidljivih razlogov.

Prva napaka je ustvarjanje SBOM-ov brez hrambe kot nadzorovanih dokazil. Če se datoteka pri vsaki gradnji prepiše in je ni mogoče povezati z izdajo, je to šibko dokazilo za presojo.

Druga napaka je ločevanje SBOM-ov od upravljanja ranljivosti. Seznam komponent brez triaže, lastništva, odprave ali sprejema tveganja ne dokazuje delovanja kontrole.

Tretja napaka je izključevanje tranzitivnih odvisnosti. Ranljivosti se pogosto skrivajo pod plastjo neposrednih odvisnosti.

Četrta napaka je puščanje zunanjega razvoja zunaj procesa. Če dobavitelj dostavi kodo brez razkritja komponent, dokazil o skeniranju ali zapisov odobritev, ima dobavna veriga programske opreme neupravljano slepo pego.

Peta napaka je sklepanje pogodb z dobavitelji brez pravic do dokazil. Nabava podpiše pogodbo, inženiring začne uporabljati storitev, varnost pa pozneje ugotovi, da ni pravice do presoje, obveznosti razkritja ranljivosti, omejitve podizvajalcev ali podpore pri izstopu.

Šesta napaka je neuspešno preslikavanje komponent na poslovne storitve. Ranljiv paket pomeni malo, dokler ne veste, ali vpliva na avtentikacijo, plačila, poročanje, podatke pacientov, upravljanje oblaka, uvajanje strank ali reguliran finančni proces.

Sedma napaka je skrivanje nerešenih kritičnih ranljivosti pred vodstvom. NIS2 in DORA izrecno določata odgovornost vodstva. Tveganje kritičnih komponent mora biti vidno forumom upravljanja, ne pa zakopano v zaostankih nalog inženiringa.

Kako je videti dobro stanje leta 2026

Program SBOM, pripravljen za presojo, ima vidne lastnosti.

Obstaja odobrena politika, ki zahteva, da so komponente tretjih oseb in odprtokodne komponente odobrene, sledene, skenirane in pregledane. CI/CD cevovod samodejno ustvarja SBOM-e. Skeniranja SCA se izvajajo pred uvedbo in med izvajanjem, kjer je to ustrezno. Kritične ranljivosti sprožijo opredeljeno eskalacijo. Izjeme imajo lastnike, datume poteka, kompenzacijske kontrole in sprejem tveganja.

Pogodbe z dobavitelji vključujejo varnostne obveznosti, roke za obvestila o kršitvah, pravice do presoje, kontrole podizvajanja in določila o prenehanju. Kritični dobavitelji se pregledajo vsaj enkrat letno. Tveganja odvisnosti od dobaviteljev in koncentracije so vidna. Ekipe zunanjega razvoja sledijo istim pravilom varnega razvoja in odobritve komponent kot notranje ekipe.

Poročanje vodstvu povezuje tehnično tveganje s poslovnim vplivom:

• Kritične ranljive komponente po produktu
• Izpostavljenost po naročniku ali regulirani storitvi
• Odprte odprave po prekoračenem SLA
• Komponente brez odobrenega vira
• Nepodprte knjižnice ali knjižnice ob koncu življenjske dobe
• Vrzeli v dokazilih dobaviteljev
• Izjeme, ki čakajo na podaljšanje ali zaprtje
• Incidenti, povezani z ranljivostmi komponent

Takrat SBOM-i prenehajo biti artefakt skladnosti in postanejo orodje upravljanja.

Pretvorite SBOM-e v zagovorljiva dokazila o skladnosti

Ko naslednjič ob 07:42 prispe opozorilo o kritični komponenti, odgovor ne sme biti: »Potrebujemo dve uri, da ugotovimo, kje je.«

Odgovor mora biti: »Tukaj je prizadeta komponenta, tukaj so storitve, tukaj so naročniki, tukaj je ocena tveganja, tukaj je načrt odprave in tukaj so dokazila.«

Clarysec vam lahko pomaga zasnovati tak sistem kontrol. Organizacijam pomagamo opredeliti obseg SBOM znotraj ISMS, preslikati kontrole iz Priloge A standarda ISO 27001:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 in revizijska pričakovanja v slogu COBIT, implementirati politike varnega razvoja in dobaviteljev, pripraviti pakete dokazil izdaje ter vzpostaviti zagotavljanje zaupanja, pripravljeno za presojo, z uporabo Zenith Controls in Zenith Blueprint.

Ste pripravljeni svojo dobavno verigo programske opreme iz vira negotovosti pretvoriti v dokaz odpornosti?

Prenesite ustrezne politike Clarysec, uporabite Zenith Blueprint za zaporedje implementacije in Zenith Controls za preslikavo dokazil čez ISO 27001:2022, NIS2, DORA in zahteve za zagotavljanje zaupanja naročnikom. Obrnite se na Clarysec, da začnete z osredotočeno oceno pripravljenosti SBOM in vzpostavite praktičen program zagotavljanja zaupanja v dobavno verigo programske opreme, pripravljen za presojo.