ES CRA 2026 m. pranešimo apie pažeidžiamumus pasirengimo vadovas

2026 m. rugsėjo pirmadienio rytą, 08:17, Anna, sparčiai augančios Europos SaaS įmonės CISO, vis dar galvoja apie praėjusios savaitės valdybos posėdį. Generalinis direktorius uždavė klausimą, kurį dabar girdi kiekvienas saugumo vadovas: „Jeigu jau pasirengėme NIS2, o mūsų fintech klientai nuolat klausia apie DORA, ką keičia Cyber Resilience Act?“

Tada atsakymas pasiekia jos el. pašto dėžutę.

Nepriklausomas tyrėjas praneša apie nuotoliniu būdu išnaudojamą pažeidžiamumą programinės aparatinės įrangos atnaujinimo komponente, kurį naudoja vienas iš įmonės prijungtųjų produktų. Pranešime pateikiamas koncepcijos įrodymas, priklausomybės pavadinimas ir įspėjimas, kad panašus išnaudojimas jau pastebėtas realioje aplinkoje.

Per kelias minutes skirtingoms funkcijoms reikia skirtingų atsakymų. CTO klausia, ar pažeidžiamumas realus. Teisininkai klausia, ar atsirado pranešimo pareiga pagal ES kibernetinio atsparumo aktą. Produkto komanda klausia, kurioms versijoms tai taikoma. CISO klausia, ar ši priklausomybė yra kuriame nors SBOM. Pardavimų komanda klausia, ar finansų sektoriaus klientams reikės DORA įrodymų. Atitikties vadovas atidaro ISO 27001 rizikų registrą ir randa pažeidžiamumų valdymo procesą, tačiau neranda aiškaus sprendimo kelio dėl pranešimo apie produktą.

Tai ir yra tikroji pasirengimo CRA problema. Dauguma organizacijų nepradeda nuo nulio. Jos jau turi reagavimo į incidentus politikas, pataisų valdymo tvarkas, saugaus kūrimo praktikas, tiekėjų peržiūras, pažeidžiamumų skenerius ir ISO 27001 įrodymus. Tačiau CRA nevertina izoliuotų dokumentų. Jis reikalauja greitos, pagrindžiamos darbo eigos, kuri vienu metu gali atsakyti į penkis klausimus:

1. Ar tai aktyviai išnaudojamas pažeidžiamumas, ar sunkus incidentas, darantis poveikį produkto saugumui?
2. Kokie produktai, versijos, klientai, priklausomybės ir tiekėjai paveikti?
3. Kuriai institucijai, klientui ar sutartiniam gavėjui turi būti pranešta ir kada?
4. Kokie įrodymai patvirtina, kad pirminis vertinimas, rizikos mažinimas ir atskleidimas buvo valdomi kontroliuojamai?
5. Kaip tai suderinta su ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF ir audito lūkesčiais?

Atsakymas nėra atskiras „CRA aplankas“. Atsakymas – integruoti CRA pranešimą apie pažeidžiamumus į ISVS, koordinuoto pažeidžiamumų atskleidimo procesą, SBOM discipliną, tiekėjų valdyseną ir reagavimo į incidentus įrodymų grandinę, kurios jau reikia brandžiai kibernetinio saugumo valdysenai.

Kodėl ES kibernetinio atsparumo aktas keičia pranešimo modelį

ES kibernetinio atsparumo aktas, Regulation (EU) 2024/2847, produkto saugumą perkelia į pagrindinę atitikties darbotvarkę. Jis taikomas ES rinkai pateikiamiems produktams su skaitmeniniais elementais, įskaitant prijungtuosius įrenginius, programinę įrangą, programinę aparatinę įrangą, įterptines sistemas ir įmonėms skirtus programinės įrangos produktus.

CISO, produkto saugumo vadovams ir atitikties komandoms svarbiausias operacinis pokytis prasideda 2026 m. rugsėjo 11 d. CRA Article 14 reikalauja etapinio pranešimo apie aktyviai išnaudojamus pažeidžiamumus ir sunkius incidentus, darančius poveikį produktų su skaitmeniniais elementais saugumui. Praktiniu požiūriu gamintojai turi būti pasirengę:

Tikslų teisinį vertinimą visada turėtų atlikti kvalifikuoti teisininkai, tačiau operacinė pamoka aiški: pirmosios 24–72 valandos bus tokios geros, kokia buvo prieš kelis mėnesius atlikta parengtis.

Jeigu jūsų SBOM neišsamūs, jeigu CVD pašto dėžutė stebima neformaliai, jeigu tiekėjų sutartyse nereikalaujama pranešti apie pažeidžiamumus arba jeigu jūsų Reagavimo į incidentus politika neskiria pranešimo apie produkto pažeidžiamumus nuo privatumo ar veiklos incidentų, teisinis laikrodis judės greičiau nei jūsų įrodymų procesas.

Naudokite ISO/IEC 27001:2022 kaip CRA pasirengimo valdymo sistemą

ISO/IEC 27001:2022 nepakeičia CRA teisinės atitikties, tačiau tai geriausia valdymo sistemos struktūra CRA įpareigojimams integruoti į kasdienę valdyseną.

4.1–4.4 punktai reikalauja, kad organizacija suprastų vidinį ir išorinį kontekstą, suinteresuotąsias šalis, reikalavimus, sąsajas su kitomis organizacijomis ir ISVS taikymo sritį ISO/IEC 27001:2022. CRA pasirengimo kontekste tai reiškia, kad jūsų ISVS taikymo sritis turi identifikuoti produktus su skaitmeniniais elementais, produkto gyvavimo ciklo atsakomybes, priglobtuosius komponentus, kūrimo grandines, atvirojo kodo priklausomybes, tiekėjus, naudotojus, importuotojus, platintojus, reguliuojamus klientus ir atitinkamas institucijas.

6.1.1–6.1.3 punktai reikalauja rizikos vertinimo ir rizikos valdymo, įskaitant rizikos savininkus, pasekmes, tikimybę, rizikos valdymo sprendimus, Taikomumo pareiškimą ir liekamosios rizikos priėmimą. CRA pranešimas tame procese turi būti vertinamas kaip produkto saugumo rizikos scenarijus, o ne kaip skubus teisinio aiškinimo pratimas.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 pateikia praktinę kontrolės priemonių struktūrą. Svarbiausios CRA pranešimo apie pažeidžiamumus kontrolės priemonės yra:

Zenith Controls: kelių atitikties režimų vadove Clarysec susieja ISO/IEC 27002:2022 kontrolę 8.8, Techninių pažeidžiamumų valdymas, kaip prevencinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą. Jos atributai dera su Identify ir Protect kibernetinio saugumo sąvokomis, o grėsmių ir pažeidžiamumų valdymas apibrėžiamas kaip operacinis pajėgumas.

Ši perspektyva svarbi. CRA pranešimas nėra vien pranešimas institucijoms. Tai gebėjimas įrodyti, kad prevencinis pažeidžiamumų valdymo pajėgumas egzistavo dar prieš gaunant pranešimą.

Kurkite veiklos modelį aplink CVD, SBOM ir pranešimo terminų laikrodį

Patikima CRA pažeidžiamumų darbo eiga prasideda dar prieš tyrėjui susisiekiant su jumis. Ji prasideda nuo gebėjimo priimti pranešimus apie pažeidžiamumus, juos patikrinti, identifikuoti paveiktus komponentus, įvertinti išnaudojimą, koordinuoti rizikos mažinimą, komunikuoti su naudotojais ir išsaugoti įrodymus.

Pirmasis elementas – viešai prieinamas pažeidžiamumų pranešimo kanalas. Clarysec Koordinuoto pažeidžiamumų atskleidimo politika, Įgyvendinimo reikalavimų 6.1 punktas, nustato:

Viešieji atskleidimo kanalai: organizacija turi palaikyti aiškų pažeidžiamumų pranešimo kanalą, pavyzdžiui, specialų saugumo kontaktinį el. pašto adresą (pvz., security@company.com) arba žiniatinklio formą. Ši informacija turi būti paskelbta įmonės svetainės saugumo puslapyje kartu su organizacijos PGP viešuoju raktu, kad būtų galima teikti šifruotus pranešimus.

Tai išsprendžia dažną audito nesėkmę. Daug įmonių teigia priimančios pranešimus apie pažeidžiamumus, tačiau pranešimo kelias yra paslėptas, nevaldomas arba nukreiptas per bendrą pagalbos eilę. CRA sąlygomis pranešimo kanalas tampa teisinio sužinojimo, sunkumo vertinimo ir įrodymų fiksavimo pradžios tašku.

Antrasis elementas – pirminis vertinimas. Koordinuoto pažeidžiamumų atskleidimo politika, Įgyvendinimo reikalavimų 6.4 punktas, nustato:

Pirminis vertinimas ir patvirtinimas: gavusi pranešimą, VRT turi jį užregistruoti ir per 2 darbo dienas išsiųsti pranešėjui gavimo patvirtinimą, priskirdama sekimo identifikatorių. VRT turi atlikti preliminarų sunkumo vertinimą, pavyzdžiui, naudodama CVSS balų sistemą, ir patikrinti problemą, prireikus pasitelkdama IT ir kūrimo komandas, per tikslinį 5 darbo dienų terminą. Kritiniai pažeidžiamumai, pavyzdžiui, leidžiantys nuotolinį kodo vykdymą arba sukeliantys reikšmingą duomenų saugumo pažeidimą, turi būti nagrinėjami skubos tvarka.

CRA pasirengimui šis pirminio vertinimo įrašas turi būti papildytas laukais, kurie palaiko teisinį sprendimą dėl pranešimo:

Trečiasis elementas – SBOM disciplina. Clarysec Saugaus kūrimo politika, Valdysenos reikalavimų 5.4 punktas, nustato:

Atvirojo kodo arba trečiųjų šalių kodo naudojimas turi būti patvirtintas, sekamas ir validuotas per: 5.4.1 programinės įrangos sudėties analizę (SCA) 5.4.2 licencijų peržiūrą (GPL, MIT, BSD ir kt.) 5.4.3 žinomų pažeidžiamumų skenavimą (CVE, OSS Index ir kt.)

Mažesnėms organizacijoms Clarysec Taikomųjų programų saugumo reikalavimų politika – MVĮ, Politikos įgyvendinimo reikalavimų 6.4.2 punktas, tą patį lūkestį pateikia praktine forma:

Kūrėjas arba IT paslaugų teikėjas turi palaikyti kiekvieno naudojamo išorinio komponento įrašą, įskaitant:

Šis komponento įrašas tampa minimaliu SBOM grindžiamo reagavimo į pažeidžiamumus įrodymų rinkiniu. Jis turi susieti komponento pavadinimą, versiją, šaltinį, tiekėją arba saugyklą, licenciją, produkto versiją, kūrimo datą ir pažeidžiamumų skenavimo būseną. Kai gaunamas CVE, tyrėjo pranešimas arba tiekėjo pranešimas, jūsų komanda per kelias valandas turi atsakyti: „Kuriuose išleistuose produktuose yra šis komponentas?“

Susiekite CRA, NIS2, DORA ir GDPR į vieną pranešimo sprendimų matricą

Cyber Resilience Act neveiks izoliuotai. Vienas produkto pažeidžiamumas gali inicijuoti CRA pranešimą, NIS2 incidento vertinimą, DORA klientų įrodymų įpareigojimus, GDPR pažeidimo vertinimą ir sutartines pranešimo pareigas.

NIS2 Article 21 reikalauja, kad esminiai ir svarbūs subjektai įgyvendintų tinkamas technines, operacines ir organizacines priemones. Šios priemonės apima rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, kūrimą ir priežiūrą, pažeidžiamumų tvarkymą ir atskleidimą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, personalo saugumą, prieigos kontrolę, turto valdymą, MFA ir saugią komunikaciją.

NIS2 Article 23 nustato etapinio incidentų pranešimo modelį: ankstyvasis įspėjimas per 24 valandas nuo sužinojimo, pranešimas apie incidentą per 72 valandas, tarpiniai atnaujinimai, jei jų prašoma, ir galutinė ataskaita ne vėliau kaip per vieną mėnesį po pranešimo apie incidentą. NIS2 Article 20 taip pat nustato valdymo organo atskaitomybę už kibernetinio saugumo rizikos valdymo priemonių patvirtinimą ir priežiūrą.

DORA taikomas nuo 2025 m. sausio 17 d. ir nustato vieningą ES skaitmeninio operacinio atsparumo sistemą finansų subjektams. SaaS paslaugų teikėjams, programinės įrangos tiekėjams ir IRT tiekėjams DORA dažnai pasireiškia per klientų sutartis. Jūsų finansų sektoriaus klientas gali būti reglamentuojamas DORA subjektas, tačiau jūsų pažeidžiamumų tvarkymas, SBOM įrodymai, incidentų palaikymas, audito teisės ir pranešimo įsipareigojimai gali būti būtini tam klientui vykdant savo pareigas.

GDPR prideda dar vieną šaką. Jeigu pažeidžiamumas ar incidentas lemia atsitiktinį arba neteisėtą asmens duomenų sunaikinimą, praradimą, pakeitimą, neautorizuotą atskleidimą arba prieigą prie jų, reikalingas asmens duomenų saugumo pažeidimo vertinimas. GDPR Article 5 taip pat apima vientisumą, konfidencialumą ir atskaitomybę, todėl organizacija turi gebėti pagrįsti savo sprendimų priėmimą.

Clarysec Reagavimo į incidentus politika, Politikos įgyvendinimo reikalavimų 6.4.1 punktas, jau palaiko šį kelių režimų vertinimą:

Jeigu incidentas lemia patvirtintą arba tikėtiną asmens duomenų ar kitų reglamentuojamų duomenų atskleidimą, Teisės funkcija ir DAP turi įvertinti, ar taikomi: 6.4.1.1 GDPR Article 33 (72 valandų pranešimas priežiūros institucijai) 6.4.1.2 GDPR Article 34 (pranešimas duomenų subjektams, kai taikoma didelė rizika) 6.4.1.3 NIS2 Article 23 (pranešimas per 24 valandas nuo sužinojimo apie incidentą) 6.4.1.4 DORA Article 17 (pranešimas apie sunkius su IRT susijusius incidentus)

CRA pasirengimui šį reagavimo veiksmų planą reikia išplėsti įtraukiant CRA Article 14 pranešimo vertinimą dėl aktyviai išnaudojamų pažeidžiamumų ir sunkių incidentų, darančių poveikį produkto saugumui.

Vieninga sprendimų matrica neleidžia komandoms taikyti atskirų ir tarpusavyje nesuderintų pranešimo planų:

MVĮ Clarysec Reagavimo į incidentus politika – MVĮ, Valdysenos reikalavimų 5.3.2 punktas, tą patį principą pateikia paprastesne forma:

Reagavimo terminai, įskaitant duomenų atkūrimą ir pranešimo įpareigojimus, turi būti dokumentuoti ir suderinti su teisiniais reikalavimais, pavyzdžiui, GDPR 72 valandų asmens duomenų saugumo pažeidimo pranešimo reikalavimu.

CRA pasirengimas tiesiog išplečia šį principą nuo pranešimo apie asmens duomenų saugumo pažeidimą iki pranešimo apie produkto pažeidžiamumus ir produkto saugumo incidentus.

Tiekėjų įrodymai dabar yra produkto saugumo įrodymai

Daug CRA aktualių pažeidžiamumų kils už jūsų kodo bazės ribų. Jie gali atsirasti atvirojo kodo paketuose, programinės aparatinės įrangos moduliuose, SDK, priglobtose taikomųjų programų sąsajose, kūrimo priemonėse, debesijos paslaugose, subtiekėjų komponentuose arba aukštesnės grandies bibliotekose. Dėl to tiekėjų valdysena tampa centrine CRA pasirengimo dalimi.

ISO 27001:2022 8.1 punktas reikalauja, kad organizacijos valdytų išorėje teikiamus procesus, produktus ar paslaugas, reikšmingus ISVS. ISO/IEC 27002:2022 kontrolė 5.21, Informacijos saugumo valdymas IRT tiekimo grandinėje, suteikia kontrolės pagrindą.

Zenith Controls Clarysec susieja kontrolę 5.21 kaip prevencinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą. Jos operacinis pajėgumas yra tiekėjų santykių saugumas, o sritys apima valdyseną, ekosistemą ir apsaugą. Esmė paprasta: tiekėjų kontrolės priemonės nėra pirkimų dokumentacija. Tai ekosistemos apsaugos kontrolės priemonės.

Clarysec Trečiųjų šalių ir tiekėjų saugumo politika – MVĮ, Valdysenos reikalavimų 5.3 punktas, nustato sutartinį pagrindą:

Sutartyse turi būti įtrauktos privalomos nuostatos, apimančios:

Įmonių programoms Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas, Kontrolės priemonių taikymo fazės 23 žingsnis, Organizacinės kontrolės priemonės 5.19–5.37, paaiškina ISO/IEC 27002:2022 kontrolę 5.20, Informacijos saugumo įtraukimas į tiekėjų sutartis:

Pasitikėjimas tiekėjais negali remtis prielaidomis. Jis turi būti įtvirtintas sutartyse.

CRA pasirengimui tiekėjų sutartyse turi būti produkto saugumo nuostatos, palaikančios greitą reagavimą į pažeidžiamumus:

DORA stiprina tą pačią kryptį. Finansų subjektai turi valdyti IRT trečiųjų šalių riziką, palaikyti IRT paslaugų sutarčių registrus, vertinti kritiškumą, atlikti deramą patikrinimą, valdyti koncentracijos riziką, apibrėžti sutartines apsaugos priemones, užtikrinti audito teises ir planuoti pasitraukimą. Jei parduodate programinę įrangą arba IRT paslaugas finansų subjektams, tikėkitės, kad klientai klaus, ar jūsų pranešimo apie pažeidžiamumus ir SBOM procesas gali palaikyti jų DORA incidentų, atsparumo ir trečiųjų šalių įrodymų poreikius.

Clarysec CRA pasirengimo darbo eiga

Clarysec padeda klientams operaciniu lygmeniu įgyvendinti CRA pranešimą ISO 27001:2022 suderintoje ISVS, taikant praktinę darbo eigą.

1. Įtraukite CRA įpareigojimus į ISVS reikalavimų registrą

Pradėkite nuo ISO 27001:2022 4.1–4.4 punktų. Atnaujinkite organizacijos kontekstą, suinteresuotąsias šalis ir taikymo sritį, kad būtų įtraukti produktai su skaitmeniniais elementais, ES rinkos ekspozicija, naudotojai, importuotojai, platintojai, reguliuotojai, CSIRT, tiekėjai ir reguliuojami klientai.

Sukurkite reikalavimų registro įrašus dėl CRA pranešimo apie pažeidžiamumus, CRA pranešimo apie sunkius produkto saugumo incidentus, NIS2 incidentų pranešimo, DORA klientų palaikymo įpareigojimų, GDPR asmens duomenų saugumo pažeidimo vertinimo, sutartinio pranešimo apie incidentus, CVD įsipareigojimų ir komunikacijos su tyrėjais.

Tai auditoriams suteikia atsekamą kelią nuo išorinio įpareigojimo iki vidinės kontrolės priemonės.

2. Sukurkite produkto pažeidžiamumo priėmimo formą

Priėmimo formą grįskite Koordinuoto pažeidžiamumų atskleidimo politika. Ji turi fiksuoti pranešėjo tapatybę, saugius kontaktinius duomenis, produkto versiją, modulį, aplinką, koncepcijos įrodymą, atkūrimo veiksmus, išnaudojimo būseną, galimą duomenų atskleidimą, poveikį paslaugai, SBOM komponento atitiktį, CVSS arba lygiavertį sunkumą, savininką, sekimo identifikatorių ir reglamentavimo kontrolinį tašką.

Forma turi automatiškai sukurti užduotį reagavimo į pažeidžiamumus eilėje. Ji taip pat turi paleisti pranešimo sprendimo laikmatį, net jei galutinis atsakymas yra „nepraneština“.

3. Susiekite SBOM duomenis su leidimais

Kiekvienai išleistai produkto versijai palaikykite SBOM arba lygiavertę komponentų apskaitą. Minimalūs naudingi įrodymai apima komponento pavadinimą, versiją, šaltinį, licenciją, tiekėją arba saugyklą, produkto versiją, kūrimo datą ir pažeidžiamumų skenavimo būseną.

Saugaus kūrimo politika ir Taikomųjų programų saugumo reikalavimų politika – MVĮ suteikia politikos pagrindą SCA, komponentų peržiūrai ir išorinių komponentų įrašams.

4. Išsaugokite įrodymus nuo pirmos dienos

Kiekviena su CRA susijusi pažeidžiamumo užduotis turi saugoti:

• Pradinį pranešimą
• Patvirtinimo laiko žymą
• Pirminio vertinimo pastabas
• CVSS arba lygiaverčio sunkumo pagrindimą
• SBOM atitikties rezultatus
• Išnaudojimo vertinimą
• Žurnalus, indikatorius ir kriminalistines momentines kopijas
• Komunikaciją su tiekėjais
• Rizikos priėmimą, jei rizikos mažinimas vėluoja
• Pataisos planą, išleidimo pastabas ir testavimo įrodymus
• Sprendimus dėl pranešimo klientams ir institucijoms
• Galutinės ataskaitos įvestis ir įgytą patirtį

Tai dera su ISO 27001:2022 8.1 punktu, kuris reikalauja pakankamos dokumentuotos informacijos, pagrindžiančios, kad procesai veikė kaip suplanuota, ir su 8.2 bei 8.3 punktais, kurie reikalauja dokumentuotų rizikos vertinimo ir rizikos valdymo rezultatų.

5. Testuokite pagal realistišką priklausomybės scenarijų

Surenkite stalo pratybas naudodami simuliuotą aktyviai išnaudojamos priklausomybės pažeidžiamumą. Įtraukite inžinerijos, saugumo, teisės, privatumo, produkto, komunikacijos, tiekėjų valdymo ir su klientais dirbančias komandas. Testas turi įrodyti, kad jūsų organizacija gali identifikuoti paveiktas versijas, įvertinti išnaudojimą, priimti pranešimo sprendimą, susisiekti su tiekėjais, parengti naudotojų gaires ir išsaugoti įrodymus.

Kaip auditoriai testuos pasirengimą CRA pranešimui apie pažeidžiamumus

CRA pasirengimo peržiūra retai apsiribos CRA kontroliniu sąrašu. Skirtingi auditoriai tą pačią įrodymų bazę tikrins per skirtingas sistemas.

Zenith Controls Clarysec susieja ISO/IEC 27002:2022 kontrolę 5.24, Informacijos saugumo incidentų valdymo planavimas ir pasirengimas, kaip korekcinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą. Ji dera su Respond ir Recover, o valdysena ir informacijos saugumo įvykių valdymas apibrėžiami kaip operaciniai pajėgumai.

Ši kontrolės priemonė yra tiltas tarp pažeidžiamumo aptikimo ir reglamentavimo pranešimo.

NIST CSF 2.0 ypač naudingas kaip valdybos lygmens komunikacijos sluoksnis. Jo GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER funkcijos padeda paaiškinti, kaip pranešimas apie produkto pažeidžiamumus įsilieja į įmonės kibernetinio saugumo valdyseną, o ne lieka inžinerine išimtimi.

Dažnos CRA pasirengimo spragos, kurias reikia pašalinti iki 2026 m.

Clarysec nuolat mato tas pačias spragas.

Pirmoji – CVD be pranešimo proceso. Įmonė turi saugumo el. pašto adresą arba security.txt failą, bet neturi vidinio kelio nuo tyrėjo pranešimo iki teisinio pranešimo vertinimo.

Antroji – SBOM be savininkystės. Inžinerija gali sugeneruoti SBOM kūrimo metu, bet niekas neatsako už išleistų produktų tikslumą ir negali paaiškinti, kaip SBOM išvados patenka į reagavimą į pažeidžiamumus.

Trečioji – ISO sertifikatas be produkto taikymo srities. ISVS apima įmonės IT ir SaaS operacijas, bet ne įterptinę programinę įrangą, programinę aparatinę įrangą, produkto atnaujinimo infrastruktūrą, kūrimo grandines ar pažeidžiamumų atskleidimą.

Ketvirtoji – tiekėjų sutartys be pažeidžiamumų nuostatų. Pirkimų funkcija reikalauja konfidencialumo ir duomenų apsaugos, bet ne pranešimo apie pažeidžiamumus, komponentų skaidrumo, pagalbos incidento metu, koordinuoto atskleidimo ar audito įrodymų.

Penktoji – reagavimas į incidentus be produkto pažeidžiamumų logikos. Incidentų planas apima išpirkos reikalaujančią programinę įrangą, fišingą ir asmens duomenų saugumo pažeidimus, bet ne aktyviai išnaudojamus produkto pažeidžiamumus, kai klientų sistemos gali patirti riziką dar prieš kompromituojant gamintojo aplinką.

Šeštoji – DORA klientų įrodymai tvarkomi rankiniu būdu. Pardavimų arba klientų sėkmės komanda atsako į finansų sektoriaus klausimynus kiekvienu atveju atskirai, o saugumo komandai trūksta standartinio įrodymų paketo, rodančio pažeidžiamumų tvarkymą, SBOM valdyseną, incidentų palaikymą ir tiekėjų kontrolės priemones.

Kiekvieną spragą galima pašalinti. Kiekviena tampa brangi, jei aptinkama realaus pažeidžiamumo metu.

90 dienų pasirengimo CRA pranešimui apie pažeidžiamumus kontrolinis sąrašas

Per artimiausias 90 dienų sukurkite pagrindžiamą pagrindą:

• Identifikuokite produktus su skaitmeniniais elementais, pateikiamus arba prieinamus ES rinkoje.
• Atnaujinkite ISVS taikymo sritį ir suinteresuotųjų šalių analizę, įtraukdami CRA suinteresuotąsias šalis.
• Įtraukite CRA Article 14 pranešimo vertinimą į teisinių ir reglamentavimo reikalavimų registrą.
• Paskelbkite ir stebėkite saugų pažeidžiamumų pranešimo kanalą.
• Sukurkite Reagavimo į pažeidžiamumus komandą su teisės, produkto, inžinerijos, saugumo ir komunikacijos vaidmenimis.
• Palaikykite SBOM arba komponentų apskaitą išleistoms produkto versijoms.
• Susiekite SCA rezultatus su pažeidžiamumų užduotimis ir produktų leidimais.
• Į pirminio vertinimo formas įtraukite aktyvaus išnaudojimo ir sunkaus produkto incidento kriterijus.
• Sukurkite bendrą CRA, NIS2, DORA, GDPR ir sutarčių pranešimo sprendimų matricą.
• Atnaujinkite tiekėjų sutartis įtraukdami pranešimo apie pažeidžiamumus, SBOM, pagalbos incidento metu ir atskleidimo koordinavimo nuostatas.
• Palaikykite pataisų žurnalus ir taisomųjų veiksmų įrodymus.
• Testuokite darbo eigą su simuliuotu aktyviai išnaudojamos priklausomybės pažeidžiamumu.
• Pateikite rezultatus vadovybei kartu su spragomis, liekamosiomis rizikomis ir taisomųjų veiksmų savininkais.
• Įtraukite įrodymų paketą į vidaus auditą ir vadovybės vertinamąją analizę.

Clarysec Pažeidžiamumų ir pataisų valdymo politika – MVĮ, Politikos įgyvendinimo reikalavimų 6.2.1 punktas, palaiko stebėsenos pagrindą:

IT funkcija turi stebėti pažeidžiamumus naudodama:

Ta pati politika, Valdysenos reikalavimų 5.4.1 punktas, papildo audito pėdsaką:

Pataisų žurnalas turi būti palaikomas ir peržiūrimas auditų bei reagavimo į incidentus veiklos metu

Šis pataisų žurnalas gali tapti vienu svarbiausių artefaktų CRA galutinėje ataskaitoje. Jis įrodo aptikimą, prioritetizavimą, taisomuosius veiksmus, testavimą ir uždarymą.

Padarykite 2026 m. rugsėjį nuobodų

Geriausias CRA pranešimo įvykis yra lengvas ne todėl, kad pažeidžiamumas paprastas. Jis lengvas todėl, kad organizacija jau repetavo darbo eigą.

Iki 2026 m. rugsėjo Clarysec gali padėti paversti pranešimą apie pažeidžiamumus auditui tinkama sistema, susiejant jūsų dabartinę ISO 27001:2022 ISVS, CVD procesą, SBOM pajėgumą, tiekėjų nuostatas ir reagavimo į incidentus veiksmų planus su CRA, NIS2, DORA, GDPR ir NIST CSF lūkesčiais.

Pradėkite nuo tikslinio pasirengimo CRA pranešimui apie pažeidžiamumus vertinimo. Clarysec peržiūrės jūsų politikas, SBOM įrodymus, tiekėjų sutartis, pažeidžiamumų užduotis, reagavimo į incidentus veiksmų planus ir audito pėdsaką. Tada naudosime Zenith Blueprint ir Zenith Controls, kad sukurtume praktinį taisomųjų veiksmų planą, o ne teorinį atitikties segtuvą.

Jeigu jau naudojate Clarysec politikas, pritaikysime jas CRA pranešimui. Jeigu nenaudojate, galime padėti įgyvendinti tinkamą politikų rinkinį, įskaitant Koordinuoto pažeidžiamumų atskleidimo politiką, Saugaus kūrimo politiką, Reagavimo į incidentus politiką, Pažeidžiamumų ir pataisų valdymo politiką – MVĮ, Taikomųjų programų saugumo reikalavimų politiką – MVĮ ir Trečiųjų šalių ir tiekėjų saugumo politiką – MVĮ, kai tai tinkama.

2026 m. rugsėjis pakankamai arti, kad reikėtų planuoti, ir pakankamai toli, kad būtų galima pasirengti disciplinuotai. Organizacijos, kurios veiks dabar, per pirmąsias 24 valandas neklaus: „Kas atsakingas už šį pažeidžiamumą?“ Jos jau turės atsakymą, įrodymus ir pranešimo kelią.

Susisiekite su Clarysec ir suplanuokite pasirengimo CRA pranešimui apie pažeidžiamumus vertinimą, kad reglamentavimo sudėtingumą paverstumėte pagrindžiamu produkto saugumo pranašumu.