Повідомлення про інциденти за CRA: сповіщення про вразливості, що активно експлуатуються і серйозні інциденти

Знайшли вразливість у продукті? Видихаємо, адже для security-команди це частина звичайної роботи. Спочатку перевіряємо проблему, далі оцінюємо ризики, після цього шукаємо спосіб її закрити й випускаємо патч. Але що робити, якщо виявилося, що хтось уже використовує цю вразливість для атак? Або якщо через інцидент продукт більше не може нормально захищати дані чи виконувати свої основні функції?

Саме для таких ситуацій  Cyber Resilience Act (CRA) встановлює окремі правила повідомлення про інциденти. Відтепер виробнику недостатньо просто закрити проблему, у визначених випадках він має повідомити про це відповідні органи через Single Reporting Platform (SRP). А ось коли саме виникає обов’язок повідомляти, яку інформацію потрібно надати на першому етапі та що відбувається далі – розберемо у цій статті.

Про що саме йдеться?

З 11 вересня 2026 року починають застосовуватися положення CRA щодо повідомлення про активно експлуатовані вразливості та серйозні інциденти, які впливають на безпеку продуктів із цифровими елементами (products with digital elements). Саме з цієї дати виробники таких продуктів мають виконувати reporting obligations, передбачені Article 14 CRA.

Читайте більше: EU Cyber Resilience Act (CRA): що робити і як бути в комплаєнсі

Проте це не означає, що тепер про кожен баг чи знайдену під час тестування вразливість потрібно повідомляти регулятору. CRA говорить конкретно про дві ситуації:

• активно експлуатовані вразливості (actively exploited vulnerabilities) – вразливості, щодо яких є достовірні докази фактичної експлуатації зловмисником; та
• серйозні інциденти, що впливають на безпеку продукту (severe incidents having an impact on the security of the product) – серйозні інциденти, які негативно впливають або можуть негативно вплинути на здатність продукту забезпечувати конфіденційність, цілісність, автентичність або доступність даних чи функцій.

Здавалося б, логіка проста, виявили проблему – повідомили. Але для цілей CRA спочатку потрібно визначити, чи має конкретна подія ознаки actively exploited vulnerability або severe incident, передбачені Article 14, і чи справді в компанії вже є достатні підстави вважати, що така подія сталася. Не менш важливо визначити, коли саме виробник дізнався про подію.

Що таке actively exploited vulnerability?

Активно експлуатована вразливість – це не будь-яка критична вразливість у продукті. Високий показник CVSS сам по собі тут нічого не вирішує, як і не вирішує те, що для вразливості вже існує технічний спосіб атаки (exploit).

CRA прив’язує цю категорію до іншого критерію – у виробника мають бути надійні докази (reliable evidence) того, що зловмисник уже використав вразливість у системі без дозволу її власника.

Простіше пояснити на прикладі. Дослідник знаходить знаходить спосіб обійти механізм автентифікації у вашому продукті та надсилає proof of concept. Security-команда відтворює проблему, підтверджує її серйозність і починає готувати патч. Вразливість може бути критичною, але для CRA цього ще недостатньо, щоб говорити про actively exploited vulnerability. Чому? Тому що регламент розділяє дві різні ситуації: вразливість можна використати і вразливість уже використовують. Для обов’язку повідомлення за Article 14 має значення саме друге. 

Тепер уявимо іншу ситуацію. У логах з’являються ознаки того, що хтось використав цю вразливість для несанкціонованого доступу. Може бути таке, що клієнт повідомляє про атаку, яку вдалося пов’язати саме з нею, або компанія отримує достовірну інформацію про її використання зловмисниками. За таких обставин компанії вже недостатньо поставити vulnerability у чергу на виправлення. Потрібно оцінити, чи є отримана інформація надійними доказами активної експлуатації, і якщо так – запускати процедуру повідомлення за CRA.

Не кожна критична вразливість є actively exploited vulnerability. Для CRA важливо не те, наскільки легко її можна використати, а те, чи є надійні докази, що її вже використовує зловмисник.

На цьому етапі у компаній може виникнути найбільше запитань. Що вважати достатнім доказом? Чи достатньо повідомлення від одного клієнта? Чи можна вважати підозрілу активність у логах підтвердженням? Чи потрібно спочатку провести повне технічне розслідування?

Універсальної відповіді для кожного інциденту немає і не буде. Оцінка залежатиме від обставин, якості доказів та можливості пов’язати конкретну активність саме з цією вразливістю. Технічне розслідування в цей момент, звичайно, не зупиняється, команда може ще з’ясовувати масштаб атаки, спосіб проникнення та кількість постраждалих продуктів. Але для CRA це вже не причина чекати завершення розслідування, оскільки 24 години рахуються від моменту, коли виробник дізнався про активну експлуатацію.

Це також означає, що ще до інциденту компанії варто визначити, хто оцінює достовірність доказів, хто фіксує момент, коли виробник дізнався про подію і хто має повноваження ухвалити рішення про повідомлення за CRA.

А що CRA називає severe incident?

CRA визначає серйозний інцидент через його вплив на безпеку продукту. Йдеться про подію, яка негативно впливає або може негативно вплинути на здатність продукту захищати важливі або чутливі дані чи функції щодо їх:

• доступності (availability);
• автентичності (authenticity);
• цілісності (integrity);
• конфіденційності (confidentiality).

Тобто сам факт того, що в компанії стався кіберінцидент, ще не означає, що він є severe incident за CRA. Потрібно дивитися на наслідки або потенційні наслідки саме для безпеки продукту.

Є ще другий критерій. Інцидент також може підпадати під цю категорію, якщо він призвів або може призвести до впровадження чи виконання шкідливого коду в самому продукті або в мережевих та інформаційних системах користувача. Наприклад, через атаку зловмисник отримує можливість змінювати критичні налаштування продукту, виконувати власний код або відключати його основні функції.  У кожній із таких ситуацій потрібно окремо оцінювати, чи досягнуто порогу severe incident за CRA.

На практиці компанії часто можуть ототожнювати такий інцидент з уже усталеним data breach за GDPR. Проте варто враховувати, що за CRA рамка значно ширша. Інцидент може взагалі не стосуватися персональних даних, але водночас створювати серйозний ризик для безпеки продукту або систем, у яких він використовується. Наприклад, DDoS-атака може не призвести до жодного витоку персональних даних, але якщо через неї продукт втрачає здатність забезпечувати доступність важливої функції, це вже потребує оцінки за критеріями severe incident.

Так само варто дивитися не лише на те, що вже сталося. Регламент враховує і ситуації, коли інцидент може негативно вплинути на захист даних або функцій. Тому відсутність фактичної шкоди на момент виявлення події не завжди означає, що повідомлення за CRA не потрібне.

Тому правильніше поставити інше питання: чи вплинув інцидент або чи може він вплинути на безпеку самого продукту та систем, у яких цей продукт використовується?

Що потрібно повідомити протягом перших 24 годин?

CRA вимагає подати раннє повідомлення (early warning) без невиправданої затримки, і в будь-якому разі не пізніше 24 годин із моменту, коли виробник дізнався про активно експлуатовану вразливість або серйозний інцидент.

Варто врахувати, що раннє повідомлення це не фінальний звіт про інцидент. Це цілком логічно, оскільки за 24 години компанія може ще не знати, як саме відбулася атака, який у неї масштаб і скільки користувачів вона могла зачепити. На цьому етапі основним завданням є не допустити ситуації, коли регулятор дізнається про actively exploited vulnerability або severe incident пізніше за всіх, поки виробник чекає на результати розслідування.

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

Тобто CRA не очікує, що за перші 24 години компанія проведе повноцінне розслідування. Часто стається так, що зранку команда виявляє підозрілу активність, вдень встановлює зв’язок із конкретною вразливістю, а ввечері отримує достатні докази її експлуатації. Частина технічних питань при цьому залишається відкритою. За логікою CRA це нормально, розслідування триває, але процедура повідомлення вже має рухатися паралельно. Далі інформацію можна доповнювати в межах наступних етапів повідомлення.

Що відбувається через 72 години?

Протягом наступних 72 годин виробник має передати вже більш детальну інформацію про подію.

Якщо йдеться про активно експлуатовану вразливість, подається повідомлення про вразливість (vulnerability notification) не пізніше 72 годин від моменту, коли виробник дізнався про її активну експлуатацію.

На цьому етапі потрібно повідомити ту інформацію, яку компанія вже має. Зокрема:

• який саме продукт із цифровими елементами зачепила вразливість;
• у чому полягає вразливість;
• як вона експлуатується;
• які заходи компанія вже вжила для усунення або зменшення ризику;
• що можуть зробити користувачі, щоб захистити себе;
• за потреби, наскільки чутливою є інформація, яка передається.

Для серйозного інциденту подається повідомлення про інцидент (incident notification). У ньому виробник описує характер події, її первинний вплив і оцінку, а також уже вжиті заходи реагування та можливі дії для користувачів.

Але, знову ж таки, за 72 години компанія може ще не знати всього, та й CRA цього від неї не вимагає. Якщо розслідування триває, у повідомленні зазначається інформація, доступна на цей момент. І це цілком логічно, оскільки інформація про кіберінцидент майже завжди змінюється в процесі розслідування. Те, що здавалося одиничною атакою в перший день, може виявитися частиною масштабнішої кампанії. А інцидент, який спочатку виглядав як локальна проблема одного клієнта, може виявитися системною вразливістю.

Саме тому CRA побудований як поетапний процес повідомлення:

1. Виробник дізнався про проблему;
2. Визначається, чи є надійні докази активної експлуатації вразливості або чи відповідає інцидент критеріям severe incident;
3. Якщо відповідь так, тоді до 24 годин раннє повідомлення, до 72 годин детальніше повідомлення про вразливість або інцидент;
4. Далі тривають розслідування, усунення вразливості та заходи зі зменшення ризику;
5. Подається фінальний звіт.

Коли потрібно подавати final report?

Після 24- і 72-годинних повідомлень компанія продовжує розслідування, усуває вразливість або наслідки інциденту, а після появи достатньої кількості нових даних подає фінальний звіт.

Для активно експлуатованої вразливості final report потрібно подати не пізніше ніж через 14 днів після того, як виробнику стає доступним corrective або mitigating measure. Тобто, наприклад, після випуску security update, який усуває вразливість, або іншого заходу, що дозволяє зменшити пов’язаний із нею ризик.

У фінальному звіті потрібно, зокрема, описати:

• саму вразливість;
• її рівень серйозності та вплив;
• за наявності, інформацію про зловмисника, який її використовував або використовує;
• security update чи інші заходи, за допомогою яких вразливість була усунута або ризик від неї зменшений.

Для серйозного інциденту final report потрібно подати протягом одного місяця після подання 72-годинного повідомлення про інцидент. У звіті потрібно надати детальний опис інциденту, його серйозність та вплив, тип загрози або ймовірну першопричину (root cause), а також заходи, які компанія вже застосувала або продовжує застосовувати для зменшення ризику.

Окремо варто врахувати, що CSIRT може запросити проміжний звіт (intermediate report). Це означає, що між 72-годинним повідомленням і фінальним звітом компанія за потреби може отримати ще один запит щодо перебігу розслідування або реагування.

Повідомлення за CRA це не один документ, який компанія надсилає після завершення всієї історії. Спочатку компанія сигналізує про проблему, потім доповнює інформацію, паралельно працює над її усуненням і врешті документує результат.

Кому потрібно повідомляти?

Ми вже зʼясували коли повідомлення за CRA потрібне, за скільки часу його потрібно подати, тепер залишається ще одне запитання: кому саме його подавати?

CRA передбачає для цього Single Reporting Platform – єдину платформу для повідомлення про відповідні вразливості та інциденти. Через цю платформу повідомлення надсилається CSIRT, визначеному як coordinator, а інформація також передається ENISA відповідно до механізму, встановленого регламентом. Це досить зручно, оскільки виробнику не потрібно готувати окремі повідомлення для кожного органу.

Насамперед потрібно визначити, який саме CSIRT є компетентним у конкретній ситуації. Для виробника, який має основне місце діяльності (main establishment) у ЄС, це визначається за правилами CRA. Для виробників, які знаходяться за межами ЄС, регламент передбачає інший порядок – залежно, зокрема, від того, хто представляє виробника в ЄС, де працюють його імпортери або дистриб’ютори та де перебувають користувачі продукту.

Якщо якщо продукт продається в кількох державах-членах, заздалегідь потрібно розуміти, який CSIRT буде відповідним і через який маршрут подаватиметься повідомлення. Тому в процедурі реагування на інциденти варто заздалегідь зафіксувати:

• який CSIRT є відповідним для кожного продукту або категорії продуктів;
• хто в компанії перевіряє правильність визначення адресата;
• хто має доступ до Single Reporting Platform;
• хто може подати повідомлення від імені виробника;
• хто замінює відповідальну особу у неробочий час.

Окремо варто перевірити й організаційну сторону процесу. Якщо повідомлення має бути подане протягом 24 годин, доступ до платформи та необхідні повноваження повинні бути налаштовані до інциденту, а не після його початку.

А користувачів теж потрібно повідомляти?

Так, і це, мабуть, один із найважливіших практичних аспектів CRA.

Після того як виробник дізнається про активно експлуатовану вразливість або серйозний інцидент, він має без зайвої затримки поінформувати користувачів, яких це стосується, а за необхідності – всіх користувачів продукту.

Для чого це? Все досить просто, користувач повинен розуміти, чи є для нього ризик і що саме потрібно зробити, щоб його зменшити. Наприклад, виробник може рекомендувати:

• встановити конкретне security update;
• змінити певні налаштування продукту;
• тимчасово вимкнути вразливу функцію;
• змінити облікові дані або ключі доступу;
• застосувати інші тимчасові заходи, поки остаточне виправлення ще готується.

Тому повідомлення на кшталт “ми знаємо про проблему та вже працюємо над її вирішенням” навряд чи буде достатнім, якщо користувачеві потрібно щось зробити зі свого боку. Чим зрозуміліше компанія пояснить наступні дії користувача, тим менше простору залишається для неправильного трактування або його бездіяльності.

Чи потрібно одразу публікувати всі технічні деталі?

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

CRA дозволяє враховувати чутливість інформації, що повідомляється, а механізм обміну даними між виробником і відповідними органами побудований так, щоб така інформація не ставала автоматично публічною.

Проте це не означає, що виробник може використати слово “конфіденційно” як причину взагалі нічого не повідомляти. Варто розділити щонайменше три групи інформації:

• що потрібно повідомити компетентним органам для оцінки ситуації та координації реагування;
• що потрібно повідомити користувачам, щоб вони могли захистити свої системи;
• які технічні деталі поки не варто розкривати ширше, оскільки це може збільшити ризик подальшої експлуатації.

Наприклад, користувачеві може бути достатньо знати, що його версія продукту вразлива, потрібно встановити конкретне оновлення або тимчасово вимкнути певну функцію. При цьому детальний proof of concept або технічний ланцюжок exploitation на цьому етапі може залишитися поза публічним повідомленням.

Потрібно дати достатньо інформації для захисту, але не перетворити повідомлення на готову інструкцію для наступної атаки.

Один інцидент може створити кілька обов’язків одночасно

Ще одна важлива теза, яку ми згадаємо сьогодні – CRA не існує у вакуумі. Якщо внаслідок атаки було скомпрометовано персональні дані, потрібно окремо перевірити, чи є це порушенням безпеки персональних даних (personal data breach) за GDPR і чи виникає обов’язок повідомити наглядовий орган.

Якщо компанія або її клієнт належить до суб’єктів, на яких поширюється NIS2, той самий інцидент може мати значення і для виконання вимог цього регулювання. Крім того, договори з клієнтами можуть встановлювати власні строки повідомлення, які іноді навіть коротші за законодавчі.

Тобто одна атака цілком може одночасно тригерити обов’язки за CRA, GDPR, NIS2 і договором із клієнтом. І строки при цьому також можуть бути різними.

Саме тому не варто будувати окремий процес реагування на кожен нормативний акт. Набагато ефективніше мати єдиний incident response process, у якому після виявлення події команда повинна швидко пройти кілька запитань:

1. Чи є actively exploited vulnerability або severe incident за CRA?
2. Чи стався personal data breach за GDPR?
3. Чи є значний інцидент за NIS2?
4. Що вимагають контракти з клієнтами та партнерами?
5. Кого потрібно повідомити та в які строки?

Хороша процедура реагування має відповідати не лише на питання “як ми закриємо інцидент?”, а й на питання “які юридичні обов’язки виникли одночасно з ним?”.

Що варто зробити компанії вже зараз?

Якщо ваш продукт підпадає під CRA, найгірший момент для створення процедури повідомлення – це момент, коли вже почалася атака. Тому CRA reporting краще підготувати як частину загального процесу реагування на інциденти. Щонайменше варто пройти кілька кроків.

Крок 1. Визначте, хто у вас виробник (manufacturer).

Не завжди компанія, яка продає продукт, юридично є його виробником за CRA. Потрібно розібратися:

• хто розробляє продукт;
• під чиїм ім’ям або торговельною маркою він виходить на ринок;
• хто приймає рішення про його модифікацію;
• хто відповідає за виправлення вразливостей та випуск security updates.

Це питання важливе, оскільки саме на виробника CRA покладає основні обов’язки щодо повідомлення про активно експлуатовані вразливості та серйозні інциденти.

Крок 2. Визначити, які продукти підпадають під CRA.

Складіть актуальний перелік продуктів із цифровими елементами, які ваша компанія виробляє або виводить на ринок ЄС. Для кожного продукту бажано розуміти:

• у яких державах-членах він доступний;
• які версії перебувають на ринку;
• хто відповідає за його кібербезпеку;
• де зберігається технічна документація;
• хто підтримує продукт;
• як користувачі отримують security updates;
• який CSIRT буде відповідним для повідомлення.

Ця інформація знадобиться не лише для загального CRA compliance. Вона також може знадобитися буквально в перші години після виявлення активно експлуатованої вразливості.

Крок 3. Встановіть чіткий процес ескалації.

Компанія має заздалегідь визначити:

• хто отримує повідомлення про vulnerability;
• хто аналізує evidence активної exploitation;
• хто класифікує incident;
• хто залучає legal та compliance teams;
• хто ухвалює рішення про подання повідомлення;
• хто фактично подає його через Single Reporting Platform.

І бажано, щоб цей список не складався з однієї людини. Інциденти не підлаштовуються під робочий графік персоналу. Більше того, люди можуть бути у відпустці, на лікарняному або просто спати, коли починається атака. Процедура має працювати незалежно від того, хто саме сьогодні чергує.

Крок 4. Підготуйте шаблони повідомлень.

Шаблон не замінить аналіз інциденту, але допоможе не витрачати дорогоцінний час на технічне оформлення. Заздалегідь можна передбачити поля для:

• ідентифікації продукту та його версії;
• дати й часу, коли виробник дізнався про подію;
• короткого опису vulnerability або incident;
• наявних доказів exploitation;
• оцінки впливу;
• уже вжитих заходів;
• рекомендацій для користувачів;
• контактної особи.

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

Крок 5. Перевірте процедуру на практиці.

Найпростіший спосіб зрозуміти, чи працює ваш процес, – змоделювати реальний інцидент. Наприклад, можна змоделювати сценарій:

У п’ятницю о 19:00 security researcher повідомляє про критичну vulnerability. О 22:30 SOC знаходить докази того, що її вже використовували проти одного з клієнтів. Патч поки що не готовий. Частина команди перебуває поза робочим часом.

Далі команда проходить цей сценарій від початку до кінця.

1. Хто отримує перше повідомлення?
2. Хто визначає, чи достатньо доказів для ескалації?
3. Коли підключається legal team?
4. Хто фіксує момент, коли виробник дізнався про активну експлуатацію?
5. Хто подає early warning?
6. Хто перевіряє, кому саме воно має бути направлене?
7. Як і коли повідомляються користувачі?
8. Що відбувається, якщо патч не готовий до моменту першого повідомлення?

Якщо на ці питання є конкретні відповіді, тоді процедура, скоріш за все, працюватиме.

Коротко про основне

CRA змінює сам підхід до реагування на кіберінциденти. Якщо раніше для виробника головним завданням було знайти проблему, усунути її та випустити оновлення, тепер у визначених випадках, потрібно ще й швидко повідомити про неї відповідні органи та користувачів.

Ключовими є дві категорії подій – actively exploited vulnerabilities і severe incidents. Для обох діє поетапна модель: early warning протягом 24 годин, більш детальне повідомлення протягом 72 годин і фінальний звіт після завершення основного реагування.

Тому виробнику варто заздалегідь визначити, хто відповідає за оцінку вразливостей та інцидентів, хто фіксує момент, коли компанія дізналася про подію, хто подає повідомлення та як комунікація відбувається з користувачами.

Якщо у вас залишилися питання щодо CRA, наприклад, чи поширюється він на ваші продукти, які саме обов’язки виникають для компанії або як побудувати процес роботи з вразливостями та повідомлення про інциденти, звертайтеся до Legal IT Group.

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