Cyber Resilience Act (CRA) – регламент ЕС о киберустойчивости цифровых продуктов. Для коммерческого софта и «подключённых» устройств он задаёт требования к безопасности на всём жизненном цикле: от разработки до обновлений и поддержки. Для open source и дистрибутивов вроде Debian вопрос звучит иначе: что из требований относится к volunteer-проектам, пакетам в archive и к тем, кто поставляет продукт на рынок ЕС.
Ниже – практический разбор: о чём CRA, почему вокруг него спорили FOSS-сообщества, и что важно держать в голове разработчикам и пользователям Debian-стека. Это обзор логики закона и типичных рисков, а не юридическая консультация.
Зачем нужен CRA
Цель регулятора – снизить число «дырявых» продуктов на рынке: слабые пароли по умолчанию, отсутствие обновлений, непрозрачная цепочка поставки ПО. Производитель (в смысле law: economic operator, кто выводит продукт на рынок) должен проектировать security by design, закрывать уязвимости в разумные сроки, документировать процессы и, в ряде случаев, проходить оценку соответствия.
Для пользователя это потенциально плюс: меньше заброшенных IoT-коробок и яснее, кто отвечает за патчи. Для разработчика и вендора – дополнительные обязанности, отчёты и возможные штрафы при нарушениях.
Где здесь Debian и open source
Debian – дистрибутив, который собирает, патчит и сопровождает огромный archive. Сам по себе free software в репозитории и работа volunteer-мейнтейнеров – не то же самое, что коммерческий «product with digital elements», который продают как готовое решение. Ключевой спор FOSS-сообщества вокруг CRA как раз о границах ответственности:
- кто считается manufacturer, если код пишут тысячи волонтёров, а пакет в дистрибутив кладёт мейнтейнер;
- не должен ли закон «придавить» некоммерческие upstream-проекты теми же обязательствами, что и платный SaaS/устройство;
- как не сломать модель security-support, security team и open disclosure уязвимостей.
Практически: если вы просто пользуетесь Debian на сервере – вы в зоне ответственности как админ своей системы. Если вы продаёте appliance, образ, коробку или managed-продукт на базе Debian в ЕС – вы ближе к роли economic operator и уже смотрите CRA (и смежные нормы) как на compliance-рамку.
Что обычно требуют от «цифрового продукта»
- базовая гигиена: без известных критичных дыр на релизе, без дефолтных секретов «admin/admin»;
- возможность получать security-обновления в течение заявленного срока поддержки;
- процессы: SBOM/учёт зависимостей, реагирование на CVE, документирование residual risk;
- для более «критичных» классов продуктов – усиленная оценка и надзор.
Конкретные классы продуктов, сроки и пороги – в финальном тексте регламента и secondary acts. Не опирайтесь на пересказы; для compliance читайте официальный текст и юриста по EU tech law.
Риски при «кривой» реализации и непонимании ролей
- Путаница ролей. Upstream Debian ≠ вендор вашего продукта. Копирование пакетов «как есть» без своей модели поддержки не снимает с вас обязанности, если вы продаёте решение.
- Заморозка без патчей. Долгий lifecycle продукта без security-канала – прямой конфликт с идеей CRA и с здравым смыслом.
- Overcompliance для FOSS. Навешивать на каждый pet-проект требования enterprise-вендора – путь к выгоранию мейнтейнеров; закон как раз и обсуждали так, чтобы не убить open source.
- Ложное чувство безопасности. «У нас Debian, значит CRA закрыт» – нет. Закрыт процесс: обновления, inventory, реагирование, границы ответственности.
Что делать разработчикам и админам на практике
- фиксировать, кто выводит продукт на рынок и какой у него support window;
- держать инвентарь зависимостей (SBOM/пакеты) и канал security-обновлений (unattended-upgrades, зеркала, зеркалирование CVE);
- не отключать security suite «чтобы не ломалось» без компенсирующего процесса;
- для commercial-сборок на Debian: документировать, какие компоненты вы меняете, как патчите, как сообщаете о инцидентах;
- следить за позициями Debian Project, FSFE, Eclipse Foundation и других FOSS-организаций по CRA – там обычно разжёвывают, что меняется для мейнтейнеров.
Пользователям Debian
Обычный admin VPS или рабочей станции выигрывает от того, что дистрибутив и security team уже живут в модели «патчим уязвимости». Ваша часть: вовремя обновляться (stable/security), не держать EOL-релизы на проде и не путать «свободный софт» с «кто-то обязан чинить мой кастомный форк вечно».
Краткий вывод
CRA давит на безопасность продуктов на рынке ЕС. Open source и Debian в центре дискуссии о границах ответственности: volunteer-archive – не то же, что commercial product. Если вы только пользуетесь Debian – держите обновления и трезвую модель угроз. Если продаёте решение на его базе – проектируйте support, inventory и процессы реагирования так, будто compliance-вопрос к вам, а не к «дистрибутиву вообще».
