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

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

Цифровият продуктов паспорт или продуктова страница, свързана чрез QR код, може да помогне за еднозначното идентифициране на дадено устройство и по-късното информиране на потребителите за актуализация. Той обаче не е нито законовият канал за докладване, нито правилното място за съхраняване на поверителни подробности за експлойта. Затова производителите трябва още сега да разделят три потока от данни: уведомлението до органите, публичната информация за продукта и вътрешната история на актуализациите.

Новият повод: насоки от 27 и 31 юли

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

Четири дни по-късно, на 31 юли, ENISA актуализира своята информация за Single Reporting Platform. В нея вече са посочени планираният процес, предвидените полета за въвеждане и указанията за регистрация. Платформата трябва да бъде готова за работа до 11 септември 2026 г.; според Комисията функционалните тестове и тестовете за сигурност вече се провеждат.

Поетапното въвеждане във времето е важно: основните задължения по CRA по принцип се прилагат от 11 декември 2027 г. Член 14 със задълженията за докладване обаче се прилага още от 11 септември 2026 г. Това се потвърждава както от член 71 от Регламент (ЕС) 2024/2847, така и от актуализирания на 31 юли преглед на Комисията на процедурата за докладване по CRA.

Три пространства за данни вместо един претоварен продуктов паспорт

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

1. Поверително уведомление до SRP, CSIRT и ENISA

Single Reporting Platform е законовият входен канал. Трябва да бъдат докладвани два вида събития: активно експлоатирана уязвимост, за която има надеждни указания за неразрешена експлоатация, и сериозен инцидент, който засяга наличността, автентичността, целостта или поверителността на данни или функции.

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

2. Публична продуктова информация и информация за сигурността

Публичният поток от данни отговаря на други въпроси: Кой продукт и коя версия притежавам? Все още ли се поддържа? Налична ли е актуализация на сигурността? Какво конкретно трябва да направя като потребител? За тази цел стабилна продуктова страница зад QR код или друг носител на данни може да бъде полезна.

Публичната страница трябва да показва само одобрена информация: засегнатите диапазони от модели и версии, наличната сигурна версия, указания за инсталиране, контакт за поддръжка и момента на публикуване. Подробностите за експлойта, вътрешните правила за откриване, непоправените пътища за атака или личните данни за инцидента остават в защитената процедура. Решението за публично предупреждение не се взема от QR кода: съгласно член 17 от CRA координиращият CSIRT може да информира обществеността или да поиска от производителя да го направи, когато това е необходимо за предотвратяване или ограничаване на последиците.

3. Вътрешна история на актуализациите и доказателствата

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

За DPP-операция тази разлика е от ключово значение: публичният изглед показва текущото одобрено състояние; вътрешната история доказва как е достигнато до него. Който вече поддържа продуктовите данни на базата на събития, може да използва същия принцип както при DPP-актуализации и уебкуки: едно събитие задейства последващи процеси, но всеки получател получава само предвидените за неговата роля полета.

Часовникът на CRA започва да тече от узнаването

Член 14 работи с поетапни срокове. При активно експлоатирана уязвимост без неоправдано забавяне и най-късно в рамките на 24 часа след узнаването е необходимо ранно предупреждение. В рамките на 72 часа следва по-подробното уведомление за уязвимостта. Окончателният доклад трябва да е наличен най-късно 14 дни след като бъде предоставена мярка за коригиране или ограничаване на последиците.

При сериозен инцидент със сигурността също се прилагат 24 часа за ранното предупреждение и 72 часа за уведомлението за инцидента. Окончателният доклад следва в рамките на един месец след уведомлението в рамките на 72 часа. Следователно сроковете не започват да текат от публикуването на CVE и не се броят от следващото редовно издание, а от момента, в който се счита, че производителят е информиран.

За практиката се препоръчва ясен процес:

Регистрирайте с времеви печат постъпването от поддръжката, мониторинга, изследователската дейност или веригата на доставки.
Съпоставете продукта и версията със стабилен вътрешен идентификатор на продукта.
Оценете експлоатацията, съответно тежестта на инцидента, от компетентния екип.
Създайте набора от данни за 24-часовото уведомление от потвърдените минимални данни и го подайте чрез SRP.
Допълнете техническите констатации до етапа от 72 часа, без да губите първоначалното състояние.
Одобрете отделно корекцията, мярката за потребителите и публичната информация.
Свържете окончателния доклад с вътрешната история.

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

Един общ идентификатор на продукта, но разделени права за достъп

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

Най-малкото трябва да са налични следните съпоставяния:

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

Упълномощаването трябва да се разглежда на ниво поле. Екипът за инциденти и отговорните за CRA лица се нуждаят от пълното досие. Поддръжката и търговският отдел имат нужда от одобрени указания за действие. Потребителите виждат само публичното съобщение. В идеалния случай QR кодът пренася само стабилен адрес на продукта; платформата зад него решава въз основа на статуса и ролята коя информация да бъде предоставена.

Какво трябва да тестват производителите до септември

Един подходящ тестов случай не се нуждае от реална уязвимост. Изберете свързан продукт, засегната версия на фърмуера и три държави членки. Симулирайте узнаването в работен ден и проверете:

Може ли екипът в рамките на 24 часа да потвърди обхвата на продукта и минималните данни?
Ясно ли е кой трябва да получи достъп до SRP като представител чрез EU Login?
Могат ли да се добавят данните за 72-часовия етап, без поверителни подробности да станат публични?
Води ли одобрението на корекцията до проверена информация за потребителите на всички необходими езици?
Остава ли публичният URL стабилен, когато версията и мерките се променят?
Може ли да се проследи кой, какво състояние и кога е одобрил?

За последната точка помага последователното версионирано управление на данните. Статията на qr3 за текущо DPP-актуализиране показва основната идея: идентичността остава стабилна, докато специализираните данни се актуализират контролирано. В процеса по CRA към това се добавя по-строг слой на поверителност и одобрение.

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

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

Един общ идентификатор на продукта свързва тези области. Ролите, одобренията и версионирането предотвратяват изтичането на поверителни подробности навън или твърде късното информиране на потребителите за налична мярка. QR кодът остава полезен, но умишлено незабележим: той води постоянно към правилния продуктов контекст. Същинското съответствие с CRA се постига в процесите зад него.