# Что такое Cyber Resilience Act, и какие требования к кибербезопасности он предъявляет?
Что же за птица такая — Cyber Resilience Act? В этой статье мы поговорим про закон, который выдвигает требования кибербезопасности к продуктам, поставляемым на европейский рынок\. Как выглядят эти требования, какие определены штрафы за их несоблюдение — обо всём в этой статье\.
## Что такое CRA?
Cyber Resilience Act \(CRA\) — это нормативно\-правовой акт \(или же закон\), который предъявляет требования к производителям ПО, выпускающим свои продукты на рынок стран Евросоюза\. Требования касаются кибербезопасности разрабатываемого продукта\.
Создание закона было инициировано Европейской комиссией\. Он вступил в силу 10 декабря 2024 года, а его основным требованиям необходимо начать соответствовать через 36 месяцев с момента вступления в силу, т\.е\. с 11 декабря 2027 года\. Но в нём есть положения, у которых более ранние сроки соответствия:
* О сообщении об уязвимостях и инцидентах \([Article 14](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#d1e2337-1-1)\) — с 11 сентября 2026 года;
* Об уведомлении органов оценки соответствия \([Chapter IV](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#cpt_IV)\) — с 11 июня 2026 года\.
В главе **CONFIDENTIALITY AND PENALTIES**, [Article 64](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847#d1e4473-1-1) \(пункт 2\) указано, что за несоблюдение требований CRA полагается штраф до 15 000 000 евро или, если нарушителем является предприятие, до 2,5 % его общего годового оборота за предыдущий финансовый год — выбирается большая сумма\.
Причины для появления этого закона, исходя из [его же формулировок](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#rct_1), следующие:
* низкий уровень кибербезопасности программного обеспечения, проявляющийся в постоянно возникающих уязвимостях и в несвоевременном устранении уже существующих;
* пользователи не обладают информацией о том, насколько защищено от уязвимостей используемое ими ПО\.
А какое именно ПО необходимо разрабатывать в соответствии с CRA?
## Кому нужно ориентироваться на CRA?
Ещё раз повторю, что CRA — это нормативно\-правовой акт Евросоюза\. Так что его требования распространяются на тех, кто поставляет своё ПО на рынок Евросоюза, даже если оно разрабатывается за его пределами\.
А о каком именно ПО идёт речь? В самом стандарте требования выдвигаются относительно такого понятия, как "продукт с цифровыми элементами" \("product with digital elements"\)\. Там же дано определение:
> 'product with digital elements' means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;
Перевод
Продукт с цифровыми элементами — это программный или аппаратный продукт и его удалённые решения для обработки данных; связанные программные или аппаратные компоненты, поставляемые на рынок отдельно, также попадают под это определение\.
Из этого складывается впечатление, что абсолютно любое ПО является **продуктом с цифровым элементом**\. А как следствие — абсолютно любое ПО попадает под необходимость соответствия CRA\. Однако в самом акте есть [раздел **Scope**](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402847#d1e1334-1-1), содержащий следующее уточнение:
> This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network\.
Перевод
Регламент распространяется на продукты с цифровыми элементами, которые по своему назначению или ожидаемому способу использования подключаются к другим устройствам или сетям \(напрямую или косвенно\) для обмена данными\.
Также в этом же разделе есть важное уточнение: в некоторых отраслевых категориях, таких как медицина, автомобилестроение, оборона, уже существуют собственные нормативные акты, определяющие требования к разрабатываемым программным продуктам\. Именно они и продолжат устанавливать требования к разрабатываемому ПО — CRA на них не распространяется\.
Если подытожить, то можно сказать, что требования из CRA распространяются на компании, разрабатывающие продукты с цифровыми элементами, которые:
* поставляются на территорию ЕС;
* подключаются к другим устройствам или сетям для обмена данными;
* не регулируются другим каким\-либо более специализированным нормативным актом \(указаны в самом тексте CRA в [разделе **Scope**](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402847#d1e1334-1-1)\)\.
Мы успели обсудить, кому может быть интересен этот стандарт, но до сих пор не рассмотрели, что это за требования\. Пора это исправить\.
## Какие требования по кибербезопасности стандарт предъявляет к разрабатываемому продукту?
Давайте теперь рассмотрим сами требования, которые стандарт предъявляет к кибербезопасности продукта\. Они описываются в [CHAPTER III\. CONFORMITY OF THE PRODUCT WITH DIGITAL ELEMENTS](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#cpt_III), которая ссылается на [Дополнение I](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#anx_I)\.
Основные требования, предъявляемые к продукту с цифровыми элементами, поделены на две части:
1. требования кибербезопасности, относящиеся к свойствам продуктов с цифровыми элементами;
1. требования к обработке уязвимостей в продукте\.
Рассмотрим каждую из них\.
### Требования к кибербезопасности, относящиеся к свойствам продуктов с цифровыми элементами
Если обобщённо, то эта группа требований про то, что продукт должен обеспечивать надлежащий уровень кибербезопасности за счёт учёта рисков, которые могут возникнуть при его использовании\.
Для удобства восприятия в этой статье я упрощу и сгруппирую эти требования\. Оригинальное представление из CRA доступно [здесь](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#d1e47-68-1)\.
Требования, касающиеся безопасности и устойчивости продукта по умолчанию:
* продукт не должен содержать известных уязвимостей на момент выхода на рынок;
* продукт должен иметь безопасную конфигурацию по умолчанию \(с возможностью сброса к изначальным настройкам\);
* продукт должен обеспечивать обновление безопасности, в том числе:
* автоматическое обновление по умолчанию;
* уведомление пользователей о новых версиях;
* возможность отложить или отключить обновления\.
Требования к защите данных, обрабатываемых продуктом, и к надлежащему контролю доступа к ним:
* предусмотреть механизмы аутентификации, управления идентичностью и доступом, а также фиксировать несанкционированные попытки входа;
* обеспечить конфиденциальность данных — шифрование при хранении и передаче, использование современных технологий защиты;
* обеспечить целостность данных, команд и конфигураций, а также возможность выявлять их повреждения;
* принимать извне лишь минимально необходимый набор данных\.
Устойчивость и снижение последствий атак:
* поддерживать доступность основных функций, включая меры против отказа в обслуживании \(DoS\);
* минимизировать негативное влияние на другие подключенные устройства и сети;
* ограничивать поверхность атаки \(минимум открытых интерфейсов\);
* применять механизмы снижения ущерба при инцидентах\.
Мониторинг и контроль:
* вести журналы безопасности и мониторинг событий \(с возможностью отключения пользователем\);
* давать пользователю возможность безопасно удалить все данные и настройки и перенести их при необходимости — в защищённой форме\.
### Требования к обработке уязвимостей
Так же, как и с предыдущей группой требований, здесь я их представил в упрощённом и сгруппированном формате\. Оригинальное представление находится [здесь](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#d1e143-68-1)\.
Управление уязвимостями в продукте:
* вести реестр уязвимостей и компонентов;
* оперативно устранять уязвимости, выпуская обновления безопасности отдельно от функциональных;
* регулярно тестировать и проверять безопасность продукта\.
Информирование пользователей и раскрытие информации:
* после выпуска патча публиковать сведения об устранённых уязвимостях: описание, затронутые продукты, серьёзность, рекомендации;
* должна быть реализована политика координированного раскрытия уязвимостей \(CVD\)\.
Взаимодействие с пользователями и обновления:
* организовать канал для информирования об уязвимостях;
* обеспечить безопасное распространение обновлений, в том числе автоматически и бесплатно;
* обновления должны сопровождаться понятными уведомлениями и инструкциями для пользователей\.
## Меры по достижению этих требований
Глядя на них, кажется, что для удовлетворения отдельных требований нужно налаживать достаточно громоздкие процессы, но при этом как они должны выглядеть в точности, не очень понятно\. Для упрощения взаимодействия с этим стандартом ENISA выпустила [статью](https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf), в которой сопоставила требования из CRA с уже существующими стандартами\.
Отдельное внимание я хотел бы уделить требованию к **регулярному и полному тестированию продукта**\. Именно систематическое и всестороннее тестирование помогает придерживаться [shift\-left](https://en.wikipedia.org/wiki/Shift-left_testing) принципа: находить проблемы, ошибки и уязвимости в рамках цикла разработки как можно раньше\. И, как следствие, их исправление для производителя ПО будет дешевле\.
Неполное покрытие тестами увеличивает риск того, что ошибка просочится в итоговый продукт\. Поскольку каждый метод тестирования имеет свою зону ответственности, важно использовать максимально полный набор, чтобы часть проблем не ушла в тень\.
Говоря про shift\-left принцип, важно уделить внимание [статическому анализу](https://pvs-studio.ru/ru/blog/terms/0046/)\. Он позволяет находить ошибки именно на этапе разработки — ещё до тестирования и уж тем более пост\-релиза\. Статический анализ является важной предтечей такого метода тестирования как [SAST](https://pvs-studio.ru/ru/blog/terms/0046/) — тот же анализ исходного кода на наличие ошибок, но уже касающихся безопасности продукта\. В рамках цикла разработки \([SDLC](https://pvs-studio.ru/ru/blog/terms/6732/)\) SAST является важным этапом\. Про это у нас есть отдельная [статья](https://pvs-studio.ru/ru/blog/posts/0937/), рекомендую к ознакомлению\.
Помимо вышесказанного, видно, что SAST\-решение может отдельно помочь с реализацией некоторых требований, которые мы рассмотрели выше\. На примере PVS\-Studio перечислю, что SAST инструмент может уметь:
* потенциальные инъекции и другие уязвимости, среди которых и [SQL\-инъекция](https://pvs-studio.ru/ru/blog/terms/6507/), и [XSS](https://pvs-studio.ru/ru/blog/terms/6462/), и [Path\-traversal](https://pvs-studio.ru/ru/blog/terms/6470/), и многое другое;
* использование [небезопасных алгоритмов шифрования](https://pvs-studio.ru/ru/docs/warnings/v5315/);
* использование [устаревших протоколов обмена данными](https://pvs-studio.ru/ru/docs/warnings/v5313/);
* ошибки, потенциально приводящие к DoS\. К примеру, [ReDoS](https://pvs-studio.ru/ru/blog/terms/7008/) или [XEE](https://pvs-studio.ru/ru/blog/terms/6545/);
* и так далее\.
Подобные ошибки ищутся в соответствии со следующими стандартами и классификациями:
* [OWASP Top Ten](https://pvs-studio.ru/ru/pvs-studio/sast/owasptopten/);
* [MISRA](https://pvs-studio.ru/ru/docs/warnings/#MISRA);
* [AUTOSAR](https://pvs-studio.ru/ru/docs/warnings/#AUTOSAR);
* [OWASP ASVS](https://pvs-studio.ru/ru/pvs-studio/sast/owasp/);
* [Top 25 CWE](https://pvs-studio.ru/ru/pvs-studio/sast/cwetop25/);
* [SEI CERT](https://pvs-studio.ru/ru/pvs-studio/sast/cert/)\.
В контексте рассмотренных ранее требований не могу не упомянуть и про [SCA](https://pvs-studio.ru/ru/blog/terms/6698/) — технологию, позволяющую обнаружить использование уязвимой библиотеки/компонента в составе разрабатываемого ПО\. Именно SCA в том числе может помочь в достижении требования по отсутствию уязвимостей в выпущенном продукте\.
## Заключение
Разработке безопасного ПО уделяется много внимания по всему миру\. В этой статье мы краем глаза обозрели Европейский Cyber Resilience Act и какие требования к разрабатываемому продукту он предъявляет\.
Однако не стоит забывать, что в рамках разработки ПО лучшей практикой является полное всестороннее тестирование\. Помимо SAST\-инструментов, необходимо также помнить и про модульное тестирование, и про функциональное, и про динамический анализ, и про всё\-всё остальное, что поможет вашему продукту быть безопаснее\.
Если затрагивать тему отечественного контроля за разработкой безопасного ПО, то, конечно же, речь пойдёт о ГОСТ Р 56939\-2024 "Защита информации\. Разработка безопасного программного обеспечения\. Общие требования"\. Направлен этот стандарт на предотвращение программных недостатков и уязвимостей и содержит требования, предъявляемые к разработчикам и производителям ПО\. Если есть желание ознакомиться с вопросом, [можете обратиться](https://pvs-studio.ru/ru/blog/posts/1291/) к нашей статье, в которой собрана подборка различных материалов на тему разработки безопасного программного обеспечения \(РБПО\)\.
На этом будем с вами прощаться\. Подписывайтесь на наш блог и до скорых встреч\.