Отчётность по Cyber Resilience Act уже действует: что построить до того, как пойдёт первый 24-часовой отсчёт

Производители продуктов с цифровыми элементами (это и отдельное ПО, и подключённое оборудование) с 11 сентября 2026 года обязаны сообщать о двух вещах: об активно эксплуатируемых уязвимостях в своих продуктах и о серьёзных инцидентах, затрагивающих безопасность продукта. Так устроена статья 14 Регламента (ЕС) 2024/2847. Остальные требования Cyber Resilience Act, включая базовые требования, оценку соответствия и штрафы, начнут применяться с 11 декабря 2027 года.

Отчётность пришла на пятнадцать месяцев раньше всего остального.

Три детали в сфере применения ловят команды врасплох. Обязанность распространяется на каждый продукт в сфере действия закона, а не только на «важные» и «критические» (Eversheds Sutherland, 10 сентября 2026 года). Она касается и устаревших продуктов, которые уже были на рынке ЕС, и сохраняется после окончания периода поддержки продукта. Обратной силы нет: об эксплуатации, которая была вам известна до 11 сентября 2026 года, сообщать не нужно, а вот о новой эксплуатации той же уязвимости нужно (Hogan Lovells, 11 сентября 2026 года).

Мы инженеры, не юристы. Попадает ли ваш продукт под регламент, уточните у юриста. Для белорусской компании это не формальность: если продукт продаётся пользователям в ЕС, вы тоже производитель в смысле регламента. Здесь разбираем, что должно появиться в ваших системах, когда вопрос о сфере решён.

Отсчёт начинается, когда вы узнали об активной эксплуатации. Раннее предупреждение нужно в течение 24 часов, уведомление с описанием эксплойта и принятых мер исправления в течение 72 часов, итоговый отчёт не позднее 14 дней после появления исправления или меры по снижению риска. По серьёзным инцидентам итоговый отчёт подаётся через месяц после уведомления, поданного на 72-м часу (статья 14(2) и (4); Crowell, 11 сентября 2026 года).

Читайте эти сроки как инженерные задачи. За 24 часа нужно знать, какой продукт и какие версии затронуты и в каких государствах-членах они продаются. Это вопрос инвентаризации, и в два часа ночи по памяти на него никто не ответит. К 72 часам регулятору нужно описание уязвимости и то, что могут сделать пользователи. Это разбор уязвимости плюс мера защиты, пусть даже флаг в конфигурации. Для итогового отчёта за 14 дней нужны критичность, влияние и детали исправления, так что заметки к релизу и запись CVE должны к тому времени уже существовать.

Статья 14(8) добавляет обязанность, о которой большинство команд забывает: затронутых пользователей нужно уведомить об уязвимости и мерах защиты в структурированном машиночитаемом формате. Если производитель медлит, координирующая группа CSIRT может проинформировать пользователей сама (Eversheds Sutherland). Мы бы предпочли написать это уведомление сами.

Единая платформа отчётности (SRP) означает, что вы подаёте отчёт один раз. Уведомление уходит в CSIRT, назначенный координатором (как правило, в государстве-члене, где находится ваше основное предприятие в ЕС), и одновременно становится доступным ENISA; координатор пересылает его в CSIRT всех остальных стран, где продаётся продукт (ENISA, 11 сентября 2026 года). На практике из этого следует, что отчёт подаёт человек, а не команда. В SRP эта роль называется Assigned Representative (AR): один основной и до 20 дополнительных, у каждого своя учётная запись EU Login с многофакторной аутентификацией (Crowell; Help Net Security, 14 сентября 2026 года).

Несколько ограничений запуска определяют, какие инструменты нужны. API у платформы на старте не было, поэтому отчёты вводятся в веб-форму. На одно событие допускается только одно уведомление, даже если затронуто несколько линеек продуктов. Платформа запустилась только на английском. Неверно выбранный координирующий CSIRT может сделать отчёт недействительным и заставить подавать его заново.

По данным Crowell, ENISA не советует регистрироваться как производитель, пока вам нечего сообщать, а Eversheds отмечает, что регистрация занимает считаные минуты, после чего CSIRT проверяет AR. Откладывать нельзя учётную запись EU Login с MFA на телефоне, который дежурный действительно носит с собой. Мы завели двух именованных AR в разных часовых поясах и поставили в календарь дежурств ежеквартальную проверку входа.

Четыре вещи: SBOM, который создаётся при каждой релизной сборке; задача, сопоставляющая его с лентами уязвимостей; этап триажа, где решают, эксплуатируется ли совпадение в вашем продукте; и журнал доказательств с метками времени. Формальная обязанность по SBOM (приложение I, часть II) действует только с 11 декабря 2027 года и требует как минимум зависимостей верхнего уровня в распространённом машиночитаемом формате; хранится он в технической документации и не публикуется (Anchore, обновлено 7 октября 2026 года). Но без него уже сегодня не ответить на вопрос первых 24 часов: какие версии затронуты.

По умолчанию мы генерируем CycloneDX JSON в CI. CycloneDX 1.7 вышел 21 октября 2025 года и остаётся актуальной спецификацией. SPDX тоже подойдёт; выберите один формат и держитесь его. SBOM хранится для каждого релизного тега, потому что после уведомления об уязвимости всегда спрашивают «в каких из поставленных версий это есть», а ветка main на него не ответит.

Минимум верхнего уровня тоньше, чем кажется. Когда мы пересчитали собственный корпоративный сайт (приложение на Laravel), в composer.json нашлось 6 рантайм-пакетов, а в composer.lock зафиксировано 80. На фронтенде 12 прямых dev-зависимостей и 254 записи в package-lock.json. SBOM верхнего уровня показал бы примерно один PHP-пакет из тринадцати. Мы записываем всё дерево: юридический минимум плохо подходит как инженерный.

Сопоставление дешёвое: composer audit, pip-audit, npm audit или OSV-Scanner по сохранённому SBOM, ночью, по каждому поддерживаемому релизу, а не только по main. Каталог CISA Known Exploited Vulnerabilities даёт полезный сигнал об эксплуатации. По сторонней оценке, на 2 октября 2026 года в нём было 1 733 записи, из них 249 добавлены в 2026 году, уже больше, чем 245 за весь 2025-й (The Uptime Report). Но попадание в KEV не доказывает, что эксплуатируют именно ваш продукт. Hogan Lovells так читает руководство Еврокомиссии: при уязвимости в стороннем компоненте производитель сообщает, только если её активно эксплуатируют в его собственном продукте.

Это последнее суждение самое дорогое, и принимает его человек. Мы назначаем на него дежурного владельца и фиксируем письменное определение: надёжные доказательства эксплуатации злоумышленником (так формулировку регламента пересказывает Eversheds).

Продукт, проданный в 2023 году и снятый с поддержки в 2025-м, всё равно подлежит отчётности, если об эксплуатации стало известно после 11 сентября 2026 года. Для команд, у которых в эксплуатации остались старые релизы на PHP или Python, это меняет цену мёртвой ветки. Исправлять её, возможно, не обязательно, но вы должны уметь сказать, у каких клиентов она работает, и уведомить их.

Из-за EOL-рантаймов задача сопоставления шумит сильнее: ленты уязвимостей перестают указывать исправленные версии для веток, которые никто не патчит, и сканер сообщает о находке без пути обновления. Решение «на этой ветке исправления нет» мы отдаём владельцу продукта и записываем в журнал доказательств. Обычно оно же становится поводом для разговора об обновлении, который мы описали в статье «Legacy PHP: обновить, вытеснять по частям или переписать».

У стюардов открытого ПО (фондов и похожих организаций, которые поддерживают open source-проекты, используемые в коммерческих продуктах) собственные обязанности по отчётности появятся с 11 декабря 2027 года (ENISA). До тех пор мейнтейнер библиотеки, от которой вы зависите, перед SRP ничего не должен. А вы должны, если уязвимость эксплуатируют в вашем продукте.

Runbook делает две вещи: фиксирует метку времени «узнали» в тот момент, когда дежурный владелец подтвердил эксплуатацию, и превращает запись триажа в черновик, который AR вставит в форму SRP. Раз у платформы нет API, автоматизация заканчивается черновиком для вставки вручную.

from datetime import datetime, timezone, timedelta
from dateutil.relativedelta import relativedelta

def cra_clock(aware_at, kind, fix_at=None, notified_at=None):
    d = {"early_warning": aware_at + timedelta(hours=24),
         "notification": aware_at + timedelta(hours=72)}
    if kind == "vulnerability" and fix_at:
        d["final_report"] = fix_at + timedelta(days=14)
    if kind == "incident" and notified_at:
        d["final_report"] = notified_at + relativedelta(months=1)
    return d

def early_warning(t):  # t: запись триажа из тикета
    return (f"Product: {t['product']} {', '.join(t['versions'])}\n"
            f"Exploitation evidence: {t['evidence']}\n"
            f"Member States: {', '.join(t['markets'])}\n"
            f"Aware at (UTC): {t['aware_at']:%Y-%m-%d %H:%M}")

Текст черновика остаётся английским: платформа принимает только английский. Список markets берётся из базы продаж или лицензий, а не из памяти инженера. Сроки попадают в тикет инцидента как даты исполнения, а оповещения приходят на 50% и 80% каждого окна. aware_at храните в UTC. 24-часовое окно не учитывает переход на летнее время, а координирующий CSIRT может находиться в двух часовых поясах от вашего дежурного инженера.

С учётных записей EU Login и списка рынков. Это дело одного дня, а без них самый полный SBOM в мире всё равно не уложится в 24 часа. Работа над конвейером идёт второй, а разовый аудит релизов, которые ещё работают у клиентов, третьей. Если вы выпускаете ещё и ИИ-функции, обязанности по прозрачности живут по отдельному графику; мы разобрали их в статье «EU AI Act после Omnibus». А серверам инструментов для агентов нужна та же дисциплина инвентаризации, что описана в «MCP-серверы в продакшене».

Мы проводим двухнедельный аудит готовности к CRA для конвейера поставки: генерация SBOM, сопоставление с уязвимостями по поддерживаемым релизам и runbook отчётности, который ваш AR отрепетировал хотя бы раз. Подробности на странице услуг по безопасности или напишите нам.