SBOM ISO 27001, NIS2 un DORA apliecināšanai

Ir piektdienas 07:42, kad Amēlija, strauji augoša FinTech uzņēmuma informācijas drošības vadītāja, saņem brīdinājumu, kuru neviens drošības vadītājs nevēlas redzēt.

Plaši izmantotai atvērtā pirmkoda pakotnei ir kritiska attālinātas koda izpildes ievainojamība. Programmatūras sastāva analīzes rīks norāda, ka komponents varētu būt autentifikācijas pakalpojumā, iespējams, norēķinu modulī un varbūt arī trešās puses API ietvarā, kas tiek izmantots maksājumu darbplūsmā. Inženierijas komandai nepieciešams laiks apstiprināšanai. Juridiskais dienests jautā, vai ir sācies NIS2 paziņošanas termiņš. DORA programmas vadītājs jautā, vai ietekmētais pakalpojums atbalsta finanšu subjekta kritisku vai svarīgu funkciju. Pārdošanas komanda jautā, vai tas bloķēs līguma atjaunošanu. Valde uzdod vienkāršāko un vienlaikus sarežģītāko jautājumu: “Vai mēs esam pakļauti riskam?”

Bez programmatūras sastāva saraksta godīga atbilde bieži ir: “Mēs vēl nezinām.”

2026. gadā šāda atbilde nav tikai tehniska nepilnība. Tā ir pārvaldības vājā vieta, līgumisks risks, audita ekspozīcija un regulētiem subjektiem — noturības problēma. SBOM no DevSecOps higiēnas prakses ir kļuvuši par valdes līmeņa pierādījumiem programmatūras piegādes ķēdes apliecināšanai, ISO/IEC 27001:2022 kontroles pasākumu darbībai, NIS2 kiberdrošības risku pārvaldībai, DORA IKT trešo pušu pārvaldībai, GDPR pārskatatbildībai un klientu sākotnējai izpētei.

Būtiskākais nav tikai SBOM faila ģenerēšana. Būtiskākais ir pierādīt, ka programmatūras komponenti ir identificēti, apstiprināti, uzraudzīti, novērtēti pēc riska, ielāpoti, pārvaldīti līgumiski un izsekojami līdz atbildīgajiem īpašniekiem. Tieši šeit Clarysec politiku bibliotēka, Zenith Blueprint: An Auditor’s 30-Step Roadmap un Zenith Controls: The Cross-Compliance Guide pārvērš izstrādātāja artefaktu par pamatotiem atbilstības pierādījumiem.

Kāpēc SBOM tagad ir programmatūras piegādes ķēdes apliecināšanas pierādījumi

SBOM ir programmatūras komponentu uzskaite, kas ietver atvērtā pirmkoda pakotnes, komerciālās bibliotēkas, versijas, avotus, licences un atkarību attiecības. Noderīgs SBOM palīdz atbildēt uz četriem jautājumiem, kas tagad ir svarīgi regulatoriem, klientiem un valdēm:

1. Kas ir mūsu programmatūras sastāvā?
2. Kur tā ir izvietota?
3. Vai tā ir ievainojama, neatbalstīta, nelicencēta vai neapstiprināta?
4. Kurš ir atbildīgs par ievainojamības novēršanu, mazināšanu vai riska pieņemšanu?

Šie jautājumi tieši atbilst mūsdienu tiesiskajām un regulatīvajām prasībām.

NIS2 attiecas uz daudzām vidējām un lielām struktūrām būtiskās un svarīgās nozarēs, tostarp digitālo infrastruktūru, mākoņdatošanas pakalpojumu sniedzējiem, datu centru pakalpojumu sniedzējiem, pārvaldīto pakalpojumu sniedzējiem, pārvaldīto drošības pakalpojumu sniedzējiem, tiešsaistes tirdzniecības vietām, meklētājprogrammām, sociālo tīklu platformām un noteiktiem digitālo pakalpojumu sniedzējiem. Tā var būt piemērojama arī, pamatojoties uz nacionālu noteikšanu un nozarei specifisku transponēšanu. Subjektiem, uz kuriem attiecas regulējums, NIS2 prasa, lai vadības struktūras apstiprina kiberdrošības risku pārvaldības pasākumus un pārrauga to ieviešanu. Article 21 ietver piegādes ķēdes drošību, drošu iegādi, drošu izstrādi un uzturēšanu, ievainojamību pārvaldību un izpaušanu, incidentu apstrādi, darbības nepārtrauktību, aktīvu pārvaldību, piekļuves kontroli, kriptogrāfiju, efektivitātes izvērtēšanu un kiberdrošības higiēnu.

DORA, kas ir piemērojama no 2025. gada 17. janvāra, finanšu subjektiem izveido vienotu ES digitālās darbības noturības ietvaru. Tā aptver IKT risku pārvaldību, ar IKT saistītu incidentu ziņošanu, noturības testēšanu, IKT trešo pušu risku pārvaldību, līgumiskās vienošanās un kritisku IKT trešo pušu pakalpojumu sniedzēju pārraudzību. DORA sagaida, ka finanšu subjekti identificē IKT aktīvus, ar IKT atbalstītas biznesa funkcijas, atkarības, savienojumus, ievainojamības, riska scenārijus, izmaiņas un trešo pušu atbalstītus procesus.

GDPR pievieno privātuma slāni. Ja ievainojams komponents ietekmē sistēmas, kurās tiek apstrādāti personas dati, jautājums ir, vai personas datiem varētu būt nesankcionēti piekļūts, vai tie varētu būt mainīti, zaudēti, izpausti vai citādi kompromitēti. Pārziņiem un apstrādātājiem ir vajadzīgi pierādījumi, ka tie spēj identificēt ietekmētās sistēmas, datu plūsmas, apakšapstrādātājus un pārkāpuma ietekmi.

NIST CSF 2.0 pastiprina to pašu darbības modeli ar GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER. Tā piegādes ķēdes rezultāti paredz piegādātāju atbildību, kritiskumu, līgumiskās prasības, sākotnējo izpēti, uzraudzību, incidentu plānošanu un attiecību izbeigšanas noteikumus.

Kad Amēlijas valde jautā, vai FinTech uzņēmums ir pakļauts riskam, organizācija, kas balstās uz SBOM, var atbildēt ar pierādījumiem:

• Kuri produkti un laidieni satur ievainojamo komponentu
• Kuras izvietotās vides ir ietekmētas
• Kuri klienti, reģioni, funkcijas un datu plūsmas ir saistītas
• Kurš piegādātājs vai iekšējais īpašnieks ir atbildīgs
• Kuri kompensējošie kontroles pasākumi ir aktīvi
• Vai var tikt sasniegti NIS2, DORA, GDPR vai līgumiskie sliekšņi
• Kurš labojums, mazināšanas pasākums, izņēmums vai riska pieņemšana ir apstiprināta

Tā ir atšķirība starp komponentu sarakstu un kontroles sistēmu.

ISO 27001:2022 ir SBOM pārvaldības pamats

ISO/IEC 27001:2022 ir spēcīgs pamats SBOM pārvaldībai, jo tas ir pārvaldības sistēmas standarts, nevis tikai tehnisks kontrolsaraksts. Tā punkti prasa organizācijām definēt kontekstu, ieinteresētās puses, darbības jomu, vadības apņemšanos, politiku, lomas, risku izvērtēšanu, riska apstrādi, mērķus, veiktspējas novērtēšanu, iekšējo auditu, vadības pārskatīšanu un nepārtrauktu uzlabošanu.

SBOM programmas neizdodas, ja tās atrodas ārpus IDPS. Inženierija var ģenerēt failus, bet neviens nepiemēro ievainojamību novēršanas SLA, piegādātāju pienākumus, pierādījumu glabāšanu, riska pieņemšanu vai klientu informēšanas noteikumus. ISO 27001 to atrisina, pārvēršot SBOM par organizācijas risku pārvaldības sistēmas daļu.

Saskaņā ar punktiem 4.1 līdz 4.4 organizācija nosaka iekšējos un ārējos jautājumus, ieinteresēto pušu prasības, juridiskos un regulatīvos pienākumus, līgumiskās gaidas un IDPS darbības jomu. SBOM apliecināšanai darbības jomā skaidri jāiekļauj:

• Produkti un pakalpojumi, kas tiek piegādāti klientiem
• Mākoņa un SaaS ražošanas vides
• CI/CD konveijeri, pirmkoda repozitoriji un artefaktu reģistri
• Atvērtā pirmkoda un komerciālie programmatūras komponenti
• Ārpakalpojuma izstrādes un integrācijas partneri
• IKT trešo pušu pakalpojumu sniedzēji un apakšuzņēmēji
• Klientu drošības prasības saskaņā ar DORA, NIS2, GDPR un līgumiem

Punkti 5.1 līdz 5.3 padara programmatūras piegādes ķēdes risku par vadības jautājumu. Vadībai ir jāsaskaņo drošības mērķi ar biznesa virzienu, jānodrošina resursi, jāpiešķir atbildība un jākomunicē politika. Punkti 6.1.2 un 6.1.3 pārvērš SBOM konstatējumus risku izvērtēšanas un riska apstrādes pierādījumos. Kritiska ievainojama komponente internetam pieejamā autentifikācijas pakalpojumā nav tikai pieteikums. Tas ir riska scenārijs, kas ietekmē konfidencialitāti, integritāti, pieejamību, līgumiskās saistības, regulatīvo ziņošanu un darbības noturību.

Būtiskākie ISO/IEC 27001:2022 Annex A kontroles pasākumi SBOM apliecināšanai ir:

Clarysec kartē šīs attiecības, izmantojot ISO/IEC 27002:2022 atribūtus Zenith Controls. Piemēram, Zenith Controls traktē ISO/IEC 27002:2022 kontroles pasākumu 5.21 “Informācijas drošības pārvaldība IKT piegādes ķēdē” kā preventīvu, kas aizsargā konfidencialitāti, integritāti un pieejamību, ir saskaņots ar Identify kiberdrošības konceptu un darbojas pārvaldības, ekosistēmas un aizsardzības jomās. Kontroles pasākums 8.25 “Drošas izstrādes dzīves cikls” tiek traktēts kā preventīvs un saskaņots ar Protect. Kontroles pasākums 8.8 “Tehnisko ievainojamību pārvaldība” tiek traktēts kā preventīvs un saskaņots ar Identify un Protect, sasaistot ievainojamību pārvaldību ar pārvaldību, ekosistēmu, aizsardzību un aizstāvēšanu.

Šāds tulkojums starp kontroles valodām ir būtisks, jo dažādi pārbaudītāji uzdod atšķirīgus jautājumus. ISO auditors var jautāt, vai komponentu risks ir iekļauts piemērojamības deklarācijā (SoA). DORA pārbaudītājs var jautāt, vai komponents atbalsta kritisku vai svarīgu funkciju. Klients var jautāt, vai neatrisinātās ievainojamības pārsniedz līgumiskos SLA. Tie paši SBOM pierādījumi var atbalstīt visus trīs, ja tie tiek pareizi pārvaldīti.

Clarysec politikas slānis auditam gataviem SBOM

Uzticamai SBOM programmai ir vajadzīga politikas valoda. Izstrādātājiem jāzina, kas jāreģistrē. Iepirkumam jāzina, kas piegādātājiem jānodrošina. Drošības komandai jāzina, kuri konstatējumi izraisa eskalāciju. Atbilstības funkcijai jāzina, kuri pierādījumi jāglabā.

Mazākām organizācijām Secure Development Policy - SME izveido minimāli pietiekamu SBOM kontroles pasākumu:

Ģenerāldirektoram vai norīkotam izstrādātājam jāuztur visu izmantoto ārējo komponentu saraksts, tostarp: 6.6.2.1 Versija un avots 6.6.2.2 Zināmās ievainojamības vai ielāpu statuss 6.6.2.3 Pēdējās atjaunināšanas vai pārskatīšanas datums

Šī prasība ir vienkārša, bet spēcīga. Tā nosaka versiju redzamību, avota izsekojamību, ievainojamību statusu un pārskatīšanas regularitāti.

Application Security Requirements Policy - SME pievieno dzīves cikla pārskatīšanu:

Jebkurš trešās puses rīks, spraudnis vai ārēja koda bibliotēka, kas tiek izmantota lietojumprogrammā, ir jāreģistrē un katru gadu jāpārskata attiecībā uz drošības ietekmi un ielāpu statusu.

Vulnerability and Patch Management Policy - SME sasaista SBOM ar ievainojamību novēršanu:

Izstrādātājiem jāuzrauga un jāatjaunina trešo pušu bibliotēkas (piemēram, atvērtā pirmkoda pakotnes)

Uzņēmuma līmeņa vidēm Secure Development Policy paaugstina prasību līmeni:

Atvērtā pirmkoda vai trešās puses koda izmantošana jāapstiprina, jāizseko un jāvalidē, izmantojot:

Tā arī nosaka skenēšanu kā obligātu:

Visi trešo pušu komponenti pirms ieviešanas un izpildlaikā jāskenē ievainojamību noteikšanai, izmantojot automatizētus rīkus.

Ārpakalpojuma izstrādei jāievēro tas pats standarts. Outsourced Development Policy prasa:

Droša atvērtā pirmkoda bibliotēku izmantošana, pakļaujot tās ievainojamību skenēšanai un apstiprināšanai

Piegādātāju līgumiem ir vajadzīgas izpildāmas tiesības uz pierādījumiem. Third-Party and Supplier Security Policy - SME prasa līguma klauzulas par konfidencialitāti, drošības pienākumiem, paziņošanas par pārkāpumu termiņiem, audita tiesībām, apakšuzņēmēju piesaistes ierobežojumiem un drošu izbeigšanu:

Līgumos jāiekļauj obligātas klauzulas par: 5.3.1 Konfidencialitāti un neizpaušanu 5.3.2 Informācijas drošības pienākumiem 5.3.3 Paziņošanas termiņiem datu aizsardzības pārkāpuma gadījumā (piemēram, 24–72 stundu laikā) 5.3.4 Audita tiesībām vai atbilstības pierādījumu pieejamību 5.3.5 Ierobežojumiem turpmākai apakšuzņēmēju piesaistei bez apstiprinājuma 5.3.6 Izbeigšanas noteikumiem, tostarp drošai datu atdošanai vai iznīcināšanai

Uzņēmuma līmeņa klientiem Third party and supplier security policy ietver:

Tiesības auditēt, pārbaudīt un pieprasīt drošības pierādījumus

Ja SaaS pakalpojumu sniedzējs, ārpakalpojuma izstrādes partneris vai komerciālas programmatūras piegādātājs nenodrošina drošības pierādījumus, ievainojamību statusu, paziņošanas saistības vai audita piekļuvi, jūsu programmatūras piegādes ķēdes apliecinājumā ir aklā zona.

Supplier Dependency Risk Management Policy pārvērš atkarību koncentrāciju izmērāmā noturības riskā:

Piegādātāju atkarību reģistrs: Piegādātāju pārvaldības birojam (VMO) jāuztur aktuāls visu kritisko piegādātāju reģistrs, tostarp informācija par sniegtajiem pakalpojumiem/produktiem; vai piegādātājs ir vienīgais piegādes avots; pieejamajiem alternatīvajiem piegādātājiem vai aizstājamību; spēkā esošajiem līguma noteikumiem; un ietekmes izvērtējumu, ja piegādātājs pārtrauktu darbību vai tiktu kompromitēts. Reģistrā skaidri jāidentificē augstas atkarības piegādātāji (piemēram, tie, kuriem nav ātri pieejamas alternatīvas).

Šis reģistrs jāsasaista ar SBOM. Ja kritiska bibliotēka nāk no vienīgā piegādes avota piegādātāja, atbalsta regulēta klienta darbplūsmu un tai nav ātri pieejama aizstājēja, tā nav tikai pakotne. Tā ir noturības atkarība.

No SBOM faila līdz operacionālam kontroles pasākumam vienā sprintā

Praktiska SBOM programma jāsāk ar vienu produktu līniju un vienu ražošanas vidi. Nemēģiniet pirmajā dienā inventarizēt visu uzņēmumu. Ja Amēlijas FinTech sāk ar klientu sākotnējās piesaistes un maksājumu darbplūsmu, komanda var izveidot atkārtojamu pierādījumu modeli pirms mērogošanas.

1. solis: definējiet SBOM darbības jomu IDPS ietvaros

Izveidojiet darbības jomas paziņojumu, kas sasaistīts ar jūsu IDPS darbības jomu un regulatīvajiem virzītājspēkiem:

• Produkts: klientu sākotnējās piesaistes un maksājumu SaaS platforma
• Vide: ES ražošana
• Repozitoriji: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Būvēšanas sistēmas: Git pakalpojumu sniedzējs, CI/CD platforma, konteineru reģistrs
• Ieviešana: Kubernetes klasteris, pārvaldīta datubāze, objektu glabātuve
• Dati: kontu dati, autentifikācijas žurnāli, norēķinu metadati, maksājumu atsauces
• Klienti: ES finanšu subjekti un komerciālie klienti
• Regulatīvie virzītājspēki: ISO 27001:2022, NIS2 klientu apliecinājums, DORA IKT trešo pušu sākotnējā izpēte, GDPR drošības pārskatatbildība

Tas atbilst ISO 27001 4. punkta darbības jomas loģikai un NIST CSF profila darbības jomas noteikšanai.

2. solis: ģenerējiet un glabājiet SBOM būvēšanas laikā

Konfigurējiet CI/CD konveijerus tā, lai SBOM tiktu ģenerēts katram būvējuma artefaktam, tostarp konteineru attēliem. Parasti tiek izmantoti standarta formāti, piemēram, CycloneDX un SPDX. Glabājiet katru SBOM kontrolētā pierādījumu repozitorijā, kas sasaistīts ar būvējuma ID, komita jaucējvērtību, ieviešanas ierakstu un laidiena versiju.

Tas tieši atbalsta Secure Development Policy - SME prasību uzturēt versiju, avotu, zināmo ievainojamību vai ielāpu statusu un pārskatīšanas datumu.

3. solis: papildiniet SBOM datus ar izmantojamību un biznesa kontekstu

Neapstājieties pie pakotņu saraksta. Pievienojiet operacionālā riska kontekstu:

• Vai komponents ir ievainojams?
• Vai ievainojamā funkcija ir sasniedzama?
• Vai pakalpojums ir pieejams internetā?
• Vai pakalpojums apstrādā personas datus?
• Vai tas atbalsta DORA klienta kritisku vai svarīgu funkciju?
• Vai ir pieejams ielāps?
• Vai ir kompensējošs kontroles pasākums?
• Vai riska īpašnieks ir apstiprinājis riska pieņemšanu?

Kritiska CVE tikai testēšanai paredzētā pakotnē atšķiras no kritiskas CVE ražošanas autentifikācijas pakalpojumā. ISO 27001 risku izvērtēšanas un apstrādes punkti palīdz šo atšķirību padarīt pamatotu.

4. solis: sasaistiet SBOM ar piegādātāju un ārpakalpojuma izstrādes kontroles pasākumiem

Ja komponentu nodrošina komerciāls piegādātājs vai ārpakalpojuma izstrādes partneris, atjauniniet piegādātāja ierakstu:

Tas atbalsta NIS2 Article 21 piegādes ķēdes drošību un DORA Article 28 prasības attiecībā uz IKT trešo pušu riska stratēģiju, sākotnējo izpēti, līgumiskajiem drošības pasākumiem, informācijas reģistriem, audita plānošanu, izbeigšanas tiesībām un izstāšanās stratēģijām.

5. solis: definējiet ievainojamību novēršanas noteikumus un pierādījumus

Piesaistiet ievainojamību novēršanas SLA biznesa ietekmei, nevis tikai CVSS vērtējumam.

Šeit SBOM kļūst noderīgi NIS2, DORA un GDPR vajadzībām. Novēršanas darbplūsmai jāņem vērā būtiska incidenta potenciāls, būtiska ar IKT saistīta incidenta ietekme, personas datu aizsardzības pārkāpuma kritēriji, līgumiskie paziņošanas pienākumi un darbības noturības ietekme.

6. solis: pievienojiet laidiena kontroles vārtus

Pirms ieviešanas pieprasiet, lai konveijers vai izmaiņu process apstiprina:

• SBOM ir sekmīgi ģenerēts
• Nav palikušu kritisku neapstiprinātu ievainojamību
• Jauni trešo pušu komponenti ir apstiprināti
• Licenču politika ir izpildīta
• SCA, SAST, DAST vai cita nepieciešamā testēšana ir pabeigta
• Izmaiņu pieteikums ir sasaistīts
• Augsta riska laidieniem ir dokumentēts atcelšanas plāns

Tas savieno A.8.25 drošu izstrādi, A.8.29 drošības testēšanu un A.8.32 izmaiņu pārvaldību vienā auditējamā darbplūsmā.

7. solis: izveidojiet laidiena pierādījumu paketi

Katram laidienam glabājiet:

• SBOM failu
• Būvējuma ID un komita jaucējvērtību
• SCA skenēšanas izvaddatus
• Ievainojamību sākotnējās izvērtēšanas un prioritizēšanas ierakstu
• Apstiprinātos izņēmumus
• Izmaiņu apstiprinājumu
• Ieviešanas ierakstu
• Testēšanas rezultātus
• Piegādātāju pierādījumus, ja piemērojams
• Incidenta vai problēmas ierakstu, ja laidienā tika novērsta ievainojamība

Kad auditors jautā, kā trešo pušu bibliotēkas tiek pārvaldītas ražošanas vidē, Amēlijas komandai nav jāmeklē Slack pavedienos. Tā atver laidiena pierādījumu paketi.

Savstarpējās atbilstības kartēšana: viena SBOM programma, daudzi pienākumi

SBOM programmas komerciālā vērtība palielinās, ja tā tiek vienreiz kartēta un atkārtoti izmantota dažādos ietvaros. Clarysec savstarpējās atbilstības pieeja novērš dubultu darbu, pārtulkojot tos pašus pierādījumus dažādās apliecinājuma valodās.

NIS2 incidentu ziņošana var kļūt ļoti ātra, ja ekspluatācija izraisa vai var izraisīt smagus darbības traucējumus, finanšu zaudējumus vai būtisku materiālu vai nemateriālu kaitējumu. NIS2 izmanto pakāpenisku ziņošanu, tostarp agrīnu brīdinājumu 24 stundu laikā pēc informētības iegūšanas, incidenta paziņojumu 72 stundu laikā un galīgo ziņojumu viena mēneša laikā pēc incidenta paziņojuma. SBOM palīdz noteikt, vai ietekmētais komponents ir klātesošs, vai ir ietekmēti klientu pakalpojumi un vai pārrobežu ietekme ir ticama.

DORA izmanto strukturētu IKT incidentu dzīves ciklu, tostarp atklāšanu, reģistrēšanu, klasifikāciju, pamatcēloņa analīzi, eskalāciju, komunikācijas plānus, eskalāciju vadības struktūrai un regulatīvo ziņošanu par būtiskiem ar IKT saistītiem incidentiem. SBOM pierādījumi atbalsta klasifikāciju, jo tie sasaista ievainojamu komponentu ar ietekmētajiem klientiem, dīkstāvi, ģeogrāfisko izplatību, datu zudumiem, pakalpojuma kritiskumu un ekonomisko ietekmi.

NIST CSF 2.0 pievieno noderīgu valodu klientu apliecinājumam. Zenith Controls kartē A.5.21 uz piegādes ķēdes pārvaldības rezultātiem, piemēram, GV.SC-05, kur kiberdrošības prasības piegādātājiem tiek noteiktas, komunicētas un integrētas līgumos un citās vienošanās. SBOM, ievainojamību izpaušanas, audita pierādījumu un novēršanas termiņu pieprasīšana kļūst par līgumisku kontroles pasākumu, nevis ad hoc pieprasījumu.

Kā Zenith Blueprint secīgi strukturē darbu

Zenith Blueprint pārvērš kontroles valodu ieviešanas ceļkartē.

Risku pārvaldības posmā 14. solis sasaista drošu izstrādi, CI/CD kontroles pasākumus, atkarību skenēšanu, izmaiņu pārvaldību, incidentu apstrādi un izstrādātāju apmācību. Posmā “Kontroles pasākumi darbībā” 20. solis skaidri attiecas uz trešo pušu un atvērtā pirmkoda komponentiem:

Šis kontroles pasākums attiecas arī uz trešo pušu un atvērtā pirmkoda komponentiem. Paļaušanās uz ārējām bibliotēkām ir standarta prakse, taču katra iekļaušana ir uzticēšanās lēmums. Izstrādātājiem jāizvērtē atkarības, balstoties uz reputāciju, uzturēšanas biežumu, zināmām ievainojamībām un licenču ierobežojumiem. Tādi rīki kā SBOM (programmatūras sastāva saraksts) kļūst arvien svarīgāki, lai izsekotu, kas ir iekļauts jūsu tehnoloģiju stekā.

21. solis nosaka drošības testēšanu kā no konteksta atkarīgu un iesaka slāņveida testēšanu darbībkritiskiem vai internetam pieejamiem sistēmu risinājumiem, tostarp programmatūras sastāva analīzi trešo pušu bibliotēkām, statisko un dinamisko analīzi, ielaušanās testēšanu, draudu modelēšanas validāciju, nepareizas lietošanas gadījumu testēšanu, fuzzing un manuālu izpētes testēšanu.

22. solis aptver piegādātāju līgumus, tostarp konfidencialitātes pienākumus, piekļuves kontroles pienākumus, tehniskos un organizatoriskos pasākumus, incidentu ziņošanas termiņus, audita tiesības, apakšuzņēmēju kontroles pasākumus un līguma beigu noteikumus.

Praktiskā mācība ir vienkārša. SBOM vieta ir risku pārvaldībā, drošā izstrādē, testēšanā, piegādātāju pārvaldībā, reaģēšanā uz incidentiem un vadības ziņošanā.

Audita skatpunkts: ko pārbaudīs dažādi pārbaudītāji

Nobriedušai SBOM programmai jāiztur dažādi audita stili.

ISO 27001:2022 auditors sāks ar IDPS. Viņš jautās, vai programmatūras piegādes ķēdes risks ir darbības jomā, vai ieinteresēto pušu prasības ietver NIS2, DORA klientus, GDPR un līgumus, vai komponentu risks ir daļa no riska metodoloģijas, vai piemērojamības deklarācijā (SoA) ir iekļauti attiecīgie Annex A kontroles pasākumi un vai politikas tiek ieviestas laika gaitā. Auditors var atlasīt vienu laidienu un izsekot to no politikas līdz konveijeram, SBOM, ievainojamību skenēšanai, izmaiņu apstiprinājumam, ieviešanai un uzraudzībai pēc laidiena.

DORA pārbaudītājs vai finanšu klients koncentrēsies uz darbības noturību un IKT trešo pušu risku. Viņš var jautāt, kuri komponenti atbalsta finanšu subjekta izmantoto pakalpojumu, vai pakalpojums atbalsta kritisku vai svarīgu funkciju, kā ir dokumentēti IKT aktīvi un atkarības, vai ievainojamības tiek uzraudzītas, vai ikgadējā testēšana aptver kritiskās sistēmas un vai līgumos ir iekļauts atbalsts, audita tiesības, incidentu paziņošana, datu atrašanās vieta, apakšuzņēmēju piesaiste un izbeigšanas noteikumi.

NIST CSF izvērtētājs meklēs rezultātus. GOVERN ietvaros viņš pārbaudīs juridisko, regulatīvo, līgumisko, privātuma un piegādes ķēdes pārvaldību. IDENTIFY ietvaros viņš sagaidīs aktīvu, programmatūras un pakalpojumu redzamību. PROTECT ietvaros viņš pārbaudīs drošu izstrādi un konveijera kontroles pasākumus. DETECT un RESPOND ietvaros viņš pārbaudīs ievainojamību brīdinājumus, analīzi, eskalāciju un komunikāciju. RECOVER ietvaros viņš jautās, kā komponenta kompromitēšana ietekmē atjaunošanu un klientu komunikāciju.

COBIT vai ISACA stila auditors koncentrēsies uz pārvaldību, pārskatatbildību, atbildību par risku, kontroles dizainu un pierādījumu uzticamību. Viņš var pārbaudīt, vai SBOM ir pilnīgi, vai ievainojamību pieteikumi tiek slēgti saskaņā ar politiku, vai izņēmumiem beidzas derīguma termiņš, vai piegādātāju pierādījumi ir aktuāli un vai vadība saņem jēgpilnu ziņošanu.

Biežākās SBOM kļūdas, no kurām jāizvairās

SBOM programmas parasti neizdodas paredzamu iemeslu dēļ.

Pirmā kļūda ir SBOM ģenerēšana, tos neglabājot kā kontrolētus pierādījumus. Ja fails tiek pārrakstīts ar katru būvējumu un to nevar sasaistīt ar laidienu, tas ir vājš audita pierādījums.

Otrā kļūda ir SBOM nošķiršana no ievainojamību pārvaldības. Komponentu saraksts bez sākotnējās izvērtēšanas, īpašumtiesībām, novēršanas vai riska pieņemšanas nepierāda kontroles pasākuma darbību.

Trešā kļūda ir tranzitīvo atkarību izslēgšana. Ievainojamības bieži slēpjas zem tiešo atkarību slāņa.

Ceturtā kļūda ir ārpakalpojuma izstrādes atstāšana ārpus procesa. Ja piegādātājs piegādā kodu bez komponentu atklāšanas, skenēšanas pierādījumiem vai apstiprinājuma ierakstiem, programmatūras piegādes ķēdē ir nepārvaldīta aklā zona.

Piektā kļūda ir piegādātāju līgumu parakstīšana bez tiesībām uz pierādījumiem. Iepirkums paraksta vienošanos, inženierija izmanto pakalpojumu, un drošības komanda vēlāk atklāj, ka nav audita tiesību, nav ievainojamību izpaušanas pienākuma, nav apakšuzņēmēju ierobežojumu un nav izstāšanās atbalsta.

Sestā kļūda ir komponentu nekartēšana uz biznesa pakalpojumiem. Ievainojama pakotne nozīmē maz, kamēr nav zināms, vai tā ietekmē autentifikāciju, maksājumus, pārskatu sniegšanu, pacientu datus, mākoņa administrēšanu, klientu sākotnējo piesaisti vai regulētu finanšu darbplūsmu.

Septītā kļūda ir neatrisinātu kritisku ievainojamību slēpšana no vadības. NIS2 un DORA skaidri nosaka vadības pārskatatbildību. Kritiskam komponentu riskam jābūt redzamam pārvaldības forumos, nevis paslēptam inženierijas atlikto darbu sarakstos.

Kā izskatās laba prakse 2026. gadā

Auditam gatavai SBOM programmai ir redzamas pazīmes.

Ir apstiprināta politika, kas prasa trešo pušu un atvērtā pirmkoda komponentus apstiprināt, izsekot, skenēt un pārskatīt. CI/CD konveijers ģenerē SBOM automātiski. SCA skenēšana darbojas pirms ieviešanas un izpildlaikā, kur piemērojams. Kritiskas ievainojamības izraisa definētu eskalāciju. Izņēmumiem ir īpašnieki, derīguma termiņi, kompensējošie kontroles pasākumi un riska pieņemšana.

Piegādātāju līgumos ir iekļauti drošības pienākumi, paziņošanas par pārkāpumu termiņi, audita tiesības, apakšuzņēmēju kontroles pasākumi un izbeigšanas noteikumi. Kritiskie piegādātāji tiek pārskatīti vismaz reizi gadā. Piegādātāju atkarības un koncentrācijas riski ir redzami. Ārpakalpojuma izstrādes komandas ievēro tos pašus drošas izstrādes un komponentu apstiprināšanas noteikumus kā iekšējās komandas.

Vadības ziņošana sasaista tehnisko risku ar ietekmi uz biznesu:

• Kritiskie ievainojamie komponenti pa produktiem
• Pakļautība riskam pa klientiem vai regulētiem pakalpojumiem
• Atvērtie novēršanas darbi ārpus SLA
• Komponenti bez apstiprināta avota
• Neatbalstītas vai dzīves cikla beigās esošas bibliotēkas
• Piegādātāju pierādījumu trūkumi
• Izņēmumi, kas gaida atjaunošanu vai slēgšanu
• Incidenti, kas saistīti ar komponentu ievainojamībām

Šajā brīdī SBOM pārstāj būt atbilstības artefakts un kļūst par vadības rīku.

Pārvērtiet SBOM par pamatotiem atbilstības pierādījumiem

Nākamreiz, kad kritiska komponenta brīdinājums pienāk 07:42, atbildei nevajadzētu būt: “Mums vajag divas stundas, lai noskaidrotu, kur tas atrodas.”

Tai jābūt: “Šeit ir ietekmētais komponents, šeit ir pakalpojumi, šeit ir klienti, šeit ir riska vērtējums, šeit ir novēršanas plāns un šeit ir pierādījumi.”

Clarysec var palīdzēt jums izveidot šādu kontroles sistēmu. Mēs palīdzam organizācijām definēt SBOM darbības jomu IDPS ietvaros, kartēt ISO 27001:2022 Annex A kontroles pasākumus uz NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT stila audita gaidām, ieviest drošas izstrādes un piegādātāju politikas, izveidot laidienu pierādījumu paketes un sagatavot auditam gatavu apliecinājumu, izmantojot Zenith Controls un Zenith Blueprint.

Vai esat gatavi pārvērst savu programmatūras piegādes ķēdi no nenoteiktības avota par noturības pierādījumu?

Lejupielādējiet attiecīgās Clarysec politikas, izmantojiet Zenith Blueprint, lai secīgi strukturētu ieviešanu, un izmantojiet Zenith Controls, lai kartētu pierādījumus starp ISO 27001:2022, NIS2, DORA un klientu apliecinājuma prasībām. Sazinieties ar Clarysec, lai sāktu ar fokusētu SBOM gatavības izvērtēšanu un izveidotu praktisku, auditam gatavu programmatūras piegādes ķēdes apliecinājuma programmu.