CRA 2026 produkto saugumo byla pagal ISO 27001

Prijungtųjų įrenginių gamintojas penktadienio popietės susitikimui pasikviečia savo CISO Mariją. Pardavimo komanda ką tik sudarė platinimo Europoje susitarimą. Teisės skyrius klausia, ar įmonė gali pagrįsti Cyber Resilience Act atitiktį. Inžinerijos komanda teigia, kad saugus kūrimas „iš esmės padengtas“, nes vykdomos kodo peržiūros, SAST ir pataisų diegimas. Pirkimų komanda sako, kad tiekėjai yra „pagal NDA“. Produktų komandos programinės aparatinės įrangos priklausomybes laiko viename įrankyje, debesijos taikomųjų programų sąsajų apskaitą – kitame, o pažeidžiamumų užduotis – Jira. Atitikties komanda turi ISO/IEC 27001:2022 sertifikavimo įrodymus, tačiau jie sutvarkyti pagal organizacijos ISVS, o ne pagal kiekvieną į ES rinką pateikiamą produktą.

Tada nuskamba nepatogus klausimas: „Jei ES institucija, klientas, notifikuotoji įstaiga ar didelis platintojas 2026 m. paprašys produkto saugumo bylos, ar galėsime ją pateikti per vieną savaitę?“

Daugeliui programinės įrangos tiekėjų, išmaniųjų įrenginių gamintojų ir prijungtųjų paslaugų teikėjų sąžiningas atsakymas yra ne. Ne todėl, kad jie neturi saugumo kontrolės priemonių, o todėl, kad produkto saugumo įrodymai yra išskaidyti. Saugaus kūrimo įrašai lieka pas inžinerijos komandą. SBOM generuojami kiekvienam rinkiniui, bet nėra valdomi. Koordinuotas pažeidžiamumų atskleidimas egzistuoja kaip interneto puslapis, tačiau ne visada susietas su pirminiu įvertinimu, pataisomis, saugumo pranešimais ir stebėsena po pateikimo rinkai. Tiekėjų saugumas paslėptas pirkimų sutartyse. Pranešimas apie incidentus priklauso saugumo operacijoms, o atitikties dokumentacija – produktų atitikties funkcijai.

ES Cyber Resilience Act keičia veiklos modelį. Produktų kibernetinis saugumas nebėra tik geroji praktika ar sutartinis pažadas. Jis tampa gyvavimo ciklo įrodymų prievole. Organizacijos turi gebėti parodyti, kaip kibernetinio saugumo reikalavimai įtraukiami į projektavimą, kūrimą, išleidimą, pažeidžiamumų tvarkymą, atnaujinimus ir stebėseną produktui patekus į rinką.

Čia ISO/IEC 27001:2022 tampa ypač vertingas, jei naudojamas teisingai. Tai nėra savarankiška produkto sertifikavimo schema, tačiau jo ISVS, rizikos, turto, tiekėjų, saugaus kūrimo, pažeidžiamumų ir incidentų kontrolės priemonės gali sudaryti CRA produkto saugumo bylos pagrindą. Tikslas nėra sukurti dar vieną atitikties silosą. Tikslas – esamą ISVS paversti produkto lygmens įrodymų sistema.

Kaip Clarysec Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plane nurodoma 2 fazės 8 žingsnyje „Įrodymų architektūra“:

„Įrodymai neturi būti renkami audito ciklo pabaigoje. Jie turi būti įprojektuoti į kontrolės priemonę, priskirti savininkui, proceso metu pažymėti laiko žyma ir pakartotinai naudojami pagal kiekvieną prievolę, kuri tą patį klausimą užduoda skirtinga kalba.“

Šis sakinys tiksliai nusako pasirengimo CRA esmę. Klausimas nėra vien „Ar turime saugų kūrimą?“ Klausimas yra: „Ar galime įrodyti saugų kūrimą, komponentų žinomumą, pažeidžiamumų tvarkymą ir stebėseną po pateikimo rinkai šiam produktui, šiai versijai, šiam išleidimui ir šiai rinkai?“

CRA produkto saugumo byla yra gyva įrodymų sistema

CRA produkto saugumo byla neturėtų būti laikoma statiniu PDF dokumentu, vieną kartą parengtu prieš išleidimą ir pamirštu. Tai turi būti struktūruota byla, parodanti produkto saugumo istoriją nuo koncepcijos iki palaikymo pabaigos.

Naudinga byla paaiškina:

1. Kas yra produktas ir kaip jis numatytas naudoti.
2. Kokią programinę įrangą, programinę aparatinę įrangą, debesijos paslaugas ir trečiųjų šalių priklausomybes jis apima.
3. Kokios kibernetinio saugumo rizikos buvo įvertintos.
4. Kokie saugumo reikalavimai buvo taikyti.
5. Kaip buvo vykdomas saugus kūrimas.
6. Kaip pažeidžiamumai gaunami, pirminiai įvertinami, pašalinami ir atskleidžiami.
7. Kaip teikiami saugūs atnaujinimai.
8. Kaip kontroliuojami tiekėjai ir atvirojo kodo komponentai.
9. Kaip eskaluojami incidentai ir aktyviai išnaudojami pažeidžiamumai.
10. Kaip produktas stebimas po pateikimo rinkai.

CISO tai yra ISVS įrodymų iššūkis. Produktų atitikties vadovui tai yra techninė dokumentacija. Inžinerijos komandai tai yra DevSecOps ir išleidimų valdysena. Vykdomiesiems vadovams tai yra patekimas į rinką ir atsakomybės kontrolė.

Klaida – šiuos dalykus traktuoti kaip atskiras darbo kryptis. Geresnis modelis yra sukurti produkto lygmens įrodymų bylą, susietą su ISO/IEC 27001:2022 ir ISO/IEC 27002:2022 kontrolės priemonėmis, o tuos pačius įrodymus, kai aktualu, papildomai susieti su NIS2, DORA, GDPR, NIST ir COBIT 2019.

Clarysec Zenith Controls: kryžminės atitikties vadove tai apibūdinama kaip grandinė nuo kontrolės priemonės iki įrodymo ir auditoriaus:

„Kryžminės atitikties įrodymų byla turi susieti kiekvieną prievolę su veikiančia kontrolės priemone, pasikartojančiu įrodymų objektu, atskaitingu savininku ir audito perspektyva, pagal kurią ji bus tikrinama.“

Būtent tokios disciplinos reikia pasirengimui CRA. Produkto saugumo byla nėra vien aplankas. Tai vertimo sluoksnis tarp produkto inžinerijos, saugumo valdysenos, atitikties vertinimo ir klientų patikinimo.

Pirmiausia sukurkite produkto įrodymų pagrindą

Bylai reikia nuoseklios struktūros dar prieš komandoms pradedant kelti įrašus. Be aiškaus pagrindo įrodymai virsta ekrano kopijų, eksportų ir politikų PDF dokumentų rinkiniu, kurio joks auditorius negali nuosekliai patikrinti.

CRA pasirengimo dirbtuvėse Clarysec organizacijoms, kurios jau taiko ISO/IEC 27001:2022 ISVS, paprastai rekomenduoja tokią produkto saugumo bylos struktūrą.

Ši lentelė nepakeičia teisinių techninės dokumentacijos prievolių. Ji suteikia organizacijai veiklos modelį toms prievolėms pagrįsti.

Zenith Blueprint 1 fazės 3 žingsnis skirtas taikymo srities ir ribų apibrėžimui. CRA atveju šis žingsnis tampa specifinis produktui. Apibrėžkite produktų šeimą, programinės įrangos versijas, diegimo prielaidas, naudotojų vaidmenis, prijungtąsias paslaugas, atnaujinimo kanalus ir palaikymo laikotarpį. Jei ISVS taikymo sritis yra „Įmonės SaaS ir įrenginių valdymo platforma“, CRA byla vis tiek turi atsakyti į siauresnį klausimą: „Kuris skaitmeninių elementų turintis produktas pateikiamas ES rinkai ir kas į jį įtraukta?“

Susiekite saugų kūrimą su produkto lygmens įrašais

Produkto saugumo bylos esmė yra saugumo pagal projektavimą įrodymai. ISO/IEC 27001:2022 suteikia valdysenos sistemą. ISO/IEC 27002:2022 pateikia įgyvendinimo gaires per tokias kontrolės priemones kaip A.8.25 Saugaus kūrimo gyvavimo ciklas, A.8.27 Saugių sistemų architektūra ir inžinerijos principai, A.8.28 Saugus programavimas ir A.8.29 Saugumo testavimas kūrimo ir priėmimo metu.

Svarbus pokytis yra perėjimas nuo bendrų teiginių apie saugų kūrimą prie konkrečiam išleidimui skirtų įrašų. „Atliekame kodo peržiūrą“ nepakanka. Byla turi parodyti, kuris išleidimas buvo peržiūrėtas, kokios rizikos įvertintos, kurie saugumo testai sėkmingai atlikti, kurie pažeidžiamumai buvo priimti arba pašalinti ir kas patvirtino išleidimą.

Clarysec Enterprise Saugaus kūrimo politika sukurta taip, kad įtvirtintų šį įrodymų pėdsaką. 6.1 punkte „Saugaus kūrimo gyvavimo ciklo reikalavimai“ nurodyta:

„Kiekvienam produkto ar paslaugos išleidimui prieš diegimą į produkcinę aplinką turi būti saugomi dokumentuoti saugumo reikalavimų, projektavimo peržiūros, saugaus programavimo veiklų, saugumo testavimo, sprendimų dėl pažeidžiamumų šalinimo ir išleidimo patvirtinimo įrodymai.“

Šis punktas naudingas CRA, nes saugų kūrimą paverčia pakartojamu įrodymų modeliu. Auditoriui nereikia daryti prielaidos, kad saugus kūrimas įvyko. Jis gali patikrinti išleidimo įrašą.

Išmaniojo termostato, medicininio IoT įrenginio, pramoninio jutiklio ar su SaaS susieto produkto saugaus kūrimo įrodymai turėtų apimti:

• Produkto saugumo reikalavimus, susietus su identifikuotomis rizikomis.
• Produkto ir prijungtųjų paslaugų grėsmių modelį arba piktnaudžiavimo atvejų analizę.
• Architektūros peržiūrą, įskaitant pasitikėjimo ribas ir išorines sąsajas.
• Saugaus programavimo standartą ir kūrėjų patvirtinimo arba mokymų įrodymą.
• SAST, DAST, programinės įrangos sudėties analizę, paslapčių skenavimą ir programinės aparatinės įrangos analizę, kai taikoma.
• Didelės rizikos išvadų šalinimo užduotis.
• Rizikos priėmimo įrašus su verslo ir saugumo patvirtinimu.
• Išleidimo vartų kontrolinį sąrašą, rodantį, kad saugumo kriterijai įvykdyti.
• Kriptografinio pasirašymo ir atnaujinimo vientisumo įrodymus.
• Palaikymo laikotarpio ir eksploatavimo pabaigos prielaidas.

Metodiką sustiprina ir kiti standartai. ISO/IEC 27005 palaiko rizikos metodą, kuriuo grindžiami šie įrašai. ISO/IEC 27017 naudingas tais atvejais, kai debesijos paslaugos sudaro produkto ekosistemos dalį. ISO/IEC 27035 palaiko incidentų valdymą. ISO/IEC 29147 ir ISO/IEC 30111 ypač aktualūs pažeidžiamumų atskleidimui ir pažeidžiamumų tvarkymui. ISO/IEC 27036 palaiko tiekėjų saugumą, kuris svarbus, kai produktas apima išorės sukurtą programinę įrangą, įterptinius modulius, valdomas debesijos paslaugas ar trečiųjų šalių bibliotekas.

Zenith Controls CRA saugaus kūrimo įrodymai paprastai siejami su ISO/IEC 27002:2022 kontrolės temomis, tokiomis kaip informacijos saugumas projektų valdyme, saugaus kūrimo gyvavimo ciklas, saugus programavimas, saugumo testavimas, pakeitimų valdymas ir techninių pažeidžiamumų valdymas. Vadovas taip pat susieja jas su turto apskaita ir tiekėjų kontrolės priemonėmis, nes joks saugaus kūrimo procesas nėra užbaigtas, jei organizacija negali identifikuoti komponentų, kuriuos pateikia rinkai.

SBOM traktuokite kaip reglamentuojamo produkto įrodymą

Software Bill of Materials dažnai traktuojamas kaip techninis artefaktas. Pasirengimui CRA jis turi būti laikomas produkto įrodymu.

Naudingas SBOM parodo, kokie komponentai yra produkte, kokios versijos naudojamos, iš kur jie gauti, kokios licencijos taikomos, kokie pažeidžiamumai juos veikia ir kuriuose išleidimuose jie yra. Programinės aparatinės įrangos ir įterptinių produktų atveju tai gali apimti operacinės sistemos paketus, įkroviklius, bibliotekas, tvarkykles, konteinerius, trečiųjų šalių modulius ir debesijos pusės priklausomybes, reikalingas produkto veikimui.

Problema ta, kad daug organizacijų SBOM generuoja, bet jų nevaldo. Kūrimo konvejeris gali sukurti SPDX ar CycloneDX failą, tačiau niekas nevaliduoja jo išsamumo. Saugumo priemonės gali pažymėti pažeidžiamumus, bet rezultatai nesusiejami su produkto versijomis. Pirkimai gali patvirtinti tiekėją, tačiau to tiekėjo komponentų sąrašas nesuderinamas su išleistu produktu.

Clarysec Enterprise Turto valdymo politika šią valdysenos spragą aptaria 5.2 punkte „Informacijos ir susijusio turto apskaita“:

„Informacijos ištekliai ir susiję technologijų komponentai turi būti identifikuoti, jiems turi būti priskirtas savininkas, jie turi būti klasifikuojami, kai taikoma, ir palaikomi apskaitoje, kuri padeda vykdyti rizikos vertinimą, pažeidžiamumų valdymą, pakeitimų kontrolę ir audito įrodymus.“

CRA atveju šis punktas tampa specifinis produktui. SBOM yra susijusių technologijų komponentų apskaitos dalis. Jam reikia savininko, saugojimo taisyklės, validavimo proceso ir sąsajos su pažeidžiamumų valdymu.

Praktinė SBOM įrodymų taisyklė paprasta: kiekviena išleista produkto versija turi turėti patvirtintą komponentų apskaitą, kurią galima susieti su išleidimo artefaktu. Jei organizacija negali susieti SBOM su tiksliu programinės aparatinės įrangos atvaizdu, taikomosios programos paketu, konteinerio santrauka ar SaaS išleidimu, SBOM yra silpnas įrodymas.

Jei nepavyksta daugiau kaip dvi eilutės, problema paprastai nėra SBOM įrankis. Tai valdysenos problema. Produkto saugumo byloje turi būti užregistruotas korekcinis veiksmas ISVS, nes CRA įrodymų silpnumas kartu yra ISO/IEC 27001:2022 kontrolės veiksmingumo problema.

Susiekite CVD su pažeidžiamumų tvarkymu ir išleidimų valdysena

Koordinuotas pažeidžiamumų atskleidimas yra viena matomiausių pasirengimo CRA sričių, nes išoriniai tyrėjai, klientai ir institucijos gali ją tiesiogiai išbandyti. Pažeidžiamumų atskleidimo puslapio ar security.txt failo paskelbimas naudingas, bet tai tik įėjimo taškas. Produkto saugumo byla turi įrodyti, kad vidiniai procesai veikia.

Pagrįstas CVD ir pažeidžiamumų tvarkymo įrodymų rinkinys turėtų apimti:

• Viešą atskleidimo kanalą ir pateikimo instrukcijas.
• Tyrėjo pranešimo patvirtinimo procesą.
• Pirminio įvertinimo kriterijus, įskaitant sunkumo ir išnaudojamumo vertinimą.
• Produkto poveikio analizę.
• Šalinimo atsakomybę ir tikslinius terminus.
• Klientų saugumo pranešimų ir atnaujinimų komunikacijos šablonus.
• Saugaus pataisų kūrimo ir testavimo įrodymus.
• Koordinuoto paskelbimo įrašus, kai taikoma.
• Įgytą patirtį ir pasikartojančių pažeidžiamumų tendencijų analizę.

Clarysec Enterprise Pažeidžiamumų valdymo politika 6.3 punkte „Pažeidžiamumų gavimas, pirminis įvertinimas ir šalinimas“ nurodyta:

„Apie praneštus pažeidžiamumus turi būti registruojama žurnale, jie turi būti įvertinti pagal paveiktus turtus ir produktus, prioritetizuojami pagal riziką ir išnaudojamumą, priskiriami atskaitingam savininkui ir sekami per taisymą, patikrinimą, komunikaciją ir uždarymą.“

Šis punktas susieja CVD su SBOM, turto apskaita, inžinerijos užduotimis, išleidimų valdymu ir stebėsena po pateikimo rinkai. Tai taip pat punktas, kurį auditoriai natūraliai tikrins: parodykite gavimo įrašą, parodykite paveiktus produktus, parodykite pirminį įvertinimą, parodykite pataisą, parodykite komunikaciją klientams, parodykite uždarymą.

Esama Informacijos saugumo incidentų valdymo politika taip pat turėtų būti išplėsta, kad apimtų produkto pažeidžiamumus, kurie tampa incidentais arba reikalauja išorinio pranešimo. ISO/IEC 27002:2022 A.5.24 apima incidentų valdymo planavimą ir pasirengimą, A.5.25 – informacijos saugumo įvykių vertinimą ir sprendimų priėmimą, A.5.26 – reagavimą į informacijos saugumo incidentus, o A.5.27 – mokymąsi iš incidentų.

Zenith Controls pažeidžiamumų valdymą traktuoja ir kaip prevencinę, ir kaip korekcinę veiklą. Prevencinė pusė apima apskaitą, saugų kūrimą, tiekėjų stebėseną ir saugų konfigūravimą. Korekcinė pusė apima aptikimą, pirminį įvertinimą, pataisų diegimą, komunikaciją ir incidentų eskalavimą. Šis skirtumas svarbus, nes pažeidžiamumų tvarkymas po pateikimo rinkai yra produkto gyvavimo ciklo prievolės dalis, o ne papildoma veikla po fakto.

Tiekėjų įrodymai yra paslėptas silpnumas

Produkto saugumo byla dažnai bus griežčiausiai tikrinama ten, kur gamintojas remiasi kitais. Tai apima įterptinius modulius, išorės programinės aparatinės įrangos kūrimą, „white-label“ komponentus, debesijos prieglobą, mobiliuosius SDK, mokėjimo paslaugas, kriptografines bibliotekas ir valdomų palaikymo paslaugų teikėjus.

Dažnas nesėkmės modelis – sutartinis abstraktumas. Gamintojas sako: „Už tai atsakingas mūsų tiekėjas.“ Vertinant produkto saugumą to nepakanka. Organizacija turi parodyti, kad tiekėjų rizika identifikuojama, saugumo reikalavimai perduodami, įrodymai renkami, pažeidžiamumai koordinuojami ir pakeitimai kontroliuojami.

Clarysec Enterprise Trečiųjų šalių ir tiekėjų saugumo politika 7.1 punkte „Tiekėjų saugumo reikalavimai“ nurodyta:

„Tiekėjai, kurie kuria, eksploatuoja, tvarko, palaiko arba reikšmingai veikia informacines sistemas, produktus ar paslaugas, turi būti vertinami pagal riziką ir jiems turi būti taikomi saugumo reikalavimai, apimantys prieigą, pažeidžiamumų valdymą, pranešimą apie incidentus, subtiekimą, veiklos tęstinumą ir įrodymų teikimą.“

CRA atveju frazė „reikšmingai veikia produktus“ yra kritinė. Jei tiekėjo komponentas gali įvesti pažeidžiamumą, sutrikdyti atnaujinimus, atskleisti klientų duomenis arba kompromituoti įrenginio vientisumą, jis turi būti produkto saugumo byloje.

Ta pati politika gali palaikyti ir SBOM sutartines nuostatas. 7.3 punkte nurodyta:

„Dėl visų trečiųjų šalių programinės įrangos komponentų, bibliotekų ar operacinių sistemų, integruojamų į įmonės „skaitmeninių elementų turinčius produktus“, tiekėjas, gavęs prašymą, turi pateikti mašininiu būdu nuskaitomą Software Bill of Materials (SBOM) standartiniu formatu, pavyzdžiui, SPDX arba CycloneDX. Šis reikalavimas turi būti įtrauktas į visas pirkimų ir tiekėjų sutartis.“

Stiprus tiekėjų įrodymų paketas turėtų apimti tiekėjų klasifikavimą pagal poveikį produktui, sutartyse įtvirtintus saugumo reikalavimus, tiekėjo saugaus kūrimo įrodymus kritiniams komponentams, tiekėjo įsipareigojimus dėl pažeidžiamumų atskleidimo, SBOM arba komponentų deklaracijas, kai įmanoma, pataisų palaikymo ir eksploatavimo pabaigos terminus, periodinės peržiūros įrašus ir eskalavimo kelius dėl tiekėjo kilmės pažeidžiamumų.

ISO/IEC 27002:2022 A.5.19, A.5.20 ir A.5.21 pateikia pagrindines tiekėjų kontrolės temas. ISO/IEC 27036 suteikia daugiau gylio tiekėjų santykių saugumui. Kryžminės atitikties požiūriu NIS2 pabrėžia tiekimo grandinę ir pažeidžiamumų tvarkymą. DORA pabrėžia IRT trečiųjų šalių riziką finansų subjektams. GDPR tampa aktualus, kai produktas arba jo debesijos paslaugos tvarko asmens duomenis. COBIT 2019 tiekėjų valdyseną apibrėžia kaip įmonės technologijų valdysenos klausimą, o ne vien saugumo operacijų klausimą.

Stebėsena po pateikimo rinkai įrodymus paverčia operacijomis

Brandžiausios produktų saugumo organizacijos galvoja plačiau nei išleidimas. Jos klausia: „Kaip sužinosime, kad šis produktas tapo rizikingas po to, kai jis jau naudojamas?“

Stebėsena po pateikimo rinkai turėtų apimti signalus iš pažeidžiamumų srautų, išnaudojimo žvalgybos, klientų palaikymo, telemetrijos, klaidų atlygio programų ar tyrėjų pranešimų, tiekėjų pranešimų, debesijos žurnalų, incidentų įrašų ir lauko veikimo duomenų. Ji taip pat turėtų apimti periodinę produkto rizikos peržiūrą, kai keičiasi grėsmių sąlygos.

Clarysec Enterprise Žurnalų tvarkymo ir stebėsenos politika 5.4 punkte „Saugumo stebėsena ir peržiūra“ nurodyta:

„Saugumui svarbūs įvykiai turi būti renkami, peržiūrimi, eskaluojami ir saugomi taip, kad būtų palaikomas savalaikis aptikimas, tyrimas, reagavimas į incidentus, atitikties ataskaitų teikimas ir nuolatinis tobulinimas.“

Prijungtųjų produktų atveju tai turi būti aiškinama atsargiai. Stebėsena turi atitikti privatumo, duomenų minimizavimo ir teisinių apribojimų reikalavimus, ypač kai telemetrija apima asmens duomenis arba klientų operacinius duomenis. GDPR susiejimas yra svarbus. Produkto saugumo komandos turėtų dirbti su privatumo komandomis, kad apibrėžtų, kokia telemetrija būtina saugumui, kaip ji minimizuojama, kiek laiko saugoma ir kaip apie tai informuojami klientai.

Stebėsenos po pateikimo rinkai įrodymai turėtų apimti produkto saugumo stebėsenos planą, pažeidžiamumų žvalgybos šaltinius, klientų pranešimų gavimo kanalus, tiekėjų pranešimų kanalus, telemetrijos arba žurnalų peržiūros taikymo sritį, periodinės produkto rizikos peržiūros protokolus, pataisų įdiegimo sekimą, incidentų tendencijų analizę ir vadovybės peržiūros įvestis.

Zenith Blueprint 5 fazės 30 žingsnis skirtas nuolatiniam tobulinimui ir pasirengimui priežiūrai. CRA atveju čia produkto saugumo byla tampa gyva byla. Kiekvienas produkto išleidimas, pažeidžiamumas, tiekėjo pakeitimas ir lauko signalas turi atnaujinti įrodymų įrašą.

Viena įrodymų byla, daug atitikties klausimų

Gerai suprojektuota CRA produkto saugumo byla sumažina dubliavimą, nes tie patys įrodymai atsako į kelis atitikties klausimus. Kalba keičiasi, bet kontrolės realybė dažnai yra panaši.

Zenith Controls sukurtas šiam pakartotiniam naudojimui. Jis susieja ISO/IEC 27002:2022 kontrolės temas su tokiais požymiais kaip prevencinė, nustatomoji ir korekcinė kontrolės paskirtis, kibernetinio saugumo sąvokos, operacinės galimybės ir saugumo savybės. CRA atveju tai padeda CISO paaiškinti, kodėl vienas įrodymų objektas, pavyzdžiui, išleidimo saugumo peržiūra, palaiko saugų kūrimą, rizikos tvarkymą, pakeitimų kontrolę, pažeidžiamumų valdymą ir pasirengimą auditui.

Pasirenkite skirtingoms auditoriaus perspektyvoms

CRA produkto saugumo bylą gali tikrinti ISO auditorius, vidaus audito komanda, klientų patikinimo komanda, produkto atitikties vertintojas, reguliuotojas, NIST pagrindu vertinantis specialistas arba ISACA parengtas COBIT auditorius. Kiekvienas panašius klausimus užduos per skirtingą perspektyvą.

Tas pats silpnas taškas bus atskleistas skirtingai. Jei SBOM generuojami, bet nesaugomi, ISO auditorius mato įrašų kontrolės ir operacinės kontrolės problemą. NIST vertintojas mato turto ir pažeidžiamumų valdymo silpnumą. COBIT auditorius mato silpną informacijos išteklių valdyseną. Produkto vertintojas mato nepakankamą techninę dokumentaciją.

30 žingsnių veiksmų planas, pritaikytas pasirengimui CRA

Zenith Blueprint neleidžia atitikties komandoms iš karto šokti prie dokumentų rinkimo. CRA atveju 30 žingsnių veiksmų planas tampa produkto saugumo įrodymų programa.

1 fazė prasideda prievolių ir taikymo srities susiejimu. Nustatykite, kurie produktai, versijos, komponentai, debesijos paslaugos ir palaikymo procesai patenka į taikymo sritį. Patvirtinkite numatytą naudojimą, naudotojų kategorijas, rinkas ir saugumo palaikymo laikotarpį.

2 fazė sukuria įrodymų architektūrą. Apibrėžkite produkto saugumo bylos rodyklę, įrodymų savininkus, saugojimo reikalavimus, saugyklos struktūrą ir tvirtinimo darbo eigą. Suderinkite tai su inžinerijos sistemomis, užuot vertę komandas įkelti failus rankiniu būdu.

3 fazė įgyvendina veikiančias kontrolės priemones. Saugus kūrimas, SBOM generavimas, pažeidžiamumų tvarkymas, tiekėjų įrodymai, išleidimo vartai, saugūs atnaujinimai ir incidentų eskalavimas turi veikti kaip realūs procesai.

4 fazė tikrina pasirengimą auditui. Pasirinkite produkto išleidimą ir atlikite bandomąjį auditą. Ar komanda gali gauti SBOM? Ar gali įrodyti saugumo testavimą? Ar gali parodyti, kaip pažeidžiamumas buvo pirminiai įvertintas? Ar gali susieti tiekėjų įrodymus su produkto komponentais?

5 fazė įtvirtina priežiūrą ir tobulinimą. Stebėsena po pateikimo rinkai, pažeidžiamumų tendencijų analizė, tiekėjų peržiūros ir vadovybės peržiūros įvestys palaiko bylos aktualumą.

Šis sprintas paprastai greitai parodo tikrąją padėtį. Organizacijos retai nesėkmę patiria todėl, kad neturi jokių kontrolės priemonių. Jos patiria nesėkmę todėl, kad kontrolės priemonės nesujungtos produkto lygmeniu.

Dažnos pasirengimo CRA spragos iki 2026 m.

Programinės įrangos tiekėjų, įrenginių gamintojų ir prijungtųjų paslaugų teikėjų pasikartojančios spragos yra nuoseklios.

Pirma, ISVS taikymo sritis pernelyg organizacinė. Ji apima organizaciją, bet nepakankamai detalizuoja produkto gyvavimo ciklą. Sprendimas – sukurti produkto lygmens priedus ir įrodymų bylas.

Antra, SBOM egzistuoja, bet jais nepasitikima. Jie generuojami įrankiais, bet nėra peržiūrimi, patvirtinami, saugomi ar susiejami su sprendimais dėl pažeidžiamumų. Sprendimas – SBOM valdysena, o ne tik SBOM gamyba.

Trečia, CVD yra viešai matomas, bet operaciniu požiūriu nebrandus. Pranešimai gaunami, tačiau pirminio įvertinimo kriterijai, reagavimo tikslai, saugumo pranešimų patvirtinimai ir uždarymo įrodymai yra nenuoseklūs. Sprendimas – integruoti CVD su pažeidžiamumų valdymu, incidentų valdymu ir išleidimų valdymu.

Ketvirta, tiekėjų įrodymai per seklūs. Kritiniai tiekėjai patvirtinami komerciškai, bet nevertinami pagal poveikį produkto saugumui. Sprendimas – tiekėjų klasifikavimas pagal produkto riziką ir privalomi įrodymai kritiniams komponentams.

Penkta, stebėsena po pateikimo rinkai yra reaktyvi. Komandos reaguoja į skubius pažeidžiamumus, bet nevykdo periodinių produkto rizikos peržiūrų. Sprendimas – suplanuota produkto saugumo peržiūra po pateikimo rinkai, susieta su vadovybės ataskaitomis.

Šešta, audito įrodymai renkami pernelyg rankiniu būdu. Atitikties komandos vaikosi ekrano kopijų. Sprendimas – įrodymai pagal projektavimą, naudojant inžinerijos sistemas, užduočių darbo eigas ir saugyklas kaip patikimus šaltinius.

Sukurkite įrodymų bylą anksčiau, nei terminas ją sukurs už jus

Cyber Resilience Act palankus organizacijoms, kurios gali įrodyti produkto saugumą kaip veikiančią discipliną. Jis kelia riziką organizacijoms, kurios įrodymus traktuoja kaip paskutinės minutės atitikties pratimą.

Pradėkite nuo vieno produkto. Sukurkite vieną produkto saugumo bylą. Susiekite ją su ISO/IEC 27001:2022 ir ISO/IEC 27002:2022. Pridėkite saugaus kūrimo įrodymus, SBOM, CVD įrašus, tiekėjų patikinimą ir stebėseną po pateikimo rinkai. Atlikite audito simuliaciją prieš tai padarant išorės šaliai.

Clarysec gali padėti pagreitinti šią kelionę su Zenith Blueprint, Zenith Controls, Enterprise Saugaus kūrimo politika, Pažeidžiamumų valdymo politika, Turto valdymo politika, Trečiųjų šalių ir tiekėjų saugumo politika, Žurnalų tvarkymo ir stebėsenos politika ir Informacijos saugumo incidentų valdymo politika.

Svarbiausias jūsų CRA 2026 klausimas nėra: „Ar turime saugumo kontrolės priemones?“

Jis yra: „Ar galime įrodyti produkto saugumą – išleidimas po išleidimo, komponentas po komponento, pažeidžiamumas po pažeidžiamumo – kai produktas jau yra rinkoje?“

Sukurkite įrodymų bylą dabar, susiekite ją su savo ISVS ir užtikrinkite, kad kiekvienas būsimas produkto išleidimas būtų parengtas auditui pagal projektavimą.