Dokumentacijska mapa za varnost izdelka po CRA 2026 z ISO 27001

Proizvajalec povezanih naprav na petkov popoldanski sestanek pokliče svojo vodjo informacijske varnosti, Mario. Prodaja je pravkar zagotovila evropski distribucijski dogovor. Pravna služba sprašuje, ali lahko podjetje podpre skladnost z Aktom o kibernetski odpornosti (CRA). Razvoj pravi, da je varen razvoj »večinoma pokrit«, ker obstajajo pregled izvorne kode, SAST in nameščanje popravkov. Nabava pravi, da so dobavitelji »pod NDA«. Produktne ekipe imajo odvisnosti vdelane programske opreme v enem orodju, popise vmesnikov API v oblaku v drugem, zahtevke glede ranljivosti pa v Jira. Funkcija skladnosti ima dokazila o certifikaciji ISO/IEC 27001:2022, vendar so organizirana okoli korporativnega ISMS, ne okoli vsakega izdelka, danega na trg EU.

Nato pride neprijetno vprašanje: »Če organ EU, stranka, priglašeni organ ali večji distributer leta 2026 zahteva dokumentacijsko mapo za varnost izdelka, jo lahko pripravimo v enem tednu?«

Za številne dobavitelje programske opreme, proizvajalce pametnih naprav in ponudnike povezanih storitev je pošten odgovor ne. Ne zato, ker nimajo varnostnih kontrol, temveč zato, ker so dokazila o varnosti izdelka razpršena. Evidence varnega razvoja so pri razvoju. SBOM se generirajo za posamezne gradnje, vendar niso upravljani. Usklajeno razkrivanje ranljivosti obstaja kot spletna stran, vendar ni vedno povezano s triažo, popravki, varnostnimi obvestili in poprodajnim spremljanjem. Varnost dobaviteljev je skrita v nabavnih pogodbah. Poročanje o incidentih pripada varnostnim operacijam, dokumentacija o skladnosti pa skladnosti izdelkov.

Akt EU o kibernetski odpornosti spreminja operativni model. Kibernetska varnost izdelkov ni več samo dobra praksa ali pogodbena obljuba. Postane obveznost dokazovanja skozi življenjski cikel. Organizacije morajo biti sposobne pokazati, kako so zahteve kibernetske varnosti vgrajene v zasnovo, razvoj, izdajo, obravnavanje ranljivosti, posodobitve in spremljanje po dajanju izdelka na trg.

Tu ISO/IEC 27001:2022 postane zelo uporaben, če se uporablja pravilno. Sam po sebi ni shema certificiranja izdelkov, vendar lahko njegov ISMS ter kontrole za tveganja, sredstva, dobavitelje, varen razvoj, ranljivosti in incidente zagotovijo hrbtenico dokumentacijske mape CRA za varnost izdelka. Cilj ni ustvariti še enega silosa skladnosti. Cilj je obstoječi ISMS pretvoriti v sistem dokazil na ravni izdelka.

Kot Clarysecov Zenith Blueprint: 30-koračni načrt presojevalca navaja v fazi 2, koraku 8, arhitektura dokazil:

“Dokazil se ne sme zbirati šele ob koncu revizijskega cikla. Vgrajena morajo biti v kontrolo, dodeljena lastniku, časovno označena v procesu in ponovno uporabna za vsako obveznost, ki isto vprašanje zastavi z drugačnimi besedami.”

Ta stavek povzema bistvo pripravljenosti na CRA. Vprašanje ni samo: »Ali imamo varen razvoj?« Vprašanje je: »Ali lahko dokažemo varen razvoj, poznavanje komponent, obravnavanje ranljivosti in poprodajno spremljanje za ta izdelek, to različico, to izdajo in ta trg?«

Dokumentacijska mapa CRA za varnost izdelka je živ sistem dokazil

Dokumentacijske mape CRA za varnost izdelka ne smemo obravnavati kot statičen PDF, ki se enkrat pripravi pred izdajo in nato pozabi. Biti mora strukturirana mapa, ki predstavi varnostno zgodbo izdelka od koncepta do konca podpore.

Uporabna mapa pojasni:

1. Kaj je izdelek in kako naj bi se uporabljal.
2. Katero programsko opremo, vdelano programsko opremo, storitve v oblaku in odvisnosti tretjih oseb vključuje.
3. Katera tveganja kibernetske varnosti so bila ocenjena.
4. Katere varnostne zahteve so bile uporabljene.
5. Kako je bil izveden varen razvoj.
6. Kako se ranljivosti sprejemajo, triažirajo, odpravljajo in razkrivajo.
7. Kako se zagotavljajo varne posodobitve.
8. Kako se nadzorujejo dobavitelji in odprtokodne komponente.
9. Kako se incidenti in aktivno izkoriščane ranljivosti eskalirajo.
10. Kako se izdelek spremlja po tem, ko je dan na trg.

Za vodjo informacijske varnosti je to izziv dokazil ISMS. Za vodjo skladnosti izdelkov je to tehnična dokumentacija. Za razvoj je to DevSecOps in upravljanje izdaj. Za izvršno vodstvo je to dostop do trga in obvladovanje odgovornosti.

Napaka je, če se ta področja obravnavajo kot ločeni delovni tokovi. Boljši model je vzpostaviti dokazilno mapo na ravni izdelka, ki se preslika na kontrole ISO/IEC 27001:2022 in ISO/IEC 27002:2022, nato pa se ista dokazila po potrebi navzkrižno preslikajo na NIS2, DORA, GDPR, NIST in COBIT 2019.

Clarysecov Zenith Controls: vodnik za navzkrižno skladnost to opisuje kot verigo od kontrole do dokazila in presojevalca:

“Dokazilna mapa za navzkrižno skladnost mora vsako obveznost preslikati na delujočo kontrolo, ponavljajoči se dokazilni objekt, odgovornega lastnika in revizijski pogled, s katerim bo dokazilo izpodbijano.”

To je disciplina, ki jo priprava na CRA zahteva. Dokumentacijska mapa za varnost izdelka ni zgolj mapa. Je prevodni sloj med produktnim inženiringom, upravljanjem varnosti, presojo skladnosti in zagotavljanjem zaupanja strank.

Najprej vzpostavite dokazilno hrbtenico izdelka

Mapa potrebuje dosledno strukturo, preden ekipe začnejo nalagati zapise. Brez jasne hrbtenice dokazila postanejo kup posnetkov zaslona, izvozov in PDF-jev politik, ki jim noben presojevalec ne more slediti.

Za delavnice pripravljenosti na CRA Clarysec običajno priporoča naslednjo strukturo dokumentacijske mape za varnost izdelka za organizacije, ki že uporabljajo ISMS po ISO/IEC 27001:2022.

Ta tabela ne nadomešča zakonskih obveznosti glede tehnične dokumentacije. Podjetju daje operativni model za njihovo dokazovanje.

V Zenith Blueprint se faza 1, korak 3 osredotoča na opredelitev obsega in meja. Pri CRA ta korak postane specifičen za izdelek. Opredelite družino izdelkov, različice programske opreme, predpostavke uvedbe, uporabniške vloge, povezane storitve, kanale posodobitev in obdobje podpore. Če je obseg ISMS »Corporate SaaS and device management platform«, mora dokumentacijska mapa CRA še vedno odgovoriti na ožje vprašanje: »Kateri izdelek z digitalnimi elementi je dan na trg EU in kaj je vključeno v ta izdelek?«

Preslikajte varen razvoj na zapise na ravni izdelka

Jedro dokumentacijske mape za varnost izdelka so dokazila o vgrajeni varnosti. ISO/IEC 27001:2022 zagotavlja sistem upravljanja. ISO/IEC 27002:2022 zagotavlja smernice za izvajanje prek kontrol, kot so A.8.25 Življenjski cikel varnega razvoja, A.8.27 Varna arhitektura sistemov in inženirska načela, A.8.28 Varno kodiranje ter A.8.29 Varnostno testiranje pri razvoju in sprejemu.

Ključni premik je od splošnih trditev o varnem razvoju k zapisom, vezanim na posamezno izdajo. »Izvajamo pregled izvorne kode« ni dovolj. Mapa mora pokazati, katera izdaja je bila pregledana, katera tveganja so bila obravnavana, kateri varnostni testi so bili uspešni, katere ranljivosti so bile sprejete ali odpravljene in kdo je izdajo odobril.

Clarysecova Enterprise Politika varnega razvoja je zasnovana tako, da zahteva takšno dokazilno sled. V klavzuli 6.1, Zahteve življenjskega cikla varnega razvoja, določa:

“Za vsako izdajo izdelka ali storitve se morajo pred uvedbo v produkcijo hraniti dokumentirana dokazila o varnostnih zahtevah, pregledu zasnove, dejavnostih varnega kodiranja, varnostnem testiranju, odločitvah o odpravi ranljivosti in odobritvi izdaje.”

Ta klavzula je uporabna za CRA, ker varen razvoj pretvori v ponovljiv vzorec dokazil. Presojevalcu ni treba sklepati, da se je varen razvoj zgodil. Pregleda lahko zapis o izdaji.

Za pametni termostat, medicinsko napravo IoT, industrijski senzor ali izdelek, povezan s SaaS, morajo dokazila varnega razvoja vključevati:

• Varnostne zahteve izdelka, preslikane na identificirana tveganja.
• Model groženj ali analizo primerov zlorabe za izdelek in povezane storitve.
• Pregled arhitekture, vključno z mejami zaupanja in zunanjimi vmesniki.
• Standard varnega razvoja kode ter dokazilo o potrditvi ali usposabljanju razvijalcev.
• SAST, DAST, analizo sestave programske opreme, skeniranje skrivnosti in analizo vdelane programske opreme, kjer je primerno.
• Zahtevke za odpravo ugotovitev z visokim tveganjem.
• Zapise o sprejemu tveganja s poslovno in varnostno odobritvijo.
• Kontrolni seznam izdajne kontrolne točke, ki kaže, da so bila varnostna merila izpolnjena.
• Dokazila o kriptografskem podpisovanju in celovitosti posodobitev.
• Predpostavke glede obdobja podpore in konca življenjske dobe.

Druge norme pomagajo okrepiti metodo. ISO/IEC 27005 podpira pristop k tveganjem za temi zapisi. ISO/IEC 27017 je uporaben, kadar so storitve v oblaku del ekosistema izdelka. ISO/IEC 27035 podpira obravnavanje incidentov. ISO/IEC 29147 in ISO/IEC 30111 sta posebej pomembna za razkrivanje ranljivosti in obravnavanje ranljivosti. ISO/IEC 27036 podpira varnost dobaviteljev, kar je pomembno, kadar izdelek vključuje zunanjo programsko opremo, vdelane module, upravljane storitve v oblaku ali knjižnice tretjih oseb.

V Zenith Controls so dokazila varnega razvoja za CRA običajno preslikana okoli tem kontrol ISO/IEC 27002:2022, kot so informacijska varnost pri vodenju projektov, življenjski cikel varnega razvoja, varno kodiranje, varnostno testiranje, upravljanje sprememb in upravljanje tehničnih ranljivosti. Vodnik jih povezuje tudi s popisom sredstev in kontrolami dobaviteljev, ker noben proces varnega razvoja ni popoln, če organizacija ne zna identificirati komponent, ki jih dobavlja.

SBOM obravnavajte kot regulirano dokazilo o izdelku

Software Bill of Materials se pogosto obravnava kot tehnični artefakt. Za pripravljenost na CRA ga je treba obravnavati kot dokazilo o izdelku.

Uporaben SBOM pove, katere komponente so v izdelku, katere različice se uporabljajo, od kod izvirajo, katere licence veljajo, katere ranljivosti vplivajo nanje in katere izdaje jih vsebujejo. Pri vdelani programski opremi in vgrajenih izdelkih lahko to vključuje pakete operacijskega sistema, zagonske nalagalnike, knjižnice, gonilnike, vsebnike, module tretjih oseb in odvisnosti na strani oblaka, ki so potrebne za delovanje izdelka.

Težava je, da številne organizacije SBOM ustvarjajo, vendar jih ne upravljajo. CI/CD cevovod lahko izdela datoteko SPDX ali CycloneDX, vendar nihče ne preveri popolnosti. Varnostna orodja lahko označijo ranljivosti, vendar rezultati niso povezani z različicami izdelka. Nabava lahko odobri dobavitelja, vendar seznam komponent tega dobavitelja ni usklajen z izdanim izdelkom.

Clarysecova Enterprise Politika upravljanja sredstev to vrzel v upravljanju obravnava v klavzuli 5.2, Popis informacij in povezanih sredstev:

“Informacijska sredstva in povezane tehnološke komponente morajo biti identificirani, dodeljeni lastniku, po potrebi razvrščeni in vzdrževani v popisu, ki podpira oceno tveganja, upravljanje ranljivosti, obvladovanje sprememb in revizijska dokazila.”

Za CRA ta klavzula postane specifična za izdelek. SBOM je del popisa povezanih tehnoloških komponent. Potrebuje lastnika, pravilo hrambe, postopek validacije in povezavo z upravljanjem ranljivosti.

Praktično pravilo za dokazila SBOM je preprosto: vsaka izdana različica izdelka mora imeti odobren popis komponent, ki ga je mogoče povezati z artefaktom izdaje. Če organizacija SBOM ne more povezati z natančno sliko vdelane programske opreme, aplikacijskim paketom, povzetkom vsebnika ali izdajo SaaS, je SBOM šibko dokazilo.

Če več kot dve vrstici ne prestaneta preverjanja, težava običajno ni orodje SBOM. Težava je upravljanje. Dokumentacijska mapa za varnost izdelka mora evidentirati korektivni ukrep v ISMS, ker je šibkost dokazil CRA tudi vprašanje učinkovitosti kontrol ISO/IEC 27001:2022.

Povežite CVD z obravnavanjem ranljivosti in upravljanjem izdaj

Usklajeno razkrivanje ranljivosti je eno najbolj vidnih področij pripravljenosti na CRA, ker ga lahko zunanji raziskovalci, stranke in organi neposredno preizkusijo. Objava strani za razkritje ranljivosti ali datoteke security.txt je koristna, vendar je to le vhodna točka. Dokumentacijska mapa za varnost izdelka mora dokazati, da zaledni proces deluje.

Zagovorljiv sklop dokazil za CVD in obravnavanje ranljivosti mora vključevati:

• Javni kanal za razkritje in navodila za oddajo.
• Postopek potrditve prejema za raziskovalce.
• Merila triaže, vključno z oceno resnosti in izkoristljivosti.
• Analizo vpliva na izdelek.
• Lastništvo odprave in ciljne časovne roke.
• Predloge obvestil strankam in komunikacije o posodobitvah.
• Dokazila o varnem razvoju in testiranju popravkov.
• Zapise o usklajeni objavi, kjer je primerno.
• Pridobljene izkušnje in analizo ponavljajočih se trendov ranljivosti.

Clarysecova Enterprise Politika upravljanja ranljivosti, klavzula 6.3, Sprejem, triaža in odprava ranljivosti, določa:

“Prijavljene ranljivosti morajo biti evidentirane, ocenjene glede prizadetih sredstev in izdelkov, prednostno razvrščene glede na tveganje in izkoristljivost, dodeljene odgovornemu lastniku ter spremljane skozi odpravo, preverjanje, komunikacijo in zaprtje.”

Ta klavzula povezuje CVD s SBOM, evidenco sredstev, razvojnimi zahtevki, upravljanjem izdaj in poprodajnim spremljanjem. To je tudi klavzula, ki jo bodo presojevalci naravno testirali: pokažite zapis sprejema, pokažite prizadete izdelke, pokažite triažo, pokažite popravek, pokažite komunikacijo s strankami, pokažite zaprtje.

Obstoječo Politiko upravljanja incidentov informacijske varnosti je treba razširiti tudi na ranljivosti izdelkov, ki postanejo incidenti ali zahtevajo zunanje obveščanje. ISO/IEC 27002:2022 A.5.24 zajema načrtovanje in pripravo upravljanja incidentov, A.5.25 zajema oceno in odločanje o dogodkih informacijske varnosti, A.5.26 zajema odziv na incidente informacijske varnosti, A.5.27 pa učenje iz incidentov.

V Zenith Controls se upravljanje ranljivosti obravnava kot preventivno in korektivno. Preventivna stran vključuje popis, varen razvoj, spremljanje dobaviteljev in varno konfiguracijo. Korektivna stran vključuje zaznavanje, triažo, nameščanje popravkov, komunikacijo in eskalacijo incidentov. Ta razlika je pomembna, ker je poprodajno obravnavanje ranljivosti del obveznosti življenjskega cikla izdelka, ne naknadna misel.

Dokazila dobaviteljev so skrita šibka točka

Dokumentacijska mapa za varnost izdelka bo pogosto najmočneje izpodbijana tam, kjer se proizvajalec zanaša na druge. To vključuje vdelane module, zunanji razvoj vdelane programske opreme, komponente pod tujo blagovno znamko, gostovanje v oblaku, mobilne SDK, plačilne storitve, kriptografske knjižnice in ponudnike upravljane podpore.

Pogost vzorec odpovedi je pogodbena abstrakcija. Proizvajalec reče: »Za to je odgovoren naš dobavitelj.« Pod drobnogledom varnosti izdelka to ni dovolj. Organizacija mora pokazati, da je tveganje dobavitelja identificirano, da so varnostne zahteve sporočene, dokazila zbrana, ranljivosti usklajene in spremembe nadzorovane.

Clarysecova Enterprise Politika varnosti tretjih oseb in dobaviteljev, klavzula 7.1, Varnostne zahteve za dobavitelje, določa:

“Dobavitelji, ki razvijajo, upravljajo, obdelujejo, podpirajo ali bistveno vplivajo na informacijske sisteme, izdelke ali storitve, morajo biti ocenjeni glede na tveganje in zanje morajo veljati varnostne zahteve, ki zajemajo dostop, upravljanje ranljivosti, obveščanje o incidentih, podizvajanje, neprekinjeno poslovanje in zagotavljanje dokazil.”

Za CRA je fraza »bistveno vplivajo na izdelke« ključna. Če lahko komponenta dobavitelja uvede ranljivost, prekine posodobitve, razkrije podatke strank ali ogrozi celovitost naprave, sodi v dokumentacijsko mapo za varnost izdelka.

Ista politika lahko podpira tudi pogodbeno urejanje SBOM. Klavzula 7.3 določa:

“Za vse programske komponente, knjižnice ali operacijske sisteme tretjih oseb, ki se vključijo v izdelke podjetja z digitalnimi elementi, mora dobavitelj na zahtevo zagotoviti strojno berljiv Software Bill of Materials (SBOM) v standardnem formatu, kot sta SPDX ali CycloneDX. Ta zahteva mora biti vključena v vse nabavne in dobaviteljske pogodbe.”

Močan paket dokazil dobaviteljev mora vključevati razvrstitev dobaviteljev po vplivu na izdelek, varnostne zahteve v pogodbah, dokazila dobaviteljev o varnem razvoju za kritične komponente, zaveze dobaviteljev glede razkritja ranljivosti, SBOM ali izjave o komponentah, kjer je izvedljivo, podporo pri popravkih in časovnice konca življenjske dobe, zapise periodičnih pregledov ter eskalacijske poti za ranljivosti, ki izvirajo od dobaviteljev.

ISO/IEC 27002:2022 A.5.19, A.5.20 in A.5.21 zagotavljajo ključne teme kontrol dobaviteljev. ISO/IEC 27036 poglablja varnost odnosov z dobavitelji. V smislu navzkrižne skladnosti NIS2 poudarja dobavno verigo in obravnavanje ranljivosti. DORA poudarja tveganje tretjih oseb IKT za finančne subjekte. GDPR postane relevanten, kadar izdelek ali njegove storitve v oblaku obdelujejo osebne podatke. COBIT 2019 obravnava upravljanje dobaviteljev kot vprašanje korporativnega upravljanja tehnologije, ne samo kot vprašanje varnostnih operacij.

Poprodajno spremljanje pretvori dokazila v delovanje

Najzrelejše organizacije za varnost izdelkov razmišljajo dlje od izdaje. Vprašajo se: »Kako bomo vedeli, da je ta izdelek postal tvegan po tem, ko je že na terenu?«

Poprodajno spremljanje mora zajemati signale iz virov ranljivosti, obveščevalnih podatkov o izkoriščanju, podpore strankam, telemetrije, programov bug bounty ali poročil raziskovalcev, obvestil dobaviteljev, dnevnikov v oblaku, zapisov incidentov in podatkov o delovanju na terenu. Vključevati mora tudi periodični pregled tveganja izdelka, kadar se spremenijo okoliščine groženj.

Clarysecova Enterprise Politika beleženja in spremljanja, klavzula 5.4, Spremljanje in pregled varnosti, določa:

“Varnostno relevantni dogodki morajo biti zbrani, pregledani, eskalirani in hranjeni na način, ki podpira pravočasno zaznavanje, preiskovanje, odziv na incidente, poročanje o skladnosti in nenehno izboljševanje.”

Pri povezanih izdelkih je treba to razlagati previdno. Spremljanje mora spoštovati zasebnost, minimizacijo podatkov in pravne omejitve, zlasti kadar telemetrija vključuje osebne podatke ali operativne podatke strank. Preslikava na GDPR je pomembna. Ekipe za varnost izdelkov morajo sodelovati z ekipami za zasebnost, da določijo, katera telemetrija je nujna za varnost, kako se minimizira, kako dolgo se hrani in kako so stranke obveščene.

Dokazila poprodajnega spremljanja morajo vključevati načrt spremljanja varnosti izdelka, vire obveščevalnih podatkov o ranljivostih, kanale za sprejem poročil strank, kanale za obvestila dobaviteljev, obseg pregleda telemetrije ali dnevnikov, zapisnike periodičnih pregledov tveganja izdelka, sledenje prevzemu popravkov, analizo trendov incidentov in vhodne podatke za pregled vodstva.

V Zenith Blueprint se faza 5, korak 30 osredotoča na nenehno izboljševanje in pripravljenost na nadzor. Pri CRA je to točka, kjer dokumentacijska mapa za varnost izdelka postane živa mapa. Vsaka izdaja izdelka, ranljivost, sprememba dobavitelja in signal s terena mora posodobiti dokazilni zapis.

Ena dokazilna mapa, veliko vprašanj skladnosti

Dobro zasnovana dokumentacijska mapa CRA za varnost izdelka zmanjša podvajanje, ker ista dokazila odgovarjajo na več vprašanj skladnosti. Jezik se spreminja, kontrolna resničnost pa je pogosto podobna.

Zenith Controls je zasnovan za takšno ponovno uporabo. Teme kontrol ISO/IEC 27002:2022 preslika na atribute, kot so preventivni, odkrivalni in korektivni namen kontrole, koncepti kibernetske varnosti, operativne zmogljivosti in varnostne lastnosti. Pri CRA to vodji informacijske varnosti pomaga pojasniti, zakaj en sam dokazilni objekt, kot je varnostni pregled izdaje, podpira varen razvoj, obravnavo tveganj, upravljanje sprememb, upravljanje ranljivosti in pripravljenost na revizijo.

Pripravite se na različne presojevalske poglede

Dokumentacijsko mapo CRA za varnost izdelka lahko izpodbijajo presojevalec ISO, skupina za notranjo revizijo, skupina za zagotavljanje zaupanja strank, pregledovalec skladnosti izdelka, regulator, ocenjevalec po NIST ali presojevalec COBIT, usposobljen pri ISACA. Vsak bo podobna vprašanja postavil skozi drugačen pogled.

Ista šibka točka bo izpostavljena različno. Če se SBOM generirajo, vendar ne hranijo, presojevalec ISO vidi težavo pri nadzoru zapisov in operativni kontroli. Ocenjevalec NIST vidi šibkost pri upravljanju sredstev in ranljivosti. Presojevalec COBIT vidi šibko upravljanje informacijskih sredstev. Pregledovalec izdelka vidi nezadostno tehnično dokumentacijo.

30-koračni načrt, prilagojen pripravljenosti na CRA

Zenith Blueprint ekipam za skladnost preprečuje, da bi takoj skočile v zbiranje dokumentov. Za CRA 30-koračni načrt postane program dokazil o varnosti izdelka.

Faza 1 se začne s preslikavo obveznosti in obsega. Identificirajte, kateri izdelki, različice, komponente, storitve v oblaku in podporni procesi so v obsegu. Potrdite predvideno uporabo, kategorije uporabnikov, trge in obdobje varnostne podpore.

Faza 2 vzpostavi arhitekturo dokazil. Določite kazalo dokumentacijske mape za varnost izdelka, lastnike dokazil, zahteve glede hrambe, strukturo repozitorija in odobritveni delovni tok. Uskladite se z razvojnimi sistemi, namesto da zahtevate ročna nalaganja.

Faza 3 uvede operativne kontrole. Varen razvoj, generiranje SBOM, obravnavanje ranljivosti, dokazila dobaviteljev, izdajne kontrolne točke, varne posodobitve in eskalacija incidentov morajo delovati kot dejanski procesi.

Faza 4 testira pripravljenost na revizijo. Izberite izdajo izdelka in izvedite simulirano presojo. Ali lahko ekipa pridobi SBOM? Ali lahko dokaže varnostno testiranje? Ali lahko pokaže, kako je bila ranljivost triažirana? Ali lahko poveže dokazila dobaviteljev s komponentami izdelka?

Faza 5 vgradi nadzor in izboljševanje. Poprodajno spremljanje, analiza trendov ranljivosti, pregledi dobaviteljev in vhodni podatki za pregled vodstva ohranjajo mapo aktualno.

Ta sprint običajno hitro razkrije resnico. Organizacije redko odpovejo zato, ker nimajo nobenih kontrol. Odpovejo zato, ker kontrole niso povezane na ravni izdelka.

Pogoste vrzeli pripravljenosti na CRA pred letom 2026

Pri dobaviteljih programske opreme, proizvajalcih naprav in ponudnikih povezanih storitev se ponavljajoče vrzeli pojavljajo dosledno.

Prvič, obseg ISMS je preveč korporativen. Pokriva organizacijo, vendar ne dovolj podrobno življenjskega cikla izdelka. Rešitev je ustvariti priloge in dokazilne mape na ravni izdelka.

Drugič, SBOM obstajajo, vendar jim ni mogoče zaupati. Orodja jih generirajo, vendar niso pregledani, odobreni, hranjeni ali povezani z odločitvami o ranljivostih. Rešitev je upravljanje SBOM, ne samo izdelava SBOM.

Tretjič, CVD je javno dostopen, vendar operativno ni dovolj zrel. Poročila pridejo, vendar so merila triaže, cilji odziva, odobritve varnostnih obvestil in dokazila o zaprtju nedosledni. Rešitev je integrirati CVD z upravljanjem ranljivosti, upravljanjem incidentov in upravljanjem izdaj.

Četrtič, dokazila dobaviteljev so preplitka. Kritični dobavitelji so komercialno odobreni, vendar niso ocenjeni glede vpliva na varnost izdelka. Rešitev je razvrstitev dobaviteljev glede na tveganje izdelka in obvezna dokazila za kritične komponente.

Petič, poprodajno spremljanje je reaktivno. Ekipe se odzivajo na nujne ranljivosti, vendar ne izvajajo periodičnih pregledov tveganj izdelka. Rešitev je načrtovan poprodajni varnostni pregled, povezan s poročanjem vodstvu.

Šestič, revizijski dokazi so preveč ročni. Ekipe za skladnost lovijo posnetke zaslona. Rešitev so dokazila po zasnovi, pri čemer se razvojni sistemi, delovni tokovi zahtevkov in repozitoriji uporabljajo kot avtoritativni viri.

Vzpostavite dokazilno mapo, preden vam jo vsili rok

Akt o kibernetski odpornosti nagrajuje organizacije, ki lahko dokažejo varnost izdelkov kot operativno disciplino. Tveganje ustvarja za organizacije, ki dokazila obravnavajo kot skladnostno aktivnost v zadnjem trenutku.

Začnite z enim izdelkom. Vzpostavite eno dokumentacijsko mapo za varnost izdelka. Preslikajte jo na ISO/IEC 27001:2022 in ISO/IEC 27002:2022. Priložite dokazila varnega razvoja, SBOM, zapise CVD, zagotovila dobaviteljev in poprodajno spremljanje. Izvedite simulacijo revizije, preden jo za vas izvede nekdo zunanji.

Clarysec vam lahko pomaga pospešiti to pot z Zenith Blueprint, Zenith Controls, Enterprise Politiko varnega razvoja, Politiko upravljanja ranljivosti, Politiko upravljanja sredstev, Politiko varnosti tretjih oseb in dobaviteljev, Politiko beleženja in spremljanja ter Politiko upravljanja incidentov informacijske varnosti.

Najpomembnejše vprašanje za CRA 2026 ni: »Ali imamo varnostne kontrole?«

Temveč: »Ali lahko dokažemo varnost izdelka, izdajo za izdajo, komponento za komponento, ranljivost za ranljivostjo, potem ko je izdelek že na trgu?«

Vzpostavite dokazilno mapo zdaj, povežite jo s svojim ISMS in zagotovite, da bo vsaka prihodnja izdaja izdelka pripravljena na revizijo že po zasnovi.