В декабре 2023 года разработчики Debian общим голосованием приняли публичное заявление о европейском Cyber Resilience Act (CRA) и директиве об ответственности за продукцию (Product Liability Directive, PLD). Тогда закон ещё обсуждали, а сейчас он уже действует: CRA вступил в силу 10 декабря 2024 года, обязанность сообщать об уязвимостях начинается с 11 сентября 2026 года, основные требования к продуктам с 11 декабря 2027 года. Ниже что сказал Debian, что в итоге попало в закон и что это значит для тех, кто разрабатывает на Debian или просто держит на нём серверы.
Это обзор логики закона, а не юридическая консультация. Если вы продаёте продукт в ЕС, читайте официальный текст и говорите с юристом.
Что такое CRA
CRA это регламент ЕС 2024/2847 о кибербезопасности продуктов с цифровыми элементами. По словам Еврокомиссии, он касается всего, что подключается к сети: от радионяни и умных часов до приложений и программ. Производитель должен закладывать безопасность при проектировании, разбирать уязвимости весь срок жизни продукта и выпускать обновления. Для части продуктов нужна проверка сторонним органом, а соответствие подтверждается маркировкой CE.
Для пользователя это скорее плюс: меньше заброшенных IoT-коробок без патчей и понятнее, кто отвечает за обновления. Для вендора это новые обязанности, документы и штрафы за нарушения.
Что Debian сказал в 2023 году
Голосование шло с 9 по 22 декабря 2023 года, на выбор было три варианта текста. Победил первый, который предложил Сантьяго Руано Ринкон: самый жёсткий из трёх. Главные мысли заявления:
- Свободное ПО это подарок обществу, и требования CRA делают его распространение юридически рискованным.
- Понять, коммерческий проект или нет, в Debian невозможно: проект не следит, кто где работает и кто финансирует upstream.
- Если авторы upstream-проектов испугаются закона и перестанут выкладывать код, безопасность станет хуже, а не лучше.
- Обязательное сообщение об уязвимостях властям ЕС за 24 часа ломает отлаженную схему ответственного раскрытия и собирает все уязвимости в одном месте, откуда они могут утечь.
- Открытая разработка должна быть полностью выведена из-под CRA, так же как закрытая разработка внутри компании. «Выпуск на рынок» начинается только после релиза.
- Закону нужно исключение для малого бизнеса и разработчиков-одиночек, иначе многие небольшие проекты, от которых зависят дистрибутивы, просто закроются.
Второй вариант был мягче: он поддерживал цели закона и просил только чётко прописать, что разработчики свободного ПО не отвечают как коммерческие вендоры. Третий требовал полностью вывести свободное ПО из-под CRA и PLD.
Что в итоге попало в закон про open source
Финальный текст учёл часть претензий сообщества. По разъяснению Еврокомиссии:
- Под CRA попадает только то свободное ПО, которое выпускается на рынок в рамках коммерческой деятельности. Если автор на продукте не зарабатывает, это не коммерческая деятельность.
- Разработчики, которые просто присылают код в чужой проект, под закон не попадают.
- Появилась новая роль: куратор открытого ПО (open-source software steward). Это юрлицо, которое постоянно поддерживает развитие свободного продукта, рассчитанного на коммерческое использование, например фонд.
- У таких кураторов облегчённые обязанности по статье 24: политика кибербезопасности, работа с надзорными органами, сообщения об активно эксплуатируемых уязвимостях и серьёзных инцидентах. Административных штрафов для них нет.
Обязанность сообщать об активно эксплуатируемых уязвимостях, против которой выступал Debian, в законе осталась. Она начинает действовать с 11 сентября 2026 года и касается производителей продуктов.
Кто за что отвечает на практике
- Вы просто держите Debian на своём сервере или рабочей машине: CRA к вам не относится, вы админ своей системы.
- Вы продаёте устройство, образ, коробочное решение или управляемый продукт на базе Debian в ЕС: вы ближе к роли производителя, и требования CRA уже про вас.
- Взять пакеты Debian как есть не снимает с вас обязанностей, если продукт продаёте вы. Debian не вендор вашего продукта.
- Фраза «у нас Debian, значит, с CRA всё в порядке» не работает. Нужны процессы: обновления, список компонентов, реакция на уязвимости, понятные границы ответственности.
Что делать разработчикам на Debian
- Зафиксировать, кто выпускает продукт на рынок и сколько лет он будет получать обновления.
- Вести список зависимостей (SBOM) и держать канал обновлений безопасности: unattended-upgrades, свои зеркала, отслеживание CVE.
- Не отключать обновления безопасности, «чтобы ничего не сломалось», без замены другим процессом.
- Для коммерческих сборок документировать, какие компоненты вы меняете, как патчите и как сообщаете об инцидентах.
- Следить за позицией Debian, FSFE, Eclipse Foundation и других организаций: там обычно подробно разбирают, что меняется для мейнтейнеров.
Пользователям Debian
Обычному админу VPS или рабочей станции беспокоиться не о чем: дистрибутив и его команда безопасности и так давно живут по принципу «находим и закрываем уязвимости». Ваша часть работы: вовремя ставить обновления из stable и security, не держать на боевых серверах релизы без поддержки и не ждать, что кто-то будет вечно чинить ваш собственный форк.
В итоге Debian в 2023 году выступил против CRA, и часть претензий в финальном тексте учли: некоммерческое свободное ПО и сторонние контрибьюторы под закон не попадают, а для фондов придумали облегчённый режим без штрафов. Обязанность сообщать об уязвимостях за 24 часа осталась и действует с 11 сентября 2026 года. Если вы только пользуетесь Debian, ничего не меняется. Если продаёте продукт на его базе в ЕС, к декабрю 2027 года у вас должны быть процессы поддержки, учёта компонентов и реакции на уязвимости.
