Ръководство за готовност за докладване на уязвимости по Регламента на ЕС за киберустойчивост 2026

08:17 е в понеделник сутрин през септември 2026 г. Анна, главен директор по информационна сигурност на бързо растяща европейска SaaS компания, все още мисли за заседанието на управителния съвет от предходната седмица. Главният изпълнителен директор беше задал въпроса, който всеки ръководител по сигурността вече чува: „Ако вече сме се подготвили за NIS2, а нашите финтех клиенти продължават да питат за DORA, какво променя Регламентът за киберустойчивост?“

После отговорът пристига във входящата ѝ поща.

Независим изследовател докладва отдалечено експлоатируема уязвимост в компонент за актуализация на фърмуер, използван от един от свързаните продукти на компанията. Съобщението включва PoC експлойт, име на зависимост и предупреждение, че подобна експлоатация е наблюдавана в реална среда.

В рамките на минути всеки иска различен отговор. Главният технологичен директор пита дали уязвимостта е реална. Правният екип пита дали се задейства докладване по Регламента на ЕС за киберустойчивост. Продуктовият екип пита кои версии са засегнати. CISO пита дали зависимостта присъства в някой SBOM. Търговският екип пита дали клиентите от финансовия сектор се нуждаят от доказателства по DORA. Мениджърът по съответствието отваря регистъра на риска по ISO 27001 и намира процес за управление на уязвимости, но не и ясен път за вземане на решение относно докладване за продукт.

Това е реалният проблем при готовността за CRA. Повечето организации не започват от нулата. Те вече имат политики за реагиране при инциденти, практики за управление на корекции, практики за сигурна разработка, прегледи на доставчици, скенери за уязвимости и доказателства по ISO 27001. Но CRA не възнаграждава изолирани документи. Той изисква бърз, защитим работен поток, който може едновременно да отговори на пет въпроса:

1. Това активно експлоатирана уязвимост ли е или сериозен инцидент, засягащ сигурността на продукта?
2. Кои продукти, версии, клиенти, зависимости и доставчици са засегнати?
3. Кой орган, клиент или договорно определен получател трябва да бъде уведомен и кога?
4. Какви доказателства показват, че триажът, смекчаването и оповестяването са били контролирани?
5. Как това е съгласувано с ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF и очакванията при одит?

Отговорът не е отделна „папка за CRA“. Отговорът е докладването на уязвимости по CRA да бъде свързано със СУИС, процеса за координирано оповестяване на уязвимости, дисциплината около SBOM, управлението на доставчици и веригата от доказателства при реагиране при инциденти, които вече са необходими за зряло управление на киберсигурността.

Защо Регламентът на ЕС за киберустойчивост променя модела на докладване

Регламентът на ЕС за киберустойчивост, Регламент (EU) 2024/2847, въвежда сигурността на продуктите в основния поток на съответствието. Той се прилага за продукти с цифрови елементи, пуснати на пазара на ЕС, което може да включва свързани устройства, софтуер, фърмуер, вградени системи и корпоративни софтуерни продукти.

Оперативната промяна, която е най-важна за CISO, ръководителите по продуктова сигурност и екипите по съответствие, започва на 11 септември 2026 г. CRA Article 14 изисква поетапно докладване за активно експлоатирани уязвимости и сериозни инциденти, засягащи сигурността на продукти с цифрови елементи. На практика производителите трябва да бъдат готови за:

Точната правна оценка винаги следва да се извършва от квалифициран правен консултант, но оперативният извод е ясен. Първите 24 до 72 часа са толкова добри, колкото е добра подготовката, завършена месеци по-рано.

Ако вашите SBOM са непълни, ако пощенската кутия за CVD се наблюдава неформално, ако договорите с доставчици не изискват уведомяване за уязвимости или ако вашата политика за реагиране при инциденти не разграничава докладването на продуктови уязвимости от инциденти, свързани с поверителността или операциите, правният срок ще се движи по-бързо от процеса ви за доказателства.

Използвайте ISO/IEC 27001:2022 като основа за готовност за CRA

ISO/IEC 27001:2022 не е заместител на правното съответствие с CRA, но е най-добрата системна основа за управление, чрез която задълженията по CRA могат да бъдат интегрирани в ежедневното управление.

Клаузи 4.1 до 4.4 изискват организацията да разбира вътрешния и външния контекст, заинтересованите страни, изискванията, интерфейсите с други организации и обхвата на СУИС ISO/IEC 27001:2022. За готовност за CRA това означава, че обхватът на СУИС трябва да идентифицира продукти с цифрови елементи, отговорности по жизнения цикъл на продукта, хоствани компоненти, пайплайни за компилация, open-source зависимости, доставчици, потребители, вносители, дистрибутори, регулирани клиенти и съответните органи.

Клаузи 6.1.1 до 6.1.3 изискват оценка на риска и третиране на риска, включително собственици на риска, последици, вероятност, решения за третиране, Декларация за приложимост и приемане на остатъчния риск. Докладването по CRA следва да се третира като рисков сценарий за сигурността на продукта в рамките на този процес, а не като извънредно упражнение по правно тълкуване.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 предоставя практическата структура на контролите. Най-важните контроли за докладване на уязвимости по CRA са:

В Zenith Controls: The Cross-Compliance Guide Clarysec съпоставя контрол 8.8 по ISO/IEC 27002:2022, управление на техническите уязвимости, като превантивен контрол, подпомагащ поверителността, целостта и наличността. Неговите атрибути са съгласувани с концепциите Identify и Protect в киберсигурността, като оперативната способност е управление на заплахи и уязвимости.

Тази рамка е важна. Докладването по CRA не се изчерпва с уведомяване на органите. То изисква доказване, че превантивна способност за управление на уязвимости е съществувала преди получаването на доклада.

Изградете оперативния модел около CVD, SBOM и срока за докладване

Надежден работен поток за уязвимости по CRA започва преди изследовател изобщо да се свърже с вас. Той започва със способността да приемате доклади за уязвимости, да ги валидирате, да идентифицирате засегнатите компоненти, да оценявате експлоатацията, да координирате смекчаването, да комуникирате с потребителите и да съхранявате доказателства.

Първият градивен елемент е публичен канал за докладване на уязвимости. Политика за координирано оповестяване на уязвимости на Clarysec, клауза 6.1 от изискванията за внедряване, посочва:

Публични канали за оповестяване: Организацията следва да поддържа ясен канал за докладване на уязвимости, като например отделен имейл адрес за контакт по сигурността (например security@company.com) или уеб формуляр. Тази информация следва да бъде публикувана на страницата за сигурност на уебсайта на компанията, заедно с публичния PGP ключ на организацията, за да се даде възможност за криптирани подавания.

Това решава често срещан одитен пропуск. Много компании заявяват, че приемат доклади за уязвимости, но пътят за докладване е скрит, неуправляван или насочен към обща опашка за поддръжка. При CRA каналът за докладване се превръща в точка, която задейства правно узнаване, оценка на сериозността и събиране на доказателства.

Вторият градивен елемент е триажът. Политика за координирано оповестяване на уязвимости, клауза 6.4 от изискванията за внедряване, посочва:

Триаж и потвърждение: При получаване на доклад VRT следва да го регистрира и да изпрати потвърждение на докладващото лице в срок до 2 работни дни, като присвои референтен номер за проследяване. VRT следва да извърши предварителна оценка на сериозността, например чрез CVSS точкова оценка, и да валидира проблема, включително с подкрепа от ИТ и екипите за разработка, когато е необходимо, в целеви срок от 5 работни дни. Критични уязвимости, като такива, които позволяват отдалечено изпълнение на код или съществено нарушение на сигурността на данните, следва да се обработват приоритетно.

За готовност за CRA този запис за триаж следва да бъде разширен с полета, които подпомагат решението за правно докладване:

Третият градивен елемент е дисциплината около SBOM. Политика за сигурна разработка на Clarysec, клауза 5.4 от изискванията за управление, посочва:

Използването на open-source код или код от трети страни трябва да бъде одобрявано, проследявано и валидирано чрез: 5.4.1 анализ на състава на софтуера (SCA) 5.4.2 преглед на лиценза (GPL, MIT, BSD и др.) 5.4.3 сканиране за известни уязвимости (CVE, OSS Index и др.)

За по-малки организации Политика за изискванията за сигурност на приложенията - МСП на Clarysec, клауза 6.4.2 от изискванията за прилагане на политиката, задава същото очакване в практическа форма:

Запис за всеки използван външен компонент трябва да се поддържа от разработчика или доставчика на ИТ услуги, включително:

Този запис за компонент се превръща в минималния набор от доказателства за реагиране при уязвимости, основано на SBOM. Той трябва да свързва име на компонент, версия, източник, доставчик или хранилище, лиценз, версия на продукта, дата на компилация и статус на сканиране за уязвимости. Когато пристигне CVE, доклад от изследовател или уведомление от доставчик, екипът ви трябва да може в рамките на часове да отговори: „Кои пуснати продукти съдържат този компонент?“

Съпоставете CRA, NIS2, DORA и GDPR в единна матрица за решение за уведомяване

Регламентът за киберустойчивост няма да действа изолирано. Една уязвимост в продукт може да задейства докладване по CRA, оценка за инцидент по NIS2, задължения за клиентски доказателства по DORA, оценка за нарушение по GDPR и договорни задължения за уведомяване.

NIS2 Article 21 изисква съществените и важните субекти да прилагат подходящи технически, оперативни и организационни мерки. Тези мерки включват анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване, разработка и поддръжка, обработване и оповестяване на уязвимости, оценка на ефективността, киберхигиена, криптография, сигурност в областта на човешките ресурси, контрол на достъпа, управление на активите, MFA и сигурни комуникации.

NIS2 Article 23 задава поетапен модел за докладване на инциденти: ранно предупреждение в срок до 24 часа от узнаването, уведомление за инцидент в срок до 72 часа, междинни актуализации при поискване и окончателен доклад не по-късно от един месец след уведомлението за инцидента. NIS2 Article 20 също създава отчетност на управителния орган за одобряване и надзор върху мерките за управление на риска за киберсигурността.

DORA се прилага от 17 януари 2025 г. и създава единна рамка на ЕС за цифрова оперативна устойчивост за финансовите субекти. За SaaS доставчици, доставчици на софтуер и ИКТ доставчици DORA често се проявява чрез клиентски договори. Вашият клиент от финансовия сектор може да е регулираният субект по DORA, но вашето обработване на уязвимости, SBOM доказателства, подкрепа при инциденти, права на одит и ангажименти за уведомяване може да са необходими, за да може този клиент да изпълни собствените си задължения.

GDPR добавя още един клон. Ако уязвимостта или инцидентът причинява случайно или незаконосъобразно унищожаване, загуба, промяна, неразрешено разкриване на лични данни или неразрешен достъп до тях, се изисква оценка за нарушение на сигурността на личните данни. GDPR Article 5 също включва цялостност, поверителност и отчетност, което означава, че организацията трябва да може да докаже процеса си на вземане на решения.

Политика за реагиране при инциденти на Clarysec, клауза 6.4.1 от изискванията за прилагане на политиката, вече подпомага тази оценка по няколко режима:

Ако инцидент доведе до потвърдено или вероятно излагане на лични данни или други регулирани данни, правният отдел и DPO трябва да оценят приложимостта на: 6.4.1.1 GDPR Article 33 (72-часово уведомяване на надзорния орган) 6.4.1.2 GDPR Article 34 (уведомяване на субектите на данни, когато се прилага висок риск) 6.4.1.3 NIS2 Article 23 (уведомяване в срок до 24 часа от узнаване на инцидента) 6.4.1.4 DORA Article 17 (докладване на сериозни инциденти, свързани с ИКТ)

За готовност за CRA разширете този наръчник, за да включи оценка за докладване по CRA Article 14 за активно експлоатирани уязвимости и сериозни инциденти, засягащи сигурността на продукта.

Единната матрица за решения предотвратява работата на екипите по отделни, несъгласувани наръчници за докладване:

За МСП Политика за реагиране при инциденти - МСП на Clarysec, клауза 5.3.2 от изискванията за управление, дава същия принцип в по-опростена форма:

Сроковете за реагиране, включително възстановяване на данни и задължения за уведомяване, трябва да бъдат документирани и съгласувани с правните изисквания, като например 72-часовото изискване по GDPR за уведомяване при нарушение на сигурността на личните данни.

Готовността за CRA просто разширява този принцип от уведомяване при нарушение на сигурността на личните данни към докладване на продуктови уязвимости и инциденти по сигурността на продукта.

Доказателствата от доставчици вече са доказателства за сигурността на продукта

Много релевантни за CRA уязвимости ще произхождат извън вашата кодова база. Те могат да идват от open-source пакети, фърмуерни модули, SDK, хоствани приложно-програмни интерфейси (API), инструменти за компилация, облачни услуги, компоненти, възложени на подизпълнители, или upstream библиотеки. Това прави управлението на доставчици централно за готовността за CRA.

Клауза 8.1 на ISO 27001:2022 изисква организациите да контролират външно предоставени процеси, продукти или услуги, релевантни за СУИС. Контрол 5.21 по ISO/IEC 27002:2022, управление на информационната сигурност във веригата за доставки на ИКТ, предоставя контролната основа.

В Zenith Controls Clarysec съпоставя контрол 5.21 като превантивен контрол, подпомагащ поверителността, целостта и наличността. Неговата оперативна способност е сигурност на взаимоотношенията с доставчици, а домейните му включват управление, екосистема и защита. Посланието е просто: контролите за доставчици не са документация за закупуване. Те са контроли за защита на екосистемата.

Политика за сигурност на трети страни и доставчици - МСП на Clarysec, клауза 5.3 от изискванията за управление, задава договорната основа:

Договорите трябва да включват задължителни клаузи, обхващащи:

За корпоративни програми Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Controls in Action“, стъпка 23, организационни контроли 5.19 до 5.37, обяснява контрол 5.20 по ISO/IEC 27002:2022, отразяване на информационната сигурност в споразуменията с доставчици:

Доверието, когато става въпрос за доставчици, не може да се основава на предположения. То трябва да бъде кодифицирано.

За готовност за CRA споразуменията с доставчици следва да включват клаузи за сигурност на продукта, които подпомагат бързо реагиране при уязвимости:

DORA засилва същата посока. Финансовите субекти трябва да управляват ИКТ риск от трети страни, да поддържат регистри на договори за ИКТ услуги, да оценяват критичност, да извършват надлежна проверка, да управляват риск от концентрация, да дефинират договорни предпазни мерки, да осигуряват права на одит и да планират изход. Ако продавате софтуер или ИКТ услуги на финансови субекти, очаквайте клиентите да попитат дали вашият процес за докладване на уязвимости и SBOM може да подпомогне техните нужди от доказателства по DORA за инциденти, устойчивост и трети страни.

Работният поток на Clarysec за готовност за CRA

Clarysec помага на клиентите да приложат докладването по CRA в рамките на съгласувана с ISO 27001:2022 СУИС чрез практически работен поток.

1. Добавете задълженията по CRA в регистъра на изискванията на СУИС

Започнете с клаузи 4.1 до 4.4 на ISO 27001:2022. Актуализирайте организационния контекст, заинтересованите страни и обхвата, за да включите продукти с цифрови елементи, експозиция на пазара на ЕС, потребители, вносители, дистрибутори, регулатори, CSIRT, доставчици и регулирани клиенти.

Създайте записи в регистъра на изискванията за докладване на уязвимости по CRA, докладване на сериозни инциденти по сигурността на продукта по CRA, уведомяване за инциденти по NIS2, задължения за клиентска поддръжка по DORA, оценка за нарушение на сигурността на личните данни по GDPR, договорно уведомяване за инциденти, CVD ангажименти и комуникация с изследователи.

Това дава на одиторите проследим път от външното задължение до вътрешния контрол.

2. Създайте формуляр за приемане на продуктови уязвимости

Базирайте формуляра за приемане на Политика за координирано оповестяване на уязвимости. Той трябва да събира самоличност на докладващото лице, сигурни данни за контакт, версия на продукта, модул, среда, proof of concept, стъпки за възпроизвеждане, статус на експлоатация, потенциално излагане на данни, въздействие върху услугата, съвпадение със SBOM компонент, CVSS или еквивалентна степен на сериозност, собственик, референтен номер за проследяване и регулаторна контролна точка.

Формулярът следва автоматично да създава тикет в опашката за реагиране при уязвимости. Той следва също да стартира таймер за решение за уведомяване, дори ако окончателният отговор е „не подлежи на докладване“.

3. Свържете SBOM данните с версиите

За всяка пусната версия на продукт поддържайте SBOM или еквивалентен инвентар на компоненти. Минимално полезните доказателства включват име на компонент, версия, източник, лиценз, доставчик или хранилище, версия на продукта, дата на компилация и статус на сканиране за уязвимости.

Политика за сигурна разработка и Политика за изискванията за сигурност на приложенията - МСП предоставят политическата основа за SCA, преглед на компоненти и записи за външни компоненти.

4. Съхранявайте доказателства от първия ден

Всеки тикет за уязвимост, релевантна за CRA, следва да съхранява:

• Първоначалния доклад
• Времеви маркер на потвърждението
• Бележки от триажа
• Обосновка за CVSS или еквивалентна степен на сериозност
• Резултати от съвпадение със SBOM
• Оценка на експлоатацията
• Журнали, индикатори и форензични снимки
• Комуникации с доставчици
• Приемане на риска, ако смекчаването се забавя
• План за корекция, бележки към версия и доказателства от тестване
• Решения за уведомяване на клиенти и органи
• Входни данни за окончателния доклад и извлечени поуки

Това е съгласувано с клауза 8.1 на ISO 27001:2022, която изисква документирана информация, достатъчна за доказване, че процесите са работили както е планирано, както и с клаузи 8.2 и 8.3, които изискват документирани резултати от оценка на риска и третиране на риска.

5. Тествайте с реалистичен сценарий за зависимост

Проведете настолно упражнение със симулирана активно експлоатирана уязвимост в зависимост. Включете инженеринг, сигурност, правен отдел, поверителност, продуктови екипи, комуникации, управление на доставчици и екипи за работа с клиенти. Тестът трябва да докаже, че организацията ви може да идентифицира засегнати версии, да оцени експлоатацията, да вземе решение за уведомяване, да се свърже с доставчици, да подготви указания за потребителите и да съхрани доказателства.

Как одиторите ще тестват готовността за докладване на уязвимости по CRA

Прегледът на готовността за CRA рядко ще се ограничи до контролен списък за CRA. Различни одитори ще тестват едни и същи доказателства през различни рамки.

В Zenith Controls Clarysec съпоставя контрол 5.24 по ISO/IEC 27002:2022, планиране и подготовка за управление на инциденти по информационна сигурност, като коригиращ контрол, подпомагащ поверителността, целостта и наличността. Той е съгласуван с Respond и Recover, като оперативните способности са управление и управление на събития по информационна сигурност.

Този контрол е мостът между откриването на уязвимост и регулаторното докладване.

NIST CSF 2.0 е особено полезна като комуникационен слой към управителния съвет. Функциите GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND и RECOVER помагат да се обясни как докладването на продуктови уязвимости се вписва в корпоративното управление на киберсигурността, вместо да остава инженерно изключение.

Често срещани пропуски в готовността за CRA, които трябва да се отстранят преди 2026 г.

Clarysec вижда едни и същи пропуски многократно.

Първият е CVD без докладване. Компанията има имейл адрес за сигурност или security.txt файл, но няма вътрешен път от доклада на изследовател до оценка за правно уведомяване.

Вторият е SBOM без собственост. Инженерният екип може да генерира SBOM по време на компилация, но никой не носи отговорност за точността за пуснатите продукти или не обяснява как констатациите от SBOM захранват реагирането при уязвимости.

Третият е ISO сертификат без продуктов обхват. СУИС покрива корпоративните ИТ и SaaS операциите, но не и вграден софтуер, фърмуер, инфраструктура за продуктови актуализации, пайплайни за компилация или оповестяване на уязвимости.

Четвъртият е договори с доставчици без клаузи за уязвимости. Закупуването изисква поверителност и защита на данните, но не и уведомяване за уязвимости, прозрачност на компонентите, съдействие при инциденти, координирано оповестяване или доказателства за одит.

Петият е реагиране при инциденти без логика за продуктови уязвимости. Планът за инциденти покрива ransomware, фишинг и нарушения на сигурността на личните данни, но не и активно експлоатирани продуктови уязвимости, при които системите на клиентите може да са изложени на риск преди собствената среда на производителя да бъде компрометирана.

Шестият е ръчна обработка на клиентски доказателства по DORA. Търговският екип или екипът за клиентски успех отговаря на въпросници от финансовия сектор случай по случай, докато сигурността няма стандартен пакет доказателства, показващ обработване на уязвимости, управление на SBOM, подкрепа при инциденти и контроли за доставчици.

Всеки пропуск може да бъде отстранен. Всеки става скъп, ако бъде открит по време на реална уязвимост.

90-дневен контролен списък за готовност за докладване на уязвимости по CRA

Използвайте следващите 90 дни, за да изградите защитима основа:

• Идентифицирайте продуктите с цифрови елементи, пуснати или предоставени на пазара на ЕС.
• Актуализирайте обхвата на СУИС и анализа на заинтересованите страни, за да включите заинтересованите страни по CRA.
• Добавете оценка за докладване по CRA Article 14 в регистъра на правните и регулаторните изисквания.
• Публикувайте и наблюдавайте сигурен канал за докладване на уязвимости.
• Създайте екип за реагиране при уязвимости с роли за правни въпроси, продукт, инженеринг, сигурност и комуникации.
• Поддържайте SBOM или инвентари на компоненти за пуснати продуктови версии.
• Свържете SCA резултатите с тикети за уязвимости и продуктови версии.
• Добавете критерии за активна експлоатация и сериозен продуктов инцидент във формулярите за триаж.
• Създайте комбинирана матрица за решения за уведомяване по CRA, NIS2, DORA, GDPR и договори.
• Актуализирайте договорите с доставчици с клаузи за уведомяване за уязвимости, SBOM, съдействие при инциденти и координация на оповестяването.
• Поддържайте журнали на корекциите и доказателства за отстраняване.
• Тествайте работния поток със симулирана активно експлоатирана уязвимост в зависимост.
• Представете резултатите пред ръководството с пропуски, остатъчни рискове и собственици на отстраняването.
• Добавете пакета доказателства към вътрешния одит и прегледа от ръководството.

Политика за управление на уязвимости и корекции - МСП на Clarysec, клауза 6.2.1 от изискванията за прилагане на политиката, подпомага основата за мониторинг:

ИТ функцията трябва да наблюдава уязвимостите чрез:

Същата политика, клауза 5.4.1 от изискванията за управление, добавя одитната следа:

Трябва да се поддържа журнал на корекциите и той да се преглежда по време на одити и дейности по реагиране при инциденти

Този журнал на корекциите може да се превърне в един от най-важните артефакти в окончателен доклад по CRA. Той доказва откриване, приоритизация, отстраняване, тестване и приключване.

Направете септември 2026 г. скучен

Най-доброто събитие за докладване по CRA не е лесно, защото уязвимостта е проста. То е лесно, защото организацията вече е отрепетирала работния поток.

Преди септември 2026 г. Clarysec може да ви помогне да превърнете докладването на уязвимости в система, готова за одит, като съпостави текущата ви ISO 27001:2022 СУИС, CVD процеса, SBOM способността, клаузите за доставчици и наръчниците за реагиране при инциденти с очакванията по CRA, NIS2, DORA, GDPR и NIST CSF.

Започнете с фокусирана оценка на готовността за докладване на уязвимости по CRA. Clarysec ще прегледа вашите политики, SBOM доказателства, договори с доставчици, тикети за уязвимости, наръчници за инциденти и одитна следа. След това ще използваме Zenith Blueprint и Zenith Controls, за да изградим практическа пътна карта за отстраняване, а не теоретична папка за съответствие.

Ако вече използвате политиките на Clarysec, ще ги настроим за докладване по CRA. Ако не ги използвате, можем да помогнем за внедряване на правилния набор от политики, включително Политика за координирано оповестяване на уязвимости, Политика за сигурна разработка, Политика за реагиране при инциденти, Политика за управление на уязвимости и корекции - МСП, Политика за изискванията за сигурност на приложенията - МСП и Политика за сигурност на трети страни и доставчици - МСП, когато е приложимо.

Септември 2026 г. е достатъчно близо за планиране и достатъчно далеч за дисциплинирана подготовка. Организациите, които действат сега, няма да питат „Кой е собственикът на тази уязвимост?“ през първите 24 часа. Те вече ще имат отговора, доказателствата и пътя за докладване.

Свържете се с Clarysec, за да насрочите оценка на готовността за докладване на уязвимости по CRA и да превърнете регулаторната сложност в защитимо предимство за сигурността на продукта.