Cyber Resilience Act: як підготуватися до повідомлення про вразливості з 11 вересня 2026 року

11 вересня 2026 року в ЄС починають застосовуватися обов’язки Cyber Resilience Act щодо повідомлення про активно експлуатовані вразливості та серйозні інциденти. Повний набір вимог до продуктів із цифровими елементами запрацює пізніше — 11 грудня 2027 року, але процес звітування потрібен раніше. Виробникам програмного й апаратного забезпечення варто вже зараз визначити відповідальних, джерела сигналів і спосіб безпечної передачі відомостей.

CRA охоплює широкий клас цифрових продуктів

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

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

Звітувати потрібно не про кожну знайдену помилку

CRA розрізняє звичайну вразливість і вразливість, яку активно експлуатують. Активна експлуатація означає наявність надійних доказів того, що зловмисник використав уразливість у системі без дозволу власника. Лише високий бал CVSS або публічний proof of concept не завжди доводить реальну експлуатацію, хоча такі сигнали можуть суттєво підвищити пріоритет реагування.

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

Перше повідомлення має дуже короткий строк

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

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

Відлік починається з обізнаності виробника

Найскладнішим може бути не надсилання форми, а визначення моменту, коли організація «дізналася» про подію. Повідомлення може надійти через security@-адресу, bug bounty, підтримку, постачальника, публічний репозиторій або власний моніторинг. Якщо сигнали розпорошені й ніхто не відповідає за їх об’єднання, компанія ризикує втратити час ще до передачі інформації команді безпеки.

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

Єдина платформа не скасовує внутрішньої координації

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

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

Координоване розкриття не повинно зашкодити виправленню

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

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

Залежності не знімають відповідальності за продукт

Більшість цифрових продуктів містить відкриті бібліотеки, пакети постачальників, прошивки та сервіси. Вразливість у залежності не завжди робить кожен продукт експлуатованим: усе залежить від версії, конфігурації та досяжності коду. Однак виробник повинен уміти швидко визначити, де використано компонент і які збірки потрібно перевірити.

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

Підтримка має тривати заявлений період

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

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

Навчальна вправа виявить прогалини до вересня

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

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

Відкритий код має окремий режим

Безоплатне програмне забезпечення з відкритим кодом, яке розробляється або постачається поза комерційною діяльністю, загалом не охоплюється так само, як комерційний продукт. Водночас open source steward і компанія, що монетизує або інтегрує компонент у комерційну пропозицію, можуть мати визначені обов’язки. Організація не повинна автоматично записувати всю залежність із публічного репозиторію до «винятків»: потрібно оцінити власну роль, спосіб розповсюдження та економічний контекст.

Метрики повинні показувати готовність, а не обсяг листування

Корисні показники — час від першого сигналу до тріажу, час до встановлення переліку уражених версій, частка продуктів з актуальним SBOM і строк доставки виправлення. Кількість закритих заявок мало говорить про здатність вкластися в 24 години. Окремо варто вимірювати, скільки рішень неможливо швидко оцінити через невідомого власника або відсутні дані про розгортання.

Контрольний список готовності

1. Складіть реєстр продуктів, економічних операторів, версій і періодів підтримки.
2. Опублікуйте канал приймання повідомлень про вразливості та цілодобову ескалацію.
3. Визначте критерії активної експлуатації й серйозного інциденту.
4. Підготуйте шаблони раннього, 72-годинного та фінального повідомлень.
5. Зв’яжіть SBOM і дані про розгортання з процесом оцінювання впливу.
6. Узгодьте правила координованого розкриття та комунікації з користувачами.
7. Проведіть вправу до 11 вересня 2026 року й виправте виявлені прогалини.

Підготовка до звітування покращує сам продукт

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

Це загальне редакційне пояснення, а не юридична консультація. Першоджерела: огляд Cyber Resilience Act Єврокомісії, офіційний виклад регламенту, календар упровадження та текст Регламенту (ЄС) 2024/2847.