Актът за киберустойчивост: задължението за докладване се прилага от 11 септември 2026 г.

Повечето регламенти на ЕС дават дата за съответствие и гратисен период, през който всички тихомълком се организират. Актът за киберустойчивост (CRA) действа различно. Първото му твърдо задължение е 24-часов срок за докладване, и то се прилага от 11 септември 2026 г.

Един 24-часов срок не може да се въвежда постепенно. Или процесът е налице, когато се появи експлоатирана уязвимост, или пропускате срока.

Какво представлява CRA

Регламент (ЕС) 2024/2847 определя изисквания за киберсигурност към продуктите с цифрови елементи, пускани на пазара на ЕС. Понятието обхваща много повече, отколкото обикновено се предполага в началото: всеки софтуерен или хардуерен продукт, заедно с решенията му за отдалечена обработка на данни, чиято предвидена или разумно предвидима употреба включва пряка или непряка връзка за данни.

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

Актът е публикуван през ноември 2024 г. и се прилага на етапи:

• 11 юни 2026 г.: задължения за органите за оценяване на съответствието.
• 11 септември 2026 г.: задължения за докладване на активно експлоатирани уязвимости и тежки инциденти.
• 11 декември 2027 г.: пълно прилагане, включително съществените изисквания за киберсигурност, маркировката CE, техническата документация и спецификацията на софтуерните компоненти (SBOM).

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

Какво се прилага от 11 септември 2026 г.

От тази дата производителите трябва да докладват:

Активно експлоатирани уязвимости в своите продукти с цифрови елементи, и

Тежки инциденти, засягащи сигурността на тези продукти.

Докладването става през единната платформа за докладване по CRA, поддържана от ENISA, до екипа CSIRT, определен в държавата членка, където е основното място на стопанска дейност на производителя, а той препраща информацията към другите засегнати CSIRT и към ENISA. ENISA пусна първа версия на платформата на 11 септември 2026 г., в деня, в който задължението влезе в сила, и обявява, че през следващите месеци ще добавя функции.

Сроковете:

• До 24 часа след узнаването: ранно предупреждение.
• До 72 часа: пълно уведомление, включително предприетите коригиращи или смекчаващи мерки.
• До 14 дни след като коригиращата мярка стане достъпна: окончателен доклад за активно експлоатирана уязвимост.
• До един месец: окончателен доклад за тежък инцидент.

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

Защо е по-трудно, отколкото изглежда

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

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

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

Затова екипите изграждат конвейери за спецификация на софтуерните компоненти още сега, повече от година преди официалното изискване за SBOM през декември 2027 г. Целта не е SBOM. Целта е да можете да отговорите на въпроса „засегнати ли сме?“ в рамките на часове, а SBOM е това, което прави отговора възможен.

Неприятното е, че това важи и за продукти, които сте пуснали преди години. Ако имате поддържани устройства на терен с фърмуер, компилиран през 2022 г. от дърво на зависимостите, което никой не е записал, възстановяването му е сериозна работа.

Трябва да наблюдавате

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

Трябва да имате път за вземане на решение

Някой трябва да може във всеки час да реши дали даден инцидент достига прага и дали срокът е започнал да тече. Без определена роля и път за ескалация първите часове отиват в изясняване кой има право да вземе решението.

Зависимостите с изтекла поддръжка стават риск

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

Какво носи пълното прилагане през декември 2027 г.

Задълженията от декември 2027 г. са по-голямата програма и трябва да започнат много по-рано.

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

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

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

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

Маркировка CE. Цифровият еквивалент на физическата маркировка, с който се декларира съответствие.

Политика за координирано оповестяване на уязвимости. Публикувана, с работеща точка за контакт.

Кой всъщност попада в обхвата

Няколко гранични случая възникват постоянно.

Свободният софтуер и софтуерът с отворен код, разработван извън търговска дейност, до голяма степен е извън обхвата. Актът въвежда понятието „стюард на софтуер с отворен код“ с по-леки задължения. Но ако комерсиализирате софтуер с отворен код или го доставяте в продукт, който продавате, задълженията за продукта са ваши.

Софтуерът като услуга (SaaS) по правило е извън CRA и попада под NIS2, но решенията за отдалечена обработка на данни, които са неразделна част от продукт с цифрови елементи, се включват. Ако устройството ви зависи от облачния ви бекенд, за да работи, този бекенд върви заедно с продукта.

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

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

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

Какво бихме направили сега

Ако сте в обхвата и започвате сега, редът, който работи:

Първо, съставете опис на продуктите. Какво всъщност имате на пазара на ЕС? Включително стари версии, които още са на терен, варианти под чужда марка и продукти, които дистрибутирате за някой друг. Този списък обикновено е по-дълъг, отколкото някой очаква.

Второ, вградете генерирането на SBOM в CI. Генерирайте SBOM при всяка компилация, в CycloneDX или SPDX, съхранявайте го заедно с артефакта на версията и поддържайте възможност за търсене в него. Смисълът е да можете да попитате „кои от пуснатите ни версии съдържат тази библиотека?“ и да получите отговор за минути.

Трето, свържете наблюдението на уязвимости. Подавайте данните от SBOM към скенер, който следи бюлетините за сигурност и каталозите с известни експлоатирани уязвимости, и пренасочвайте сигналите към канал, който някой чете.

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

Пето, публикувайте политика за оповестяване на уязвимости. Файл security.txt, адрес, който някой следи, и обявено време за отговор. Това е работа за един следобед и е разликата между това да научите за проблем от изследовател и да научите за него от журналист.

Шесто, започнете работата за декември 2027 г. Сигурните настройки по подразбиране, механизмите за актуализация, решенията за периода на поддръжка и документацията са въпроси на архитектурата, а не на документооборота. Продуктите, които проектирате през 2026 г., ще бъдат на пазара и през 2028 г.

Припокриването, което никой не използва

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

SBOM, изградена за CRA, отговаря на повечето въпроси за веригата на доставки в NIS2. Наръчникът за инциденти се припокрива с 24-часовото ранно предупреждение по NIS2 и със 72-часовото уведомяване за нарушение на сигурността на данните по ОРЗД. Процесите за обработка на уязвимости се използват пряко във въпросниците за сигурност на клиентите и в корпоративните обществени поръчки.

Изградете ги веднъж като възможност на платформата. Алтернативата е три екипа да изграждат три версии на един и същ опис на активите.

Откъде да получите помощ

Разработваме и поддържаме софтуер за компании, които продават в ЕС, а това все по-често означава изграждане на видимостта във веригата на доставки и на инфраструктурата за актуализации, които CRA приема за даденост. Ако изяснявате дали сте в обхвата, или задължението за докладване вече важи за вас, а никой не наблюдава компонентите ви, пишете ни на office@c9group.dev.

Нашата услуга за поддръжка на наследени системи често е началната точка, защото продуктите с най-лоша видимост на зависимостите обикновено са най-старите. По-широката регулаторна картина е в нашето ръководство за цифрово съответствие в ЕС за 2026 г.

Ние сме инженери, а не юристи. Решенията за обхвата и класификацията са работа на вашите юристи, а ние изграждаме според отговора, който те дадат.