EU Cyber Resilience Act: что поставили клиентам и когда узнали об уязвимости
С 11 сентября 2026 года для производителей цифровых продуктов в Евросоюзе начнут действовать ключевые требования EU Cyber Resilience Act vulnerability reporting requirements. Если компания узнает, что уязвимость в ее продукте активно эксплуатируется, уведомление ENISA придется направить не позднее чем через 24 часа. Расширенный отчет должен последовать в течение 72 часов.
Именно поэтому главный вопрос нового регулирования звучит не только как "насколько защищен продукт?". Гораздо важнее понять, что именно было выпущено, в какие версии оно попало и когда компания впервые получила информацию о проблеме. Для многих организаций это окажется значительно сложнее, чем формальное заполнение уведомления.
В требованиях EU CRA 24 hour vulnerability reporting критично каждое звено цепочки: обнаружение инцидента, его проверка, определение затронутых компонентов, установление списка поставленных версий и фиксация времени принятия решения. Если сведения хранятся в разрозненных системах, а состав релизов невозможно быстро восстановить, даже добросовестная компания рискует нарушить сроки.
Уроки открытого кода
Показательный случай произошел с одним из проектов свободного программного обеспечения, к проверке которого был привлечен архитектор ActiveState Шейн Уорден. На официальный адрес для сообщений о безопасности поступил отчет с 95 предполагаемыми уязвимостями. Письмо было оформлено корректно: использовалась GPG-подпись, соблюдались правила ответственного раскрытия, а информация была направлена ограниченному кругу специалистов.
Однако масштаб документа вызвал сомнения. На практике исследователь обычно описывает несколько подтвержденных проблем, а затем обсуждает дальнейший аудит. В этом случае большая часть заявлений оказалась недостоверной: реальными были лишь две или три уязвимости. Но команде все равно пришлось проверить весь список, чтобы отделить факты от ошибок.
Затем последовало второе письмо с требованием выплатить 100 тысяч долларов. В противном случае автор угрожал публичным раскрытием данных и масштабной информационной кампанией. Хотя сам отчет оказался сильно преувеличен, потенциальный ущерб был настоящим: публикация сведений могла затронуть каждую установку уязвимого продукта, доступную для обнаружения через интернет-сканирование.
Такие ситуации показывают, почему EU CRA vulnerability reporting compliance начинается задолго до контакта с регулятором. Организация должна иметь доказуемую историю: какие компоненты присутствовали в каждом выпуске, какие сборки получили пользователи, кто и когда сообщил о проблеме, а также в какой момент появилась уверенность в ее активной эксплуатации.
Сначала - прозрачность, затем инженерные требования
С 11 сентября 2026 года обязанности по уведомлению станут юридически обязательными для производителей продуктов с цифровыми элементами, которые продаются на рынке ЕС. При подтверждении активной эксплуатации необходимо будет сообщить об уязвимости в течение суток, а более детальную информацию предоставить в течение 72 часов.
При этом требования, определяющие, как именно компании должны проектировать, разрабатывать и сопровождать продукты, начнут применяться позднее - 11 декабря 2027 года. Таким образом, между запуском обязательной отчетности и полноценным вступлением инженерных норм в силу появится значительный переходный период.
Эту ситуацию можно описать как временный акцент на наблюдаемости. В первые месяцы Cyber Resilience Act software vendor compliance будет во многом зависеть от способности компании быстро ответить на вопросы о собственных поставках и уязвимостях. Наличие безопасного процесса разработки важно, но без точного учета релизов оно не гарантирует соблюдения закона.
Подробный разбор того, почему регулятору особенно важно знать состав поставленного продукта и момент обнаружения угрозы, представлен в материале о практических требованиях ЕС к отчетности об уязвимостях. Для многих компаний это не отвлеченный юридический вопрос, а задача инвентаризации, управления релизами и внутренними коммуникациями.
Почему SBOM не решает проблему полностью
Похожий переход организации уже проходили после указа США Executive Order 14028, который сделал программные ведомости состава - SBOM - обязательным элементом для ряда поставщиков федерального сектора. Тогда многие компании обнаружили, что знают названия своих продуктов, но не всегда могут точно определить, какие библиотеки и версии вошли в конкретную сборку.
SBOM помогает установить состав программного обеспечения, однако сам по себе не отвечает на все вопросы CRA. Важно связать перечень компонентов с конкретным артефактом, датой публикации, каналом распространения и группой пользователей. Дополнительно требуется понимать, когда команда получила сведения об угрозе и какие действия предприняла после этого.
Особенно сложной будет ситуация для компаний, использующих большое количество сторонних библиотек, контейнеров, пакетов с открытым исходным кодом и автоматических зависимостей. Обновление одного компонента может незаметно изменить содержимое продукта, а данные о сборке могут остаться в системе CI/CD, репозитории артефактов или переписке отдельных команд.
Что стоит подготовить заранее
Производителям следует сформировать единый реестр релизов и компонентов, связанный с системами контроля исходного кода, сборки и распространения. Для каждой версии желательно сохранять не только SBOM, но и хеши артефактов, дату публикации, список изменений и сведения о том, каким клиентам или каналам она была доступна.
Не менее важна процедура обработки сообщений о безопасности. Она должна фиксировать момент получения уведомления, статус проверки, ответственных сотрудников, результаты анализа и время, когда была подтверждена активная эксплуатация. Без такой временной шкалы доказать соблюдение EU CRA actively exploited vulnerabilities reporting будет трудно.
Отдельное внимание нужно уделить взаимодействию с поставщиками. Если проблема обнаружена в сторонней библиотеке, компания все равно должна быстро определить, какие собственные продукты затронуты. Договоры и внутренние регламенты должны предусматривать оперативную передачу информации, единые форматы уведомлений и понятные сроки эскалации.
В конечном счете Cyber Resilience Act переводит неформальную практику сопровождения открытого кода в плоскость обязательного корпоративного процесса. Вопрос "что мы поставили и когда узнали о проблеме?" станет проверкой зрелости управления продуктом. Чем раньше организации научатся отвечать на него точно и документально, тем ниже будет риск пропустить 24-часовой срок и столкнуться с последствиями несоблюдения новых правил.
