С 11 сентября 2026 года производители цифровых продуктов для рынка ЕС уже обязаны сообщать об активно эксплуатируемых уязвимостях и серьёзных инцидентах. Поэтому готовность к CRA — это не папка с политиками для аудитора, а состояние репозитория, CI/CD и процесса релизов. Для русскоязычных команд, которые продают софт, железо с прошивкой или SaaS европейским клиентам, это неприятная, но полезная проверка инженерной взрослости.
Cyber Resilience Act часто обсуждают как юридическую и отчётную историю, но реальная работа начинается ближе к разработчикам, сообщает The New Stack. В заметке Екатерины Окуневой из Sonar акцент сделан на простом тезисе: организация не сможет убедительно отчитаться об инциденте, если до этого не умеет быстро ответить на базовые вопросы о коде, зависимостях, сборках, тестах и выпуске продукта.
CRA, официально Regulation (EU) 2024/2847, вступил в силу 10 декабря 2024 года. Основные требования начнут применяться 11 декабря 2027 года, но отчётность по уязвимостям и серьёзным инцидентам заработала раньше — с 11 сентября 2026 года. Закон касается не только европейских компаний: если продукт с цифровыми элементами выводится на рынок ЕС, регулятору в целом всё равно, где сидит команда разработки — в Берлине, Тбилиси, Белграде, Алматы или Москве.
Ключевой сдвиг в том, что безопасность продукта перестаёт быть финальным чек-листом перед релизом. CRA требует доказуемости: что изменилось, кто внёс изменение, какие зависимости использованы, какие проверки прошли, почему релиз был одобрен и как команда узнает, что уязвимость реально затрагивает продукт. Если ответы живут в головах двух senior-разработчиков и одном чате, это не процесс, а надежда на хорошую память. А память, как известно, плохо масштабируется и не проходит аудит.
На уровне инженерной практики готовность к CRA означает встроенные контроли: проверку изменений в pull request, анализ зависимостей, трассируемые build-пайплайны, автоматические security-тесты, правила для релизных gate, журнал решений по уязвимостям и понятную связь между версией продукта и исходным кодом. Всё это звучит скучно ровно до первого эксплуатируемого CVE в библиотеке, которую никто не помнит, но которая внезапно оказалась в трёх поставляемых сборках.
Отдельная тема — код, написанный или дописанный AI-инструментами. По данным опроса Sonar State of Code Developer Survey, на который ссылается материал, 96% разработчиков не полностью доверяют AI-generated code, но только 48% всегда проверяют такой код перед коммитом. Разрыв выглядит особенно нервно на фоне агентной разработки: генерация ускоряется, а ответственность за результат никуда не исчезает. Регулятору будет всё равно, написал уязвимый фрагмент человек, Copilot-подобный ассистент или агент, который «почти всё сделал сам».
Для разработчиков это не обязательно означает ещё один слой бюрократии поверх Jira. Хороший вариант — сделать контроль частью привычного пути к релизу. Например, ввести обязательную привязку изменений к компонентам продукта, автоматизировать проверку известных уязвимостей в зависимостях, хранить результаты тестов и сканов рядом с артефактами сборки, фиксировать исключения и причины отклонения исправлений. Важный критерий простой: если завтра нужно объяснить, затронута ли конкретная версия продукта конкретной уязвимостью, команда должна получить ответ за часы, а не за неделю раскопок.
Для бизнеса вывод ещё менее романтичный. CRA превращает качество инженерных процессов в коммерческий фактор: закупки, партнёры и enterprise-клиенты будут спрашивать не только про функции и SLA, но и про уязвимости, поддержку, обновления и доказательства контроля цепочки поставки. Особенно это касается вендоров, которые поставляют SDK, embedded-компоненты, desktop-приложения, IoT-устройства, промышленное ПО или облачные сервисы с клиентскими агентами. Если продукт попадает в европейскую цепочку поставки, разговор о compliance придёт сам — обычно не в самый удобный момент.
Следующий год покажет, какие компании воспримут CRA как ещё один отчёт для юристов, а какие используют его как повод наконец разобрать залежи зависимостей, релизных исключений и «временных» обходных путей в CI. Регуляторная дата уже наступила для отчётности, а до полной применимости требований остаётся чуть больше года. Вопрос теперь не в том, нужна ли готовность к CRA, а в том, сможет ли ваша команда доказать её без героического ручного расследования при каждом инциденте.