Закон EU Cyber Resilience Act и уязвимости в ПО: что нужно знать разработчикам

В практике разработки и поддержки открытого программного обеспечения регулярно возникают ситуации, которые наглядно иллюстрируют будущее всей индустрии коммерческих IT-продуктов. Шейн Уорден (Shane Warden), главный архитектор компании ActiveState и опытный мейнтейнер open-source проектов, поделился поучительной историей из своего опыта. На официальный адрес безопасности его проекта поступил отчет об обнаруженных уязвимостях. Документ был оформлен по всем правилам конфиденциального раскрытия (responsible disclosure): содержал электронную подпись GPG и был направлен исключительно уполномоченным разработчикам.

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

Тщательная проверка показала, что реальными из 95 оказались лишь две или три проблемы. Несмотря на ничтожно малый процент подтверждения, мейнтейнерам пришлось вручную проработать весь массив данных, чтобы отсеять ложные срабатывания. Вслед за этим пришло второе письмо с прямым шантажом: требованием выплатить 100 000 долларов под угрозой немедленного публичного разглашения данных в стиле резонансной аварии Heartbleed.

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

11 сентября 2026 года вступают в силу нормативные правила информирования в рамках Европейского акта о киберустойчивости (EU Cyber Resilience Act, CRA). С этого момента любой производитель, поставляющий на рынок Евросоюза продукты с цифровыми компонентами, будет обязан уведомить Агентство ЕС по кибербезопасности (ENISA) в течение 24 часов после того, как станет известно об активной эксплуатации уязвимости в его софте. Исчерпывающий отчет должен быть передан регулятору в течение 72 часов.

Технические требования к самой разработке и поддержке продуктов (инженерная часть закона) начнут применяться с 11 декабря 2027 года. Таким образом, индустрия получает 15-месячный переходный период. В течение этого времени EU CRA фактически выступает не как стандарт абсолютной защищенности, а как жесткое требование к полной прозрачности (visibility) вашей цепочки поставок.

Как отмечает генеральный директор ActiveState Эбби Кернс (Abby Kearns), в ближайшие пятнадцать месяцев компаниям придется в срочном порядке искать ответ на два фундаментальных вопроса: «Что именно вы включили в состав релиза и когда впервые узнали о наличии проблемы?». Мейнтейнерам открытого ПО приходится отвечать на эти вопросы постоянно, используя подручные инструменты. Теперь этот экстренный режим становится официальным стандартом для любого коммерческого бизнеса.

Главный вызов — точно знать, какой код попал в релиз

Подобную организационную суету IT-отрасль уже наблюдала в 2021 году, когда в США был издан Указ Президента № 14028. Он обязал поставщиков программного обеспечения для федеральных ведомств формировать спецификацию материалов ПО (Software Bill of Materials, SBOM). Тогда многие организации подошли к задаче формально: документ SBOM генерировался один раз под давлением дедлайна, после чего о нем благополучно забывали.

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

Масштаб задачи огромен. Согласно исследованию Black Duck (2026 Open Source Security and Risk Analysis Report), около 98% современных приложений содержат сторонние open-source компоненты. Это означает, что новые нормы затронут практически каждого производителя, продающего цифровые решения в ЕС.

Дополнительную сложность создает временной разрыв между выходом патчей и требованиями регулятора. По данным отчета Edgescan (2026 Vulnerability Statistics Report), средний срок устранения критической уязвимости в приложениях составляет порядка 55 дней. В то же время регламент EU CRA оставляет компании всего 24 часа на первичное предупреждение и 72 часа на детальное описание проблемы. Именно в этом промежутке между 55 сутками разработки исправления и 72 часами на подачу отчета и будет протекать работа служб безопасности.

Для устранения этого разрыва организации используют два основных подхода:

• Собственная автоматизация конвейера разработки: автоматическая генерация актуального SBOM при каждом релизе, назначение ответственных лиц за обработку уязвимостей и сквозное отслеживание происхождения всех компонентов (provenance) на уровне CI/CD.
• Использование проверенных сторонних компонентов: переход на работу с предверифицированными библиотеками и каталогами, где вопросы происхождения и соответствия требованиям закрываются поставщиком еще до того, как код попадает в сборку.

Оба метода эффективны, однако крайне рискованно откладывать их внедрение на последний момент, надеясь урегулировать отчетность в условиях жесткого 72-часового лимита.

Почему большинство команд готовятся ответить максимум на 2 вопроса из 5

С 11 сентября 2026 года регуляторы ENISA начнут запрашивать конкретные данные по цепочке поставок. Практика показывает, что большинство современных служб безопасности и инженерных отделов способны уверенно ответить лишь на два или три вопроса из пяти, которые задаст проверка.

Большинству инженеров важно сосредоточиться на создании качественного функционала продукта, а не на детальной инспектируемости сторонних пакетов. Для закрытия этой бреши на рынке применяются решения вроде Curated Catalogs от ActiveState, охватывающие до 12 экосистем языков программирования. Они предлагают гарантированное происхождение компонентов и строгие соглашения об уровне обслуживания (SLA) — например, устранение критических уязвимостей в течение 5 рабочих дней после появления официального патча, 10 дней для высокого уровня и 30 дней для остальных.

Это избавляет команды разработки от необходимости вручную выяснять, кто именно и когда добавил конкретную библиотеку в сборку, когда тикает регламентный 72-часовой таймер.

Практический тест на готовность к требованиям EU CRA

Пока сложно сказать, насколько жестко ENISA будет контролировать соблюдение Статьи 14 в первый год ее действия. Тем не менее, рассчитывать на отсутствие проверок опрометчиво. Злоумышленники и вымогатели не ждут вступления законов в силу — они уже активно сканируют открытые зависимости и используют выявленные бреши для давления на бизнес.

Сергей Багров советует провести быстрый внутренний аудит вашей IT-инфраструктуры прямо сейчас:

1. Выберите продукт или сервисный модуль, который ваша команда запустила в продакшен около 6 месяцев назад.
2. Засеките время и попросите ответственного специалиста составить полный и точный перечень всех внешних библиотек и зависимостей этого релиза.
3. Выясните, сколько времени потребуется для того, чтобы определить момент, когда команда впервые узнала о последней критической уязвимости (CVE) в любом из этих компонентов.

Если подготовка этой информации займет больше 72 часов, ваши процессы пока не соответствуют нормам EU Cyber Resilience Act, и подготовку к новому законодательству стоит начать незамедлительно.

Источник: www.bleepingcomputer.com