24-часовой отсчёт CRA начинается 11 сентября 2026 года: убедитесь, что кто-то возьмёт трубку

Содержание

Что именно начинается 11 сентября 2026 года?
Кто на самом деле обязан?
Почему 24-часовой срок — это задача оповещения?
Что вообще входит в 24-часовое раннее предупреждение?
Как поставить звонящий телефон перед 24-часовым отсчётом?
Шаг 1 — Заведите канал со звонком только под CRA-кандидатов
Шаг 2 — Направьте пути обнаружения на этот канал
Шаг 3 — Используйте условия, чтобы звонили только правдоподобные кандидаты
Шаг 4 — Перехватите системы, которые умеют только слать письма
Шаг 5 — Подпишите на канал всех зарегистрированных представителей
Шаг 6 — Репетируйте до 11 сентября, а не после
Чего Echobell не делает
Частые вопросы
Делает ли нас Echobell соответствующими CRA?
Когда на самом деле начинается 24-часовой отсчёт?
Мы небольшая компания. Мы освобождены?
Наш ящик по безопасности читают в рабочее время. Разве этого мало?
Могут ли комплаенс, юристы и инженеры получить одно и то же оповещение?
Помогает ли это с обязанностью информировать пользователей по статье 14(8)?
Мы уже отчитываемся по NIS2 или DORA. Это то же самое?
Действительно ли звонок пробьётся через «Не беспокоить»?
Это только для iOS?
Что класть в тело вебхука?
Читайте также

11 сентября 2026 года начинают применяться обязанности по отчётности из EU Cyber Resilience Act. С этой даты у производителя, которому стало известно об активно эксплуатируемой уязвимости в продукте с цифровыми элементами — или о серьёзном инциденте, затрагивающем такой продукт, — есть 24 часа, чтобы отправить раннее предупреждение своему координирующему CSIRT и в ENISA (Европейская комиссия, Регламент (ЕС) 2024/2847).

У этого срока есть свойство, которого лишено большинство комплаенс-сроков: он идёт по реальным часам. Никаких поправок на рабочие дни, никакой паузы на выходные и никакой отсрочки на время, пока ответственный за отчётность летит в самолёте. А платформа, через которую подаётся отчёт, — Single Reporting Platform от ENISA — это веб-форма: «на данном этапе программные интерфейсы (API) предоставляться не будут» (FAQ ENISA). Войти и отправить форму должен конкретный человек.

Из-за этого правило 24 часов сначала становится задачей оповещения и только потом — задачей документооборота. Это руководство показывает, как направить момент получения сведений в звонящий телефон с помощью Echobell, и честно называет ту большую часть подготовки к CRA, которой не касается ни один инструмент уведомлений.

Что именно начинается 11 сентября 2026 года?

Производители продуктов с цифровыми элементами обязаны сообщать об активно эксплуатируемых уязвимостях и серьёзных инцидентах через единую платформу ЕС, причём отсчёт идёт поэтапно и начинается в момент, когда им стало об этом известно. Всё остальное в CRA — маркировка CE, основные требования Приложения I, оценка соответствия — применяется с 11 декабря 2027 года. Отчётность наступает на пятнадцать месяцев раньше и распространяется на продукты, уже находящиеся на рынке, а не только на то, что вы выпустите после этой даты (cyberresilienceact.eu).

Статья 14 определяет два параллельных трека одинаковой формы:

Этап	Активно эксплуатируемая уязвимость — ст. 14(2)	Серьёзный инцидент — ст. 14(4)
Раннее предупреждение	В течение 24 часов с момента получения сведений	В течение 24 часов с момента получения сведений
Уведомление	В течение 72 часов с момента получения сведений	В течение 72 часов с момента получения сведений
Итоговый отчёт	Не позднее чем через 14 дней после того, как станет доступна корректирующая или смягчающая мера	В течение одного месяца после 72-часового уведомления

Формулировка звучит так: «без неоправданной задержки и в любом случае в течение 24 часов с момента, когда производителю стало об этом известно» (статья 14). Двадцать четыре часа — это потолок, а не цель.

Статья 14(5) задаёт планку для «серьёзного»: инцидент подпадает под неё, когда он негативно влияет — или способен негативно повлиять — на способность продукта защищать доступность, подлинность, целостность или конфиденциальность чувствительных либо важных данных или функций, а также когда он привёл или способен привести к внедрению или выполнению вредоносного кода. Слово «способен» здесь существенно: обязанность отчитаться может возникнуть раньше, чем у клиента что-то реально пойдёт не так.

Статья 14(8) добавляет вторую обязанность, которая исполняется параллельно: вы должны также проинформировать затронутых пользователей продукта об уязвимости или инциденте и, при необходимости, о корректирующих мерах, которые они могут принять. Это другая аудитория, не CSIRT, и путь до неё отдельный.

Кто на самом деле обязан?

Производители продуктов с цифровыми элементами, где бы они ни были учреждены, плюс — в более узком объёме — кураторы (stewards) открытого программного обеспечения. Компания за пределами ЕС, которая продаёт в Союз, от обязанности не уходит: регламент предполагает, что за соответствующие обязанности отвечает экономический оператор в ЕС (cyberresilienceact.eu).

Отчитываетесь вы перед CSIRT, назначенным координатором в том государстве-члене, где находится ваше основное место деятельности в Союзе, и одновременно перед ENISA, но подаёте отчёт один раз — через Single Reporting Platform, которая направит его обоим адресатам (Европейская комиссия).

Кураторы открытого ПО попадают под чётко очерченное подмножество обязанностей: требование статьи 14(1) применяется в той мере, в какой они участвуют в разработке продуктов с цифровыми элементами, а статьи 14(3) и (8) — в той мере, в какой серьёзные инциденты затрагивают сети и информационные системы, которые они предоставляют для этой разработки. Если вы курируете широко используемый проект, прочитайте статью 24 вместе со статьёй 14, вместо того чтобы исходить из одной из крайностей.

Статья 15 разрешает и добровольные сообщения — об уязвимостях, киберугрозах, инцидентах и предпосылках к инцидентам — как от производителей, так и от кого угодно ещё. Добровольные сообщения не создают новых обязанностей, но идут через ту же платформу и упираются в ту же проблему: кто-то должен не спать.

Почему 24-часовой срок — это задача оповещения?

Потому что отсчёт начинается в момент, когда вам стало известно, а известно становится редко в рабочее время. Триггер — это факт, доходящий до вашей организации, а не решение, которое она принимает.

Посмотрите, откуда обычно берётся такой факт. Исследователь безопасности пишет на security@ в субботу в 23:40. Клиент ниже по цепочке заводит тикет с описанием эксплуатации. В ленте CVE или KEV загорается компонент, который вы поставляете. Ваш собственный EDR фиксирует выполнение кода в системе сборки. Аналитическая записка DLA Piper отдельно отмечает вариант этой истории с цепочкой поставок: производители часто узнают не первыми, и информация приходит через импортёров, дистрибьюторов, исследователей или поставщиков компонентов (DLA Piper).

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

Три детали делают этот разрыв шире, чем кажется:

API нет. ENISA прямо заявляет, что на данном этапе API для подачи отчётов предоставляться не будут. Нельзя поручить скрипту подать раннее предупреждение, пока все спят.
Доступ настраивается персонально и заранее. Уполномоченные представители регистрируются с учётной записью EU Login, а назначенный CSIRT-координатор подтверждает их полномочия после первого входа. Есть основной представитель и запасной, причём приглашение для запасного истекает через семь дней (FAQ ENISA, cyberresilienceact.eu). Если единственный человек, который может подать отчёт, недоступен, сроку это безразлично.
Уровень штрафов — верхний. Статья 64 относит несоблюдение обязанностей из статей 13 и 14 к диапазону административных штрафов «до 15 000 000 евро или, если нарушитель является предприятием, до 2,5 % общего мирового годового оборота за предыдущий финансовый год — в зависимости от того, какая сумма больше» (статья 64).

Одна честная оговорка к последнему пункту, потому что для небольших команд она меняет расклад: статья 64 освобождает производителей, которые квалифицируются как микропредприятия или малые предприятия, от административных штрафов за нарушение срока из статьи 14(2)(a) или 14(4)(a) — то есть именно 24-часового раннего предупреждения. Сама обязанность отчитаться остаётся, и освобождение не распространяется ни на 72-часовое уведомление, ни на остальную часть статьи 14. Прочитайте статью и получите консультацию, а не верьте блогу в вопросе о том, куда попадает ваша компания.

Что вообще входит в 24-часовое раннее предупреждение?

Очень немногое — в этом и смысл. Руководство ENISA описывает для стадии раннего предупреждения небольшой набор обязательных полей: тип сообщения (уязвимость или инцидент), уровень сообщения, время подачи, сведения о подающем, название производителя или куратора, продукт, заголовок и — для инцидентов — есть ли подозрение на противоправные или злонамеренные действия. Среди необязательных полей на этой стадии — идентификатор CVE или EUVD.

Более полная техническая картина — общий характер уязвимости или эксплойта, первичная оценка, корректирующие и смягчающие меры — относится к 72-часовому уведомлению, а не к первым 24 часам.

То есть раннее предупреждение — не исследовательский проект, а короткая форма, которую подготовленный человек заполняет за минуты. Ограничивает вас не форма. Ограничивает то, успеет ли узнать человек, который зарегистрирован, уполномочен и не спит. Это задача маршрутизации уведомлений, и она решается уже сегодня.

Как поставить звонящий телефон перед 24-часовым отсчётом?

Echobell превращает вызов вебхука или письмо в оповещение, которое звонит и вибрирует как входящий вызов, — именно так оно проходит через «Фокусирование» и «Не беспокоить» в iOS (см. как обойти «Фокусирование» в iOS). Описанная ниже настройка дополняет ваш текущий процесс тикетов и PSIRT, а не заменяет его.

Шаг 1 — Заведите канал со звонком только под CRA-кандидатов

Создайте в приложении канал и задайте тип уведомления Звонок (типы уведомлений). Назовите его по решению, которое он запускает, а не по источнику данных: «CRA — возможно, начался 24-часовой отсчёт» лучше, чем «Оповещения безопасности».

Этот канал должен молчать. Если он звонит на каждый бюллетень, каждое неудачное сканирование и каждое обновление зависимости, отвечать на него перестанут, и вы потратите свой единственный громкий канал на шум. Направьте всё это в другое место; как делить потоки, разбирает руководство по усталости от оповещений.

Скопируйте URL вебхука из деталей канала; он выглядит как https://hook.echobell.one/t/<channel-token>. Относитесь к нему как к секрету: любой, у кого он есть, может заставить телефоны вашей команды звонить (руководство по вебхукам).

Задайте шаблоны, которые в 02:00 читаются с экрана блокировки человеком спросонья:

Заголовок: Возможный отчёт по CRA — {{product}}
Текст: {{kind}} — {{summary}} (известно с {{time}} UTC)

{{time}}, {{date}}, {{hour}} и остальные системные переменные времени всегда подставляются в UTC, поэтому у уведомления есть отметка времени, даже если отправитель её не передал. Эта отметка — не юридическое доказательство того, когда началось знание о проблеме, но полезная опора, когда вы позже восстанавливаете хронологию.

Шаг 2 — Направьте пути обнаружения на этот канал

Любая система, умеющая вызвать вебхук, может запустить канал. Отправленные поля становятся переменными шаблона:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "активно эксплуатируемая уязвимость",
    "summary": "сообщение исследователя, приложен рабочий эксплойт",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

Специальная переменная externalLink превращается в кликабельную ссылку в записи уведомления, поэтому, ответив на звонок, дежурный оказывается в одном касании от тикета с деталями.

Что стоит подключить, примерно в порядке того, как часто это оказывается первым сигналом:

Ваша очередь PSIRT или входящих обращений по безопасности — вебхук в момент, когда задаче ставят метку CRA-кандидата.
GitHub Security Advisories и оповещения Dependabot в репозиториях, где собираются поставляемые продукты (интеграция с GitHub).
Ваши SIEM, EDR или WAF — для срабатываний по инфраструктуре сборки, релизов или подписи: статья 14(5) прямо охватывает инциденты, которые могут привести к внедрению вредоносного кода.
Ленты данных об уязвимостях, которые вы и так получаете, отфильтрованные по компонентам из ваших собственных SBOM.

Шаг 3 — Используйте условия, чтобы звонили только правдоподобные кандидаты

Именно этот шаг сохраняет каналу доверие. Условия в Echobell вычисляются по тем же переменным и HTTP-заголовкам, что и шаблоны, и канал срабатывает, только когда выражение истинно:

craCandidate == true && confirmed == true

Или фильтруйте по заголовку, если отправляющая система не может задать тело запроса:

header["x-cra-severity"] == "reportable"

Ставьте порог на уровне «компетентному человеку стоит взглянуть на это в течение часа», а не «это точно подлежит отчётности». Решение о том, задействована ли статья 14, — оценочное суждение, для которого нужен человек с фактами на руках; задача канала — быстро свести этого человека с фактами. Переусердствовать с фильтрацией здесь — дорогая ошибка, потому что отчёт, который вы так и не начали, хуже звонка, который оказался не нужен.

Шаг 4 — Перехватите системы, которые умеют только слать письма

Первый контакт извне чаще всего приходит письмом: исследователь, клиент, национальный CSIRT, поставщик компонента. У каждого канала Echobell может быть собственный адрес, поэтому одно правило пересылки на security@ превращает такие письма в звонки (триггеры по email).

Триггеры по email отдают from, to, subject, text и html как переменные, так что фильтровать можно, ничего не разбирая самостоятельно:

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

Договоритесь с постоянными отправителями и ключевыми поставщиками об условной пометке в теме письма и сопоставляйте по ней. Небольшая договорная деталь, которая превращает неструктурированный почтовый ящик в маршрутизируемый сигнал.

Шаг 5 — Подпишите на канал всех зарегистрированных представителей

Поделитесь каналом со всеми, кто реально может подать отчёт: основным уполномоченным представителем, запасным и руководителем по безопасности, который может принять решение по статье 14. Каждый подписчик сам выбирает тип уведомления, поэтому дежурный может остаться на Звонке, а остальные — на Срочном.

В этом весь смысл упражнения. SRP требует зарегистрированного и подтверждённого человека. Если в компании зарегистрирован ровно один человек, у вашего 24-часового срока есть единая точка отказа с аккумулятором телефона.

Шаг 6 — Репетируйте до 11 сентября, а не после

Две репетиции, обе имеет смысл провести в этом месяце:

Путь оповещения. Отправьте приведённый выше curl с реально включённым «Не беспокоить» на том телефоне, который действительно будет лежать на тумбочке. Включите в приложении «Повторять неудавшийся звонок», чтобы сорвавшийся вызов был повторён. Непроверенный путь эскалации — это допущение.
Путь подачи. Пройдите отчёт на бумаге, опираясь на пошаговые инструкции ENISA по регистрации и подаче, которые обновлялись вплоть до августа 2026 года (ENISA SRP). Заведите учётные записи EU Login сейчас, уточните, какой CSIRT является вашим координатором, и разошлите приглашение запасному представителю заранее — оно истекает через семь дней.

У второй репетиции есть нюанс, о котором стоит знать: по состоянию на июльские рекомендации ENISA публичный URL платформы всё ещё значился как «будет предоставлен на момент запуска», поэтому сквозное тестирование вживую было ещё невозможно (cyberresilienceact.eu). ENISA обязалась ввести платформу в эксплуатацию к 11 сентября 2026 года. Отрепетируйте всё, что зависит от вас, и не превращайте готовность платформы в повод откладывать собственную.

Чего Echobell не делает

Здесь точность важнее обычного, потому что тема регуляторная:

Он не делает вас соответствующими требованиям. Echobell — канал уведомлений. Определить периметр продуктов, выстроить процесс обработки уязвимостей, решить, задействована ли статья 14, зарегистрироваться в SRP и вовремя подать отчёт — всё это на вас. Ни один инструмент оповещения ни разу не исполнил обязанность по отчётности.
Он ничего не подаёт. API для подачи нет, а если бы он был, вызывал бы его не Echobell. Он звонит на телефон; остальное делает зарегистрированный человек.
Это не юридическая отметка времени. Переменная {{time}} фиксирует, когда триггер дошёл до Echobell, в UTC. Когда началось «получение сведений» — фактический вопрос о вашей организации, и документирует его ваша карточка инцидента, а не push-уведомление.
В нём нет политик эскалации и подтверждения приёма. Нет правила «если за десять минут никто не ответил, звони следующему», нет ротаций дежурств, нет журнала того, кто и что подтвердил. Для этого нужна платформа управления инцидентами — см. альтернативы Opsgenie.
Он не может гарантировать доставку. Звонок зависит от push-инфраструктуры, сети и заряженного телефона. Считайте его слоем, который сокращает разрыв между приходом факта и осведомлённостью человека, а не мерой контроля, на которую можно показать при аудите.
Он не учитывает местное время. Встроенные переменные времени работают только в UTC и не следуют за переходом на летнее время. Условия, ограничивающие временное окно, приходится вручную поправлять дважды в год.

Частые вопросы

Делает ли нас Echobell соответствующими CRA?

Нет. CRA возлагает обязанности на производителей, и ни одно приложение для уведомлений их не исполнит. Echobell закрывает один конкретный сценарий отказа: 24-часовое раннее предупреждение пропущено, потому что человек, который мог его подать, узнал обо всём только на следующий рабочий день. Это реальный и частый сценарий, но он лишь часть куда большей программы соответствия.

Когда на самом деле начинается 24-часовой отсчёт?

Когда производителю становится известно об активно эксплуатируемой уязвимости или серьёзном инциденте. Регламент не определяет точный момент, а осведомлённость зависит от фактов и от того, как быстро их удаётся установить (DLA Piper). На практике это аргумент в пользу быстрой и задокументированной первичной оценки: чем больше разрыв между приходом сигнала и его разбором, тем сложнее объяснить его потом.

Мы небольшая компания. Мы освобождены?

От отчётности — нет. Статья 64 освобождает микропредприятия и малые предприятия от административных штрафов именно за пропуск 24-часового срока из статьи 14(2)(a) или 14(4)(a). Обязанность отчитаться сохраняется, 72-часовое уведомление и итоговый отчёт этим не затронуты, а определения микропредприятия и малого предприятия — не то, о чём стоит догадываться. Считайте это узким смягчением, а не пропуском.

Наш ящик по безопасности читают в рабочее время. Разве этого мало?

Достаточно только в том случае, если вы готовы потерять до двух третей окна на обычных выходных. Сообщение, пришедшее в пятницу в 18:00, оставляет вам срок до 18:00 субботы. Мониторинг в рабочее время — нормальная настройка по умолчанию для всего остального; 24-часовой отсчёт — ровно тот случай, который она не покрывает.

Могут ли комплаенс, юристы и инженеры получить одно и то же оповещение?

Да, и должны. Поделитесь одним каналом — и по одному и тому же триггеру уведомление получит каждый подписчик, сам выбрав себе срочность. Инженер, подтверждающий факт эксплуатации, и человек, который будет отправлять форму, должны начать в одну и ту же минуту, а не по очереди.

Помогает ли это с обязанностью информировать пользователей по статье 14(8)?

Косвенно. Статья 14(8) требует информировать затронутых пользователей об уязвимости или инциденте и, при необходимости, о корректирующих мерах. Это коммуникация с клиентами, и для неё нужны ваши собственные каналы. Echobell может разбудить тех, кто отвечает за эту коммуникацию, одновременно с теми, кто отвечает за подачу отчёта, чтобы оба направления стартовали вместе.

Мы уже отчитываемся по NIS2 или DORA. Это то же самое?

Нет, хотя формы похожи. NIS2 и DORA возлагают обязанности на организации исходя из сектора и критичности; CRA возлагает обязанности на производителей исходя из продуктов, которые они выводят на рынок ЕС. Одна организация может подпадать под все три режима — с разными отсчётами и разными адресатами. Если эти режимы касаются и вас, см. оповещения об инцидентах по DORA и NIS2 — и учтите, что слой оповещения можно сделать общим, даже когда обязанности общими не являются.

Действительно ли звонок пробьётся через «Не беспокоить»?

Уведомления типа «Звонок» доставляются как оповещения в виде вызова, и именно это позволяет им пробиваться через «Фокусирование» в iOS. Магии тут нет: всё равно всё зависит от системных настроек, сети и заряженного телефона. Проверьте это на реальном устройстве, с реально включённым «Фокусированием», прежде чем на него полагаться, — и включите «Повторять неудавшийся звонок».

Это только для iOS?

Нет. Echobell есть для iOS и для Android в Google Play (релиз для Android). Поведение оповещений в виде вызова на разных платформах различается, поэтому тестируйте на том устройстве, которое дежурный действительно носит с собой.

Что класть в тело вебхука?

Минимум, которого хватит для решения, вставать или нет: продукт, вид сигнала, одну строку контекста и externalLink на тикет с подробностями. Echobell хранит содержимое и историю уведомлений на устройстве, а на сервере — только аккаунты, каналы и подписки (модель приватности), но правильная привычка при работе с чувствительными материалами по безопасности всё равно одна: отправлять указатель, а не содержимое.