От регламента к репозиторию: чего Закон ЕС о киберустойчивости требует от инженерных команд

Kilo Code, ныне входящая в состав Anaconda, переводит требования CRA в системы и рабочие процессы, которые разработчикам необходимо внедрить.

Когда Kilo Code присоединилась к Anaconda, она принесла с собой нечто большее, чем просто агент для написания кода с открытым исходным кодом и поддержкой различных моделей. Она принесла сообщество, сосредоточенное на практической работе по созданию, поддержке и защите программного обеспечения.

Эта перспектива имеет решающее значение в связи с тем, что сегодня наступает первый крайний срок в рамках Закона Европейского союза о киберустойчивости (CRA). Недавно компания Kilo опубликовала ориентированный на разработчиков анализ этого нормативного акта, написанный Аркадием Кондрашовым и Патриком Наком-Леманом. Его основная мысль проста: большая часть руководств по CRA написана для тех, кто отвечает за комплаенс, но значительная часть работы по реализации ляжет на плечи инженерных команд и специалистов по безопасности.

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

В этой статье регламент и руководства Европейской комиссии переводятся на язык практических задач для тех, кто выпускает код.

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

Две даты, которые должны знать инженерные команды

CRA вступил в силу в декабре 2024 года, но его требования применяются поэтапно:

• 11 сентября 2026 года (сегодня): Производители обязаны начать сообщать об активно эксплуатируемых уязвимостях и серьезных инцидентах, влияющих на безопасность продуктов с цифровыми элементами.
• 11 декабря 2027 года: Вступают в силу остальные требования CRA, включая основные требования кибербезопасности, обработку уязвимостей, оценку соответствия и маркировку CE.

График реализации Европейской комиссии учитывает эти этапы, а также стандарты и рекомендации, находящиеся в разработке.

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

Сначала определите, применим ли CRA к вашему продукту

Для программного обеспечения отправной точкой является место его выполнения. ПО, запуск которого происходит на устройстве пользователя, может считаться «продуктом с цифровыми элементами». К примерам относятся загружаемые приложения, локально установленные клиенты, интерфейсы командной строки, расширения для браузеров, мобильные приложения и прошивки.

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

Автономные облачные сервисы, созданные вне сферы ответственности производителя продукта, как к таковые обычно находятся за рамками действия CRA; к ним могут применяться другие правила, включая NIS2. Следовательно, называть компанию «SaaS» само по себе не означает освобождения от ответственности. Компания, которая также поставляет установщик, агент, интерфейс командной строки (CLI), приложение или подключенное устройство, может считаться производителем по меньшей мере для одного продукта.

Роль организации также имеет значение. CRA проводит различия между производителями, импортерами, дистрибьюторами, хранителями ПО с открытым исходным кодом и участниками разработки. Одна и та же организация может выполнять разные роли для разных продуктов.

Публикация бесплатного ПО с открытым исходным кодом в публичном репозитории или менеджере пакетов сама по себе обычно не означает вывод продукта на рынок. Взимание платы за программное обеспечение, монетизация связанных с ним услуг или обусловление его использования обработкой персональных данных могут изменить эту оценку. Репозиторий или менеджер пакетов, который исключительно размещает стороннее ПО, представляет собой отдельный случай и, как правило, не выводит это ПО на рынок.

Руководство Европейской комиссии по CRA от июля 2026 года охватывает вопросы сферы применения, бесплатного ПО с открытым исходным кодом, удаленной обработки данных, периодов поддержки, отчетности и существенных модификаций на примере 67 практических кейсов.

Вы несете ответственность за уязвимости в коде, который не писали

Это требование с наибольшей вероятностью изменит повседневную работу инженеров.

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

Когда производитель обнаруживает уязвимость в интегрированном компоненте, включая компонент с открытым исходным кодом, CRA требует нечто большее, чем просто внутреннее исправление. Согласно статье 13(6), производитель обязан сообщить об уязвимости лицу или организации, производящим или поддерживающим этот компонент, а также устранить ее в соответствии с требованиями к обработке уязвимостей, изложенными в Приложении I, Часть II. Если производитель разработал модификацию, устраняющую уязвимость в компоненте, он должен поделиться соответствующим кодом или документацией с мейнтейнером, где это уместно, в машиночитаемом формате. Руководство Комиссии поясняет, что уведомление вышестоящих разработчиков не требуется, если мейнтейнер уже знает об уязвимости или мейнтейнер отсутствует, а обязанность связана с версией, фактически интегрированной в продукт.

Современные программные продукты сильно зависят от стороннего кода. Согласно CRA, производители могут нести ответственность за эти компоненты даже тогда, когда они не могут напрямую исправить исходный код. Это делает видимость зависимостей, анализ достижимости, документированную приоритизацию, устранение уязвимостей и координацию с разработчиками вышестоящего ПО частью внедрения комплаенса.

Некоторые уязвимости запускают 24-часовой отсчет

Обязательства CRA по отчетности вступают в силу сегодня. Существуют два триггера для отчетности.

Активно эксплуатируемая уязвимость

Регламент определяет активно эксплуатируемую уязвимость в статье 3(42) как уязвимость, в отношении которой имеются надежные доказательства того, что злоумышленник эксплуатировал ее в системе без разрешения ее владельца.

Опубликованный концепт-эксплойт сам по себе не соответствует этому критерию. Как и высокий балл по шкале CVSS (Common Vulnerability Scoring System). Уязвимость также должна присутствовать в продукте, выведенном на рынок.

Руководство Комиссии поясняет, что уязвимость в стороннем компоненте не подлежит обязательной отчетности, если ее невозможно проэксплуатировать в продукте, например, когда уязвимый код недоступен при том способе, которым используется компонент.

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

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

Эта категория шире, чем просто проэксплуатированная уязвимость в программном обеспечении. Скомпрометированный конвейер сборки или канал выпуска может сам по себе быть серьезным инцидентом. Если злоумышленник мог изменить то, что попадает к клиентам, безопасность продукта могла пострадать, даже если никакая конкретная уязвимость продукта не эксплуатировалась.

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

• Первичное предупреждение без неоправданной задержки и не позднее чем через 24 часа после получения информации.
• Более полное уведомление без неоправданной задержки и не позднее чем через 72 часа после получения информации.
• Для активно эксплуатируемой уязвимости — итоговый отчет не позднее чем через 14 дней после появления исправления или меры по снижению рисков.
• Для серьезного инцидента — итоговый отчет не позднее чем через один месяц после 72-часового уведомления.

Обзор отчетности Комиссии подтверждает эти сроки. Периоды в 24 и 72 часа являются максимальными пределами, а не целевым временем реагирования.

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

«Осведомленность» зависит от оперативной триажи

Отсчет времени для отчетности начинается с момента, когда производитель узнает о событии, а не тогда, когда кто-то в конечном итоге решит заняться расследованием алерта.

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

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

На практике командам необходимы три возможности:

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

Процесс отчетности должен работать уже сегодня

Производители отчитываются единожды через единую платформу отчетности (SRP) ENISA. Платформа направляет отправленные данные в соответствующую национальную группу реагирования на компьютерные инциденты (CSIRT) и, за исключением определенных исключительных обстоятельств, делает их доступными для ENISA одновременно с этим.

Соответствующим CSIRT, как правило, является орган в том государстве-члене, где у производителя находится основное место деятельности. Согласно статье 14(7), это государство-член, в котором преимущественно принимаются решения по кибербезопасности продуктов производителя, что не обязательно совпадает с местом нахождения штаб-квартиры компании. Если это невозможно определить, это государство-член, в котором у производителя наибольшее число сотрудников в Союзе. Для производителей, не имеющих основного места деятельности в ЕС, CRA устанавливает порядок на основе местонахождения уполномоченного представителя, импортера, дистрибьютора и, в конечном счете, наибольшего числа пользователей.

Единая платформа отчетности должна начать работу с сегодняшнего дня, то есть с даты вступления в силу требований к отчетности. ENISA опубликовала вспомогательные материалы непосредственно перед запуском: список CSIRT, назначенных координаторами для всех 27 государств-членов, глоссарий SRP по полям, а также руководство по регистрации и интерфейсу. К настоящему моменту команды должны иметь наготове те организационные элементы, которые невозможно без спешки собрать в течение 24-часового окна реагирования:

• Создайте учетную запись EU Login прямо сейчас. ENISA рекомендует организациям регистрироваться на самой SRP только тогда, когда им потребуется отправить уведомление. Проверка назначенного представителя со стороны CSIRT происходит параллельно с подачей отчета и не блокирует отправку.
• Заранее подготовьте данные о юридическом лице, продукте, представителе и контактные данные, которые потребуются для подачи заявления. Глоссарий SRP от ENISA определяет поля отправки индивидуально, поэтому это можно подготовить на основе реальной формы, а не приблизительно.
• Планируйте ручной ввод через портал. ENISA подтвердила, что первоначальный релиз не предоставляет API для отчетности.
• Определите назначенный CSIRT по опубликованному ENISA списку координаторов и решите, кто имеет полномочия на подачу документов.
• Назначьте основного уполномоченного представителя и запасного. Обратите внимание, что «назначенный представитель» по версии ENISA — это роль для входа на платформу, а не уполномоченный представитель, назначенный в соответствии со статьей 18. В руководстве ENISA по регистрации используется модель основного и вторичного представителей, причем приглашения для вторичных представителей истекают через семь дней.

Двусмысленность в вопросах эскалации и полномочий на подачу документов может поглотить большую часть 24-часового окна. Внесите эти решения в регламент реагирования на инциденты прямо сейчас, если их там еще нет.

Определите, что означает «без задержки» для устранения уязвимостей

Более широкие требования к обращению с уязвимостями применяются с 11 декабря 2027 года к продуктам, размещенным на рынке начиная с этой даты. Согласно статье 69(2), продукт, размещенный на рынке ранее, как правило, подпадает под действие этих требований только в том случае, если он существенно модифицирован после этой даты.

CRA требует от производителей устранять уязвимости без задержки в зависимости от создаваемых ими рисков, в том числе путем предоставления обновлений безопасности (Приложение I, Часть II, пункт 2). Там, где это технически возможно, такие обновления безопасности должны распространяться отдельно от обновлений функционала.

Регламент не устанавливает универсального количества дней для формулировки «без задержки». Это не отменяет необходимости установления измеримых внутренних сроков. Оценщик может проверить, установила ли организация политику устранения уязвимостей на основе рисков, следовала ли ей и сохранила ли доказательства.

Руководители инженерных подразделений и служб безопасности должны определить сроки по степени серьезности, пути эскалации, обработку исключений и доказательства, сохраняемые для каждого решения. Такая политика, как 15 дней для критических уязвимостей и 30 дней для уязвимостей высокой степени серьезности, может быть оправданной только в том случае, если она соответствует риску, последовательно соблюдается и документируется. Неписаное намерение действовать быстро не является оперативным контролем.

Отделение обновлений безопасности от релизов новых функций — это также не просто вопрос предпочтений в составлении графиков. Это затрагивает архитектуру, процессы релизов и жизненный цикл оценки соответствия продукта.

Патчи безопасности обычно не требуют повторной оценки соответствия

Иногда команды откладывают исправления безопасности из-за опасений, что обновление будет сочтено «существенным изменением», в результате чего продукт будет рассматриваться как впервые выпущенный на рынок и потребует проведения еще одной оценки соответствия.

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

Соответствующим критерием является не размер или сложность изменения. В статье 3(30) существенное изменение определяется как изменение, которое влияет на соответствие продукта основным требованиям, изложенным в Приложении I, Часть I, или изменяет предполагаемое назначение, для которого оценивался продукт. Руководство Комиссии формулирует практический вопрос следующим образом: оказывает ли изменение потенциальное неблагоприятное воздействие на профиль рисков кибербезопасности, которое не было учтено в первоначальной оценке.

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

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

В некоторых случаях производители могут устранять проблемы в новых версиях (fix forward)

CRA в статье 13(10) позволяет производителю, выпустившему на рынок более позднюю, существенно измененную версию программного продукта, выполнять требования по устранению уязвимостей только для последней версии при соблюдении определенных условий. Пользователи более ранних версий должны иметь возможность получить последнюю версию бесплатно и без дополнительных затрат на настройку аппаратной или программной среды, в которой она работает.

Это не дает карт-бланш на отказ от старых релизов. Это положение связано с существенным изменением, и каждая версия, выпущенная на рынок, имеет собственный заявленный период поддержки. Выпуск версии 2.0 не продлевает период поддержки версии 1.0, хотя это может сократить объем работ по устранению уязвимостей в версии 1.0 при выполнении условий для устранения проблем в новых версиях. Другие обязанности по обработке уязвимостей продолжают действовать.

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

Периоды поддержки создают требования к долгосрочному хранению записей

Пять лет — это минимальный срок поддержки, а не автоматический стандарт. Период поддержки должен отражать то, как долго предполагается использовать продукт (статья 13(8)). Для таких продуктов, как операционные системы и промышленные системы управления, обычно требуется более длительная поддержка.

Период короче пяти лет требует обоснования, основанного на характере продукта и реальном ожидании того, что он будет использоваться меньше времени (преамбула 60).

Обязательства по ведению документации могут длиться еще дольше:

• Техническая документация и декларация соответствия ЕС должны быть доступны для органов рыночного надзора в течение как минимум 10 лет после выпуска продукта на рынок или в течение периода поддержки, если он дольше (статья 13(13)).
• Каждое обновление безопасности, выпущенное в течение периода поддержки, должно оставаться доступным в течение как минимум 10 лет после его выпуска или до конца периода поддержки, в зависимости от того, что дольше (статья 13(9)).

Процесс обработки уязвимостей продукта является частью его технической документации. Поэтому решения об уведомлениях должны оставаться понятными и доступными для поиска спустя годы. Многие команды в настоящее время не могут объяснить, почему конкретное уведомление было отклонено 18 месяцев назад, не говоря уже о том, чтобы обосновать это спустя десятилетие.

Система, которую вы внедряете сейчас, становится архивом. Информацию, которая никогда не фиксировалась, позже восстановить будет невозможно.

Важные детали реализации все еще находятся в стадии разработки

Два направления заслуживают внимания.

Во-первых, ни один гармонизированный стандарт CRA еще не был опубликован в Официальном журнале Европейского союза. До тех пор пока это не произойдет, презумпция соответствия CRA на основе гармонизированных стандартов в соответствии со статьей 27 недоступна для категории продуктов. Горизонтальный стандарт по обработке уязвимостей будет особенно важен, поскольку он поможет определить, как выглядит надлежащая обработка уязвимостей.

Сроки остаются неопределенными. В июле 2026 года Комиссия опубликовала проект поправки, которая сдвигает некоторые сроки стандартизации 2026 года на два месяца назад. Эта поправка все еще является проектом и сама по себе не была опубликована в Официальном журнале. Завершенный стандарт и его упоминание в Официальном журнале также являются отдельными этапами. Проекты могут помочь командам предусмотреть требования, но они еще не могут установить соответствие.

Во-вторых, руководство Комиссии, опубликованное 27 июля 2026 года, носит рекомендательный характер. Оно было выпущено в соответствии со статьей 26 как приложение к Решению Комиссии C(2026) 5252. Тем не менее, это собственная детальная интерпретация Комиссией таких вопросов, как сфера применения, существенное изменение, периоды поддержки, оценка рисков и отчетность, подкрепленная 67 примерами. Оно полезно для планирования реализации и принятия внутренних решений, но не заменяет сам регламент.

Что инженерным командам следует делать прямо сейчас

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

• Определить, какие продукты подпадают под действие регламента, и задокументировать роль организации в отношении каждого из них.
• Создать учетные записи EU Login для лиц, которым может потребоваться подавать отчеты, и определить назначенную CSIRT.
• Решить, кто уполномочен подавать отчеты, назначить основного и запасного представителей, а также составить регламент отчетности.
• Установить сроки устранения уязвимостей на основе рисков и пути эскалации. Это часть обязательств на 2027 год, но уязвимости, выявленные в ходе сегодняшней приоритизации, должны иметь определенный порядок действий.
• Оценить существующий объем нерассмотренных предупреждений о зависимостях, вместо того чтобы оставлять потенциально релевантные предупреждения без внимания.
• Начать фиксировать решения по приоритизации и устранению уязвимостей, включая задокументированные решения о бездействии.

Ни один из этих шагов не зависит от наличия утвержденного гармонизированного стандарта.

Где применим Kilo Security Agent, а где нет

Ни один инструмент не может обеспечить полное соответствие CRA. Область применения Kilo Security Agent намеренно сужена: он поддерживает часть рабочего процесса по устранению уязвимостей в зависимостях в соответствии с Приложением I, Часть II, пункт 2.

Агент начинает работу с оповещений GitHub Dependabot. Он производит триаж каждого найденного уязвимости и, при необходимости, изучает репозиторий, чтобы определить, затрагивает ли рекомендация код, который действительно выполняется продуктом. Он фиксирует соответствующие файлы, пути к коду и обоснование; открывает пулл-реквесты для устранения уязвимостей; отслеживает сроки, установленные в зависимости от степени серьезности; предупреждает до истечения этих сроков; а также сохраняет историю решений, привязанную к уязвимости.

Пулл-реквест рассматривается как попытка исправить проблему, а не как доказательство ее решения. Уязвимость остается открытой до тех пор, пока исправление не будет подтверждено или человек явно ее не отклонит.

Этот рабочий процесс решает три инженерные задачи, созданные CRA:

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

Границы применения имеют не меньшее значение. Kilo Security Agent не создает спецификации состава программного обеспечения (SBOM), не отправляет отчеты в ENISA или CSIRT, не уведомляет мейнтейнеров вышестоящих проектов и не покрывает другие требования Приложения I, Часть II. Он не проверяет уязвимости приложений, инфраструктуру или образы контейнеров. Для его работы требуется GitHub с включенным Dependabot, поэтому компоненты за пределами этой системы не видны. Он также не принимает решения о том, подлежит ли уязвимость обязательной отчетности по закону; он предоставляет ответственной команде доказательства для принятия такого решения.

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

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

Самый продуктивный способ подготовиться — начать работу с этими системами прямо сейчас.