SBOM-id ISO 27001, NIS2 ja DORA vastavustõenduse jaoks

Reedel kell 07.42 saab kiiresti kasvava FinTech-ettevõtte infoturbejuht Amelia teavituse, mida ükski infoturbejuht näha ei soovi.

Laialdaselt kasutatavas avatud lähtekoodiga paketis on kriitiline kaugkäivitatava koodi haavatavus. Tarkvarakompositsiooni analüüsi tööriist näitab, et komponent võib olla autentimisteenuses, võib-olla arvelduses ning võimalik, et ka kolmanda osapoole API wrapper’is, mida kasutatakse maksete töövoos. Arendusmeeskond vajab kinnitamiseks aega. Õigusosakond küsib, kas NIS2 teavitustähtaeg on käivitunud. DORA programmi juht küsib, kas mõjutatud teenus toetab finantsüksuse kriitilist või olulist funktsiooni. Müük küsib, kas see võib lepingu uuendamise blokeerida. Juhatus esitab kõige lihtsama ja samas kõige raskema küsimuse: „Kas me oleme ohustatud?”

Ilma tarkvara koostisosade loendita on aus vastus sageli: „Me ei tea veel.”

2026. aastal ei ole selline vastus pelgalt tehniline puudujääk. See on juhtimise nõrkus, lepinguline risk, auditirisk ja reguleeritud üksuste puhul tegevuskerksuse probleem. SBOM-id on liikunud DevSecOpsi hügieenist juhatuse tasandi tõendusmaterjaliks tarkvara tarneahela vastavustõenduse, ISO/IEC 27001:2022 kontrollimeetmete toimimise, NIS2 küberturvalisuse riskijuhtimise, DORA kolmandatest isikutest IKT-teenuseosutajate juhtimise, GDPR vastutuse ja klientide hoolsuskontrolli jaoks.

Küsimus ei ole üksnes SBOM-faili genereerimises. Oluline on tõendada, et tarkvarakomponendid on tuvastatud, heaks kiidetud, seiratud, riskitaseme järgi hinnatud, paigatud, lepinguliselt hallatud ja jälgitavad vastutavate omanikeni. Just siin muudavad Clarysec poliitikateek, Zenith Blueprint: An Auditor’s 30-Step Roadmap ja Zenith Controls: The Cross-Compliance Guide arendaja artefakti kaitstavaks vastavuse tõendusmaterjaliks.

Miks SBOM-id on nüüd tarkvara tarneahela vastavustõenduse tõendusmaterjal

SBOM on tarkvarakomponentide register, mis hõlmab avatud lähtekoodiga pakette, kommertsteeke, versioone, allikaid, litsentse ja sõltuvussuhteid. Kasulik SBOM aitab vastata neljale küsimusele, mis on nüüd regulaatorite, klientide ja juhatuste jaoks olulised:

1. Mis on meie tarkvara sees?
2. Kus see on juurutatud?
3. Kas see on haavatav, toetuseta, litsentsita või heakskiiduta?
4. Kes vastutab parandusmeetmete, maandamise või riski aktsepteerimise eest?

Need küsimused seostuvad otseselt tänapäevaste õiguslike ja regulatiivsete ootustega.

NIS2 kohaldub paljudele keskmise suurusega ja suurtele üksustele olulistes ja tähtsates sektorites, sealhulgas digitaristu, pilveteenuste pakkujad, andmekeskusteenuse pakkujad, hallatud teenusepakkujad, hallatud turbeteenuse pakkujad, veebiturud, otsingumootorid, sotsiaalvõrgustiku platvormid ja teatavad digiteenuste pakkujad. See võib kohalduda ka riikliku määramise ja sektoripõhise ülevõtmise alusel. Kohaldamisalasse kuuluvate üksuste puhul nõuab NIS2, et juhtorganid kiidaksid heaks küberturvalisuse riskijuhtimise meetmed ja teeksid nende rakendamise üle järelevalvet. Article 21 hõlmab tarneahela turvet, turvalist soetamist, turvalist arendust ja hooldust, haavatavuste käsitlemist ja avalikustamist, intsidentide käsitlemist, talitluspidevust, varahaldust, juurdepääsukontrolli, krüptograafiat, tõhususe hindamist ja küberhügieeni.

DORA, mida kohaldatakse alates 17. jaanuarist 2025, loob finantsüksustele ühtse EL-i digitaalse tegevuskerksuse raamistiku. See hõlmab IKT-riski juhtimist, IKT-ga seotud intsidentidest teatamist, tegevuskerksuse testimist, kolmandatest isikutest IKT-teenuseosutajate riskijuhtimist, lepingulisi kokkuleppeid ja kriitiliste kolmandatest isikutest IKT-teenuseosutajate järelevalvet. DORA eeldab, et finantsüksused tuvastavad IKT-varad, IKT-toega ärifunktsioonid, sõltuvused, vastastikused seosed, haavatavused, riskistsenaariumid, muudatused ja kolmandate isikute toetatud protsessid.

GDPR lisab privaatsuskihi. Kui haavatav komponent mõjutab isikuandmeid töötlevaid süsteeme, muutub küsimuseks see, kas isikuandmetele võidi juurde pääseda, neid muuta, kaotada, avalikustada või muul viisil kompromiteerida. Vastutavatel töötlejatel ja volitatud töötlejatel on vaja tõendusmaterjali, mis näitab, et nad suudavad tuvastada mõjutatud süsteemid, andmevood, alltöötlejad ja rikkumise mõju.

NIST CSF 2.0 tugevdab sama toimimismudelit funktsioonide GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER kaudu. Selle tarneahela väljundid eeldavad tarnijate vastutusi, kriitilisust, lepingulisi nõudeid, hoolsuskontrolli, seiret, intsidendiplaane ja suhte lõpetamise sätteid.

Kui Amelia juhatus küsib, kas FinTech on ohustatud, saab SBOM-iga toetatud organisatsioon vastata tõendusmaterjali alusel:

• millised tooted ja väljalasked sisaldavad haavatavat komponenti;
• millised juurutatud keskkonnad on mõjutatud;
• millised kliendid, piirkonnad, funktsioonid ja andmevood on seotud;
• milline tarnija või sisemine omanik vastutab;
• millised kompenseerivad kontrollimeetmed on aktiivsed;
• kas NIS2, DORA, GDPR või lepingulised lävendid võivad käivituda;
• milline parandus, maandamine, erand või riski aktsepteerimine on heaks kiidetud.

See on erinevus komponentide loendi ja kontrollisüsteemi vahel.

ISO 27001:2022 on SBOM-i juhtimise selgroog

ISO/IEC 27001:2022 on SBOM-i juhtimiseks tugev alus, sest see on juhtimissüsteemi standard, mitte pelgalt tehniline kontrollnimekiri. Selle klauslid nõuavad organisatsioonidelt konteksti, huvitatud poolte, kohaldamisala, juhtkonna pühendumuse, poliitika, rollide, riskihindamise, riskikäsitluse, eesmärkide, tulemuslikkuse hindamise, siseauditi, juhtkonnapoolse ülevaatuse ja pideva täiustamise määratlemist.

SBOM-programmid ebaõnnestuvad, kui need jäävad ISMS-ist väljapoole. Arendusmeeskond võib faile genereerida, kuid keegi ei rakenda haavatavuste parandamise SLA-sid, tarnijate kohustusi, tõendusmaterjali säilitamist, riski aktsepteerimist ega klientidele avalikustamise reegleid. ISO 27001 lahendab selle, muutes SBOM-id organisatsiooni riskijuhtimise süsteemi osaks.

Punktide 4.1 kuni 4.4 alusel määrab organisatsioon sisemised ja välised teemad, huvitatud poolte nõuded, õiguslikud ja regulatiivsed kohustused, lepingulised ootused ja ISMS-i kohaldamisala. SBOM-i vastavustõenduse jaoks peab kohaldamisala selgelt hõlmama järgmist:

• klientidele osutatavad tooted ja teenused;
• pilve- ja SaaS-tootmiskeskkonnad;
• CI/CD torustikud, lähterepositooriumid ja artefaktiregistrid;
• avatud lähtekoodiga ja kommertstarkvara komponendid;
• allhankearendus ja integratsioonipartnerid;
• kolmandatest isikutest IKT-teenuseosutajad ja alltöövõtjad;
• klientide turbenõuded DORA, NIS2, GDPR ja lepingute alusel.

Punktid 5.1 kuni 5.3 muudavad tarkvara tarneahela riski juhtkonna küsimuseks. Juhtkond peab viima turbe-eesmärgid kooskõlla ärisuunaga, tagama ressursid, määrama vastutused ja kommunikeerima poliitika. Punktid 6.1.2 ja 6.1.3 muudavad SBOM-i leiud riskihindamise ja riskikäsitluse tõendusmaterjaliks. Kriitiline haavatav komponent internetile avatud autentimisteenuses ei ole pelgalt pilet. See on riskistsenaarium, mis mõjutab konfidentsiaalsust, terviklust, käideldavust, lepingulisi kohustusi, regulatiivset teavitamist ja talitluspidevust.

SBOM-i vastavustõenduse jaoks kõige asjakohasemad ISO/IEC 27001:2022 Annex A kontrollimeetmed on järgmised:

Clarysec kaardistab need seosed ISO/IEC 27002:2022 atribuutide kaudu Zenith Controls lahenduses. Näiteks käsitleb Zenith Controls ISO/IEC 27002:2022 kontrollimeedet 5.21 „Infoturbe juhtimine IKT tarneahelas” ennetava meetmena, mis kaitseb konfidentsiaalsust, terviklust ja käideldavust, on joondatud küberturvalisuse tuvastamise kontseptsiooniga ning toimib juhtimise, ökosüsteemi ja kaitse valdkondades. Kontrollimeedet 8.25 „Turvaline arenduse elutsükkel” käsitletakse ennetava meetmena, mis on joondatud kaitsega. Kontrollimeedet 8.8 „Tehniliste haavatavuste haldus” käsitletakse ennetava meetmena, mis on joondatud tuvastamise ja kaitsega ning seob haavatavuste halduse juhtimise, ökosüsteemi, kaitse ja kaitsetegevustega.

See tõlgendus on oluline, sest eri läbivaatajad esitavad eri küsimusi. ISO audiitor võib küsida, kas komponentide risk on kohaldatavusdeklaratsioonis. DORA läbivaataja võib küsida, kas komponent toetab kriitilist või olulist funktsiooni. Klient võib küsida, kas lahendamata haavatavused ületavad lepingulisi SLA-sid. Sama SBOM-i tõendusmaterjal saab toetada kõiki kolme, kui seda juhitakse nõuetekohaselt.

Clarysec poliitikakiht auditivalmis SBOM-ide jaoks

Usaldusväärne SBOM-programm vajab poliitikateksti. Arendajad peavad teadma, mida tuleb registreerida. Hange peab teadma, mida tarnijad peavad esitama. Turbefunktsioon peab teadma, millised leiud käivitavad eskalatsiooni. Vastavusfunktsioon peab teadma, millist tõendusmaterjali tuleb säilitada.

Väiksemate organisatsioonide jaoks loob Turvalise arenduse poliitika - VKE minimaalse toimiva SBOM-kontrolli:

Tegevjuht või määratud arendaja peab pidama loendit kõigist kasutatavatest välistest komponentidest, sealhulgas: 6.6.2.1 versioon ja allikas 6.6.2.2 teadaolevad haavatavused või paiga staatus 6.6.2.3 viimase uuenduse või läbivaatamise kuupäev

See nõue on lihtne, kuid mõjus. See loob versioonide nähtavuse, allika jälgitavuse, haavatavuste staatuse ja läbivaatamise sageduse.

Rakendusturbe nõuete poliitika - VKE lisab elutsükli ülevaatuse:

Iga rakenduses kasutatav kolmanda osapoole tööriist, plugin või väline kooditeek tuleb registreerida ning selle turbe mõju ja paikamise staatus tuleb vähemalt kord aastas läbi vaadata.

Haavatavuste ja paikade halduse poliitika - VKE seob SBOM-id parandusmeetmetega:

Arendajad peavad seirama ja uuendama kolmandate osapoolte teeke (nt avatud lähtekoodiga pakette)

Ettevõttekeskkondades tõstab Turvalise arenduse poliitika ootust:

Avatud lähtekoodiga või kolmanda osapoole koodi kasutamine peab olema heaks kiidetud, jälgitud ja valideeritud järgmiste vahenditega:

Samuti muudab see skannimise kohustuslikuks:

Kõiki kolmandate osapoolte komponente tuleb enne juurutamist ja käitusajal automaatsete tööriistade abil haavatavuste suhtes skannida.

Allhankearendus peab järgima sama standardit. Allhankearenduse poliitika nõuab järgmist:

Avatud lähtekoodiga teekide turvaline kasutamine, millele kohaldatakse haavatavuste skannimist ja heakskiitu

Tarnijalepingutes on vaja jõustatavaid tõendusmaterjali õigusi. Kolmandate osapoolte ja tarnijate turbepoliitika - VKE nõuab lepinguklausleid, mis käsitlevad konfidentsiaalsust, turbekohustusi, rikkumisest teavitamise tähtaegu, auditeerimisõigusi, alltöövõtu piiranguid ja turvalist lõpetamist:

Lepingud peavad sisaldama kohustuslikke klausleid, mis käsitlevad järgmist: 5.3.1 konfidentsiaalsus ja mitteavaldamine 5.3.2 infoturbekohustused 5.3.3 andmekaitserikkumisest teatamise tähtajad (nt 24–72 tunni jooksul) 5.3.4 auditeerimisõigused või vastavuse tõendusmaterjali kättesaadavus 5.3.5 edasise alltöövõtu piirangud ilma heakskiiduta 5.3.6 lõpetamistingimused, sealhulgas andmete turvaline tagastamine või hävitamine

Ettevõtteklientide jaoks sisaldab Kolmandate osapoolte ja tarnijate turbepoliitika järgmist:

Õigus auditeerida, kontrollida ja nõuda turbe tõendusmaterjali

Kui SaaS-teenuse pakkuja, allhankearenduse partner või kommertstarkvara tarnija ei anna turbe tõendusmaterjali, haavatavuste staatust, teavitamiskohustusi ega auditi juurdepääsu, on teie tarkvara tarneahela vastavustõenduses pimeala.

Tarnijasõltuvuse riskijuhtimise poliitika muudab sõltuvuste koondumise mõõdetavaks talitluspidevuse riskiks:

Tarnijasõltuvuste register: VMO peab pidama ajakohast registrit kõigist kriitilistest tarnijatest, sh osutatavate teenuste / pakutavate toodete üksikasjad; kas tarnija on ainus allikas; kättesaadavad alternatiivsed tarnijad või asendatavus; kehtivad lepingutingimused; ning hinnang mõjule, kui tarnija peaks tegevuse lõpetama või kompromiteeritaks. Register peab selgelt tuvastama suure sõltuvusega tarnijad (nt need, millele puudub kiiresti kasutusele võetav alternatiiv).

See register peab olema seotud SBOM-idega. Kui kriitiline teek pärineb ainsa allika tarnijalt, toetab reguleeritud kliendi töövoogu ja sellele puudub kiire asendus, ei ole see pelgalt pakett. See on talitluspidevuse sõltuvus.

SBOM-failist operatiivseks kontrollimeetmeks ühe sprindiga

Praktiline SBOM-programm peaks algama ühest tootesarjast ja ühest tootmiskeskkonnast. Ärge püüdke esimesel päeval kogu ettevõtet inventeerida. Kui Amelia FinTech alustab kliendi liitumise ja maksete töövooga, saab meeskond enne laiendamist luua korratava tõendusmudeli.

Samm 1: määratlege SBOM-i kohaldamisala ISMS-is

Looge kohaldamisala avaldus, mis on seotud teie ISMS-i kohaldamisala ja regulatiivsete ajenditega:

• Toode: kliendi liitumise ja maksete SaaS-platvorm
• Keskkond: EL-i tootmiskeskkond
• Repositooriumid: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Build’i süsteemid: Git-teenusepakkuja, CI/CD platvorm, konteineriregister
• Juurutamine: Kubernetes klaster, hallatud andmebaas, objektisalvestus
• Andmed: kontoandmed, autentimislogid, arvelduse metaandmed, makseviited
• Kliendid: EL-i finantsüksused ja ärikliendid
• Regulatiivsed ajendid: ISO 27001:2022, NIS2 kliendi vastavustõendus, DORA kolmandatest isikutest IKT-teenuseosutajate hoolsuskontroll, GDPR turbevastutus

See on kooskõlas ISO 27001 Clause 4 kohaldamisala loogikaga ja NIST CSF profiili määratlemisega.

Samm 2: genereerige ja säilitage SBOM-id build’i ajal

Konfigureerige CI/CD torustikud nii, et iga build’i artefakti, sealhulgas konteinerkujutiste kohta genereeritakse SBOM. Tavapäraselt kasutatakse standardvorminguid, nagu CycloneDX ja SPDX. Säilitage iga SBOM kontrollitud tõendusmaterjali repositooriumis, mis on seotud build ID, commit-räsi, juurutuskirje ja väljalaskeversiooniga.

See toetab otseselt Turvalise arenduse poliitika - VKE nõuet säilitada versioon, allikas, teadaolev haavatavus või paiga staatus ning läbivaatamise kuupäev.

Samm 3: rikastage SBOM-i andmeid ärakasutatavuse ja ärikontekstiga

Ärge piirduge pakettide loendiga. Lisage operatiivse riski kontekst:

• Kas komponent on haavatav?
• Kas haavatav funktsioon on ligipääsetav?
• Kas teenus on internetile avatud?
• Kas teenus töötleb isikuandmeid?
• Kas see toetab DORA kliendi kriitilist või olulist funktsiooni?
• Kas paik on saadaval?
• Kas on olemas kompenseeriv kontrollimeede?
• Kas riskiomanik on riski aktsepteerimise heaks kiitnud?

Kriitiline CVE üksnes testimiseks kasutatavas paketis erineb kriitilisest CVE-st tootmiskeskkonna autentimisteenuses. ISO 27001 riskihindamise ja riskikäsitluse punktid aitavad selle eristuse kaitstavaks muuta.

Samm 4: siduge SBOM-id tarnijate ja allhankearenduse kontrollimeetmetega

Kui komponenti pakub kommertstarnija või allhankearenduse partner, ajakohastage tarnijakirjet:

See toetab NIS2 Article 21 tarneahela turbe nõudeid ja DORA Article 28 ootusi kolmandatest isikutest IKT-teenuseosutajate riskistrateegia, hoolsuskontrolli, lepinguliste kaitsemeetmete, teaberegistrite, auditiplaneerimise, lõpetamisõiguste ja väljumisstrateegiate suhtes.

Samm 5: määratlege parandusmeetmete reeglid ja tõendusmaterjal

Siduge parandusmeetmete SLA-d ärimõjuga, mitte ainult CVSS-skooridega.

Siin muutuvad SBOM-id NIS2, DORA ja GDPR jaoks kasutatavaks. Parandusmeetmete töövoog peab arvestama olulise intsidendi potentsiaali, suure IKT-ga seotud intsidendi mõju, isikuandmetega seotud rikkumise kriteeriume, lepingulisi teavitamiskohustusi ja talitluspidevuse mõju.

Samm 6: lisage väljalaske kontrollvärav

Enne juurutamist nõudke torustikult või muudatusprotsessilt kinnitust, et:

• SBOM genereeriti edukalt;
• kriitilisi heakskiiduta haavatavusi ei ole alles;
• uued kolmandate osapoolte komponendid on heaks kiidetud;
• litsentsipoliitika kontroll on läbitud;
• SCA, SAST, DAST või muu nõutav testimine on lõpule viidud;
• muudatuse pilet on seotud;
• kõrge riskiga väljalasete jaoks on tagasipööramise plaan dokumenteeritud.

See seob A.8.25 turvalise arenduse, A.8.29 turbetestimise ja A.8.32 muudatuste juhtimise üheks auditikõlblikuks töövooks.

Samm 7: koostage väljalaske tõenduspakett

Iga väljalaske kohta säilitage:

• SBOM-fail;
• build ID ja commit-räsi;
• SCA skannimistulemus;
• haavatavuste triaaži kirje;
• heakskiidetud erandid;
• muudatuse heakskiit;
• juurutuskirje;
• testitulemused;
• vajaduse korral tarnija tõendusmaterjal;
• intsidendi- või probleemikirje, kui väljalase parandas haavatavuse.

Kui audiitor küsib, kuidas kolmandate osapoolte teeke tootmiskeskkonnas hallatakse, ei otsi Amelia meeskond vastuseid Slacki lõimedest. Nad avavad väljalaske tõenduspaketi.

Ristvastavuse kaardistus: üks SBOM-programm, mitu kohustust

SBOM-programmi äriline väärtus kasvab, kui see kaardistatakse üks kord ja taaskasutatakse eri raamistikes. Clarysec ristvastavuse lähenemine väldib dubleerivat tööd, tõlkides sama tõendusmaterjali eri vastavustõenduse keeltesse.

NIS2 intsidenditeavituse tähtajad võivad kulgeda kiiresti, kui ärakasutamine põhjustab või võib põhjustada tõsise tegevushäire, rahalise kahju või märkimisväärse materiaalse või mittemateriaalse kahju. NIS2 kasutab etapiviisilist teavitust, sealhulgas varajane hoiatus 24 tunni jooksul teadlikuks saamisest, intsidenditeavitus 72 tunni jooksul ja lõpparuanne ühe kuu jooksul pärast intsidenditeavitust. SBOM-id aitavad määrata, kas mõjutatud komponent on olemas, kas klienditeenused on mõjutatud ja kas piiriülene mõju on usutav.

DORA kasutab struktureeritud IKT intsidendi elutsüklit, mis hõlmab tuvastamist, registreerimist, klassifitseerimist, algpõhjuse analüüsi, eskalatsiooni, kommunikatsiooniplaane, juhtorgani tasandile eskaleerimist ja suurte IKT-ga seotud intsidentide regulatiivset teatamist. SBOM-i tõendusmaterjal toetab klassifitseerimist, sest see seob haavatava komponendi mõjutatud klientide, katkestusaja, geograafilise leviku, andmekao, teenuse kriitilisuse ja majandusliku mõjuga.

NIST CSF 2.0 lisab klientidele vastavustõenduse andmiseks kasuliku keele. Zenith Controls kaardistab A.5.21 tarneahela juhtimise väljunditega, näiteks GV.SC-05, mille kohaselt tarnijatele kehtestatakse küberturvalisuse nõuded, need edastatakse ja integreeritakse lepingutesse ning muudesse kokkulepetesse. SBOM-ide, haavatavuste avalikustamise, auditi tõendusmaterjali ja parandusmeetmete tähtaegade nõudmine muutub lepinguliseks kontrollimeetmeks, mitte ad hoc päringuks.

Kuidas Zenith Blueprint töö järjestab

Zenith Blueprint muudab kontrollikeele rakendamise tegevuskavaks.

Riskijuhtimise etapis seob samm 14 turvalise arenduse, CI/CD kontrollimeetmed, sõltuvuste skannimise, muudatuste juhtimise, intsidentide käsitlemise ja arendajate koolituse. Kontrollimeetmete rakendamise etapis käsitleb samm 20 selgesõnaliselt kolmandate osapoolte ja avatud lähtekoodiga komponente:

See kontrollimeede kohaldub ka kolmandate osapoolte ja avatud lähtekoodiga komponentidele. Välistele teekidele tuginemine on tavapärane praktika, kuid iga kaasamine on usaldusotsus. Arendajad peaksid hindama sõltuvusi maine, hoolduse sageduse, teadaolevate haavatavuste ja litsentsi piirangute alusel. Sellised tööriistad nagu SBOM-id (Software Bill of Materials) on üha olulisemad, et jälgida, mis on teie tehnoloogiapinu sisse ehitatud.

Samm 21 käsitleb turbetestimist kontekstipõhisena ja soovitab ärikriitiliste või internetile avatud süsteemide puhul kihilist testimist, sealhulgas tarkvarakompositsiooni analüüsi kolmandate osapoolte teekidele, staatilist ja dünaamilist analüüsi, penetratsioonitestimist, ohumudeldamise valideerimist, väärkasutusjuhtumite testimist, fuzzing’ut ja käsitsi uurivat testimist.

Samm 23 käsitleb tarnijalepinguid, sealhulgas konfidentsiaalsuskohustusi, juurdepääsukontrolli vastutusi, tehnilisi ja korralduslikke meetmeid, intsidentidest teatamise tähtaegu, auditeerimisõigust, alltöövõtjate kontrolle ja lepingu lõppemise sätteid.

Praktiline õppetund on lihtne. SBOM-id kuuluvad riskijuhtimisse, turvalisse arendusse, testimisse, tarnijajuhtimisse, intsidentidele reageerimisse ja juhtkonna aruandlusse.

Auditi vaade: mida eri läbivaatajad testivad

Küps SBOM-programm peab vastu pidama eri auditistiilidele.

ISO 27001:2022 audiitor alustab ISMS-ist. Ta küsib, kas tarkvara tarneahela risk kuulub kohaldamisalasse, kas huvitatud poolte nõuded hõlmavad NIS2, DORA kliente, GDPR-i ja lepinguid, kas komponentide risk on osa riskimetoodikast, kas kohaldatavusdeklaratsioon sisaldab asjakohaseid Annex A kontrollimeetmeid ning kas poliitikaid rakendatakse järjepidevalt. Ta võib võtta valimisse ühe väljalaske ja jälgida seda poliitikast torustiku, SBOM-i, haavatavuse skannimise, muudatuse heakskiidu, juurutamise ja väljalaskejärgse seireni.

DORA läbivaataja või finantssektori klient keskendub talitluspidevusele ja kolmandatest isikutest IKT-teenuseosutajate riskile. Ta võib küsida, millised komponendid toetavad finantsüksuse kasutatavat teenust, kas teenus toetab kriitilist või olulist funktsiooni, kuidas IKT-varad ja sõltuvused on dokumenteeritud, kas haavatavusi seiratakse, kas iga-aastane testimine hõlmab kriitilisi süsteeme ning kas lepingud sisaldavad abi, auditeerimisõigusi, intsidenditeavitust, andmete asukohta, alltöövõttu ja lõpetamistingimusi.

NIST CSF hindaja vaatab väljundeid. GOVERN all testib ta õiguslikku, regulatiivset, lepingulist, privaatsuse ja tarneahela juhtimist. IDENTIFY all eeldab ta varade, tarkvara ja teenuste nähtavust. PROTECT all testib ta turvalise arenduse ja torustiku kontrollimeetmeid. DETECT ja RESPOND all uurib ta haavatavuste teavitusi, analüüsi, eskalatsiooni ja kommunikatsiooni. RECOVER all küsib ta, kuidas komponendi kompromiteerimine mõjutab taastamist ja kliendisuhtlust.

COBIT- või ISACA-laadne audiitor keskendub juhtimisele, vastutusele, riskivastutusele, kontrollimeetmete disainile ja tõendusmaterjali usaldusväärsusele. Ta võib testida, kas SBOM-id on täielikud, kas haavatavuste piletid suletakse poliitika kohaselt, kas erandid aeguvad, kas tarnija tõendusmaterjal on ajakohane ja kas juhtkond saab sisukat aruandlust.

Levinud SBOM-i vead, mida vältida

SBOM-programmid ebaõnnestuvad tavaliselt etteaimatavatel põhjustel.

Esimene viga on SBOM-ide genereerimine ilma nende kontrollitud tõendusmaterjalina säilitamiseta. Kui fail kirjutatakse iga build’iga üle ja seda ei saa väljalaskega siduda, on see nõrk auditi tõendusmaterjal.

Teine viga on SBOM-ide eraldamine haavatavuste haldusest. Komponentide loend ilma triaaži, omanikluse, parandusmeetmete või riski aktsepteerimiseta ei tõenda kontrollimeetme toimimist.

Kolmas viga on transitiivsete sõltuvuste välistamine. Haavatavused peituvad sageli otsese sõltuvuskihi all.

Neljas viga on allhankearenduse jätmine protsessist välja. Kui tarnija tarnib koodi ilma komponentide avalikustamise, skannimise tõendusmaterjali või heakskiidukirjeteta, on tarkvara tarneahelas haldamata pimeala.

Viies viga on tarnijalepingute sõlmimine ilma tõendusmaterjali õigusteta. Hange allkirjastab lepingu, arendusmeeskond kasutab teenust ja turbefunktsioon avastab hiljem, et puudub auditeerimisõigus, haavatavuste avalikustamise kohustus, alltöövõtja piirang ja väljumistugi.

Kuues viga on komponentide äriliste teenustega kaardistamata jätmine. Haavatav pakett ei tähenda palju enne, kui on teada, kas see mõjutab autentimist, makseid, aruandlust, patsiendiandmeid, pilvehaldust, kliendi liitumist või reguleeritud finantsprotsessi.

Seitsmes viga on lahendamata kriitiliste haavatavuste varjamine juhtkonna eest. NIS2 ja DORA muudavad juhtkonna vastutuse selgesõnaliseks. Kriitiline komponendirisk peab olema juhtimisfoorumitele nähtav, mitte peidetud arenduse tööjärjekordadesse.

Milline näeb hea välja 2026. aastal

Auditivalmis SBOM-programmil on nähtavad tunnused.

Olemas on heakskiidetud poliitika, mis nõuab kolmandate osapoolte ja avatud lähtekoodiga komponentide heakskiitmist, jälgimist, skannimist ja läbivaatamist. CI/CD torustik genereerib SBOM-id automaatselt. SCA skannimised toimuvad enne juurutamist ja vajaduse korral käitusajal. Kriitilised haavatavused käivitavad määratletud eskalatsiooni. Eranditel on omanikud, aegumiskuupäevad, kompenseerivad kontrollimeetmed ja riski aktsepteerimine.

Tarnijalepingud sisaldavad turbekohustusi, rikkumisest teavitamise tähtaegu, auditeerimisõigusi, alltöövõtu kontrolle ja lõpetamissätteid. Kriitilisi tarnijaid vaadatakse läbi vähemalt kord aastas. Tarnijasõltuvused ja kontsentratsiooniriskid on nähtavad. Allhankearenduse meeskonnad järgivad samu turvalise arenduse ja komponentide heakskiidu reegleid nagu sisemised meeskonnad.

Juhtkonna aruandlus seob tehnilise riski ärimõjuga:

• kriitilised haavatavad komponendid toote kaupa;
• kokkupuude kliendi või reguleeritud teenuse kaupa;
• avatud parandusmeetmed üle SLA;
• komponendid ilma heakskiidetud allikata;
• toetuseta või elutsükli lõppu jõudnud teegid;
• tarnija tõendusmaterjali puudujäägid;
• uuendamist või sulgemist ootavad erandid;
• komponentide haavatavustega seotud intsidendid.

Siis lakkavad SBOM-id olemast vastavusartefakt ja muutuvad juhtimisvahendiks.

Muutke SBOM-id kaitstavaks vastavuse tõendusmaterjaliks

Järgmine kord, kui kriitilise komponendi teavitus saabub kell 07.42, ei tohiks vastus olla: „Meil on vaja kaks tundi, et teada saada, kus see asub.”

Vastus peaks olema: „Siin on mõjutatud komponent, siin on teenused, siin on kliendid, siin on riskihinnang, siin on parandusplaan ja siin on tõendusmaterjal.”

Clarysec aitab teil sellise kontrollisüsteemi kujundada. Aitame organisatsioonidel määratleda SBOM-i kohaldamisala ISMS-is, kaardistada ISO 27001:2022 Annex A kontrollimeetmed NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT-laadsete auditi ootustega, rakendada turvalise arenduse ja tarnijate poliitikaid, koostada väljalaske tõenduspakette ning valmistada ette auditivalmis vastavustõendust Zenith Controls ja Zenith Blueprint abil.

Kas olete valmis muutma oma tarkvara tarneahela ebakindluse allikast tegevuskerksuse tõenduseks?

Laadige alla asjakohased Clarysec poliitikad, kasutage rakendamise järjestamiseks Zenith Blueprint lahendust ja kasutage Zenith Controls lahendust, et kaardistada oma tõendusmaterjal ISO 27001:2022, NIS2, DORA ja klientide vastavustõenduse nõuete lõikes. Võtke Claryseciga ühendust, et alustada fokuseeritud SBOM-i valmisoleku hindamisega ning luua praktiline, auditivalmis tarkvara tarneahela vastavustõenduse programm.