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

Компания 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 различает производителей, импортеров, дистрибьюторов, кураторов программного обеспечения с открытым исходным кодом и участников разработки. Одна и та же организация может выполнять разные роли для разных продуктов.

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

Документ Комиссии July 2026 CRA guidance рассматривает сферу применения, бесплатное программное обеспечение с открытым исходным кодом, удаленную обработку данных, периоды поддержки, отчетность и существенные изменения на примере 67 практических случаев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Предварительное уведомление без неоправданной задержки и не позднее чем через 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, или изменяет целевое назначение, для которого продукт проходил оценку. В руководстве Комиссии практический вопрос формулируется так: создает ли изменение потенциальное негативное воздействие на профиль рисков кибербезопасности, которое не было учтено при первоначальной оценке.

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

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

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

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. Он проводит сортировку каждой находки и, при необходимости, изучает репозиторий, чтобы определить, затрагивает ли рекомендация код, который фактически выполняется в продукте. Он записывает соответствующие файлы, пути к коду и обоснование; открывает запросы на внесение исправлений (pull requests); отслеживает сроки, установленные в зависимости от степени серьезности; предупреждает о приближении этих сроков; и сохраняет историю решений, привязанную к находке.

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

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

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

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

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

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

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