Готовы ли киберпространства к закону о цифровой устойчивости? Проблемы и перспективы CRA в контексте open source
ЗаконодательствоКибербезопасность

Готовы ли киберпространства к закону о цифровой устойчивости? Проблемы и перспективы CRA в контексте open source

admin

Принятый Европейским союзом Закон о цифровой устойчивости (Cyber Resilience Act, CRA) — это поворотный момент в регуляции безопасности цифровых продуктов. Впервые правовая система системно регулирует программное обеспечение, включая открытое (open source). CRA вступит в силу в декабре 2027 года и окажет влияние на производителей, поставщиков, разработчиков и дистрибьюторов по всему миру. Тем не менее, как показывает исследование Linux Foundation Research, отрасль пока не готова к его требованиям.

lfr_cra_readiness_031725aСкачать

Основная часть

1. Уровень осведомлённости и понимания CRA

Согласно опросу:

  • 62% респондентов — не знакомы с CRA вовсе или знают о нём лишь поверхностно;
  • 51% — не знают сроков вступления закона в силу, лишь 28% правильно указали 2027 год;
  • 56% — не могут различить роли производителей и опекунов (stewards);
  • 59% — не осведомлены о штрафах за несоблюдение CRA.

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

2. CRA и классификация ролей: от теории к практике

Закон выделяет три категории:

  • Производители — организации, создающие продукты с цифровыми компонентами.
  • Опекуны (Stewards) — организации, развивающие open source для коммерческого использования.
  • Некомерческие разработчики — не подлежат регулированию, но 76% из них не уверены, затрагивает ли их CRA.

Реальность сложнее: многие специалисты (например, интеграторы, консультанты, академики) не могут отнести себя к конкретной роли. Это усложняет оценку ответственности и соответствия требованиям.

3. Производители и зависимость от open source

Текущая практика:

  • Лишь 34% производителей создают SBOM (Software Bill of Materials) для всех продуктов;
  • 46% — пассивно полагаются на upstream-проекты для устранения уязвимостей;
  • Только 38% регулярно оценивают безопасность используемых OSS-компонентов;
  • 63% не планируют вносить изменения или улучшения в open source в рамках CRA.

Активные производители:

  • Имеют 69% зависимости от OSS (против 47% у пассивных);
  • Чаще создают SBOM и оценивают безопасность;
  • В 8 раз чаще вносят upstream-фиксы.

4. Готовность опекунов: ресурсный дефицит

  • 74% опекунов имеют политики по безопасности;
  • 68% — активно устраняют уязвимости;
  • Однако лишь 32% создают SBOM;
  • 71% не имеют формальных процедур уведомления властей о критических инцидентах;
  • Только 9% готовы к предоставлению документации по требованиям регулирующих органов.

5. CRA и некоммерческая open source-деятельность

CRA не должен касаться проектов, не имеющих коммерческой направленности. Однако:

  • 17% OSS-разработчиков ошибочно считают, что CRA на них распространяется;
  • 59% — не уверены в этом;
  • 75% — хотят получить чёткие объяснения и сценарии применения закона.

Из-за этой неясности 30% задумываются о снижении активности в open source или испытывают тревогу.

6. Барьеры и ресурсы

Производители:

  • Основные опасения — сложность регулирования и юридические риски (47%), безопасность компонентов от поставщиков и OSS (46%);
  • Лишь половина оценила финансовые последствия: ожидается рост цен на 6%;
  • Главные приоритеты: GAP-анализ, автоматизация (SBOM, сканеры), интеграция безопасности в DevOps.

Опекуны:

  • Только 32% имеют ресурсы на реагирование при инцидентах;
  • Основные потребности:
    • Финансирование (50%);
    • Юридическая помощь (47%);
    • Технические ресурсы (44%).

Заключение

CRA — это не просто норматив, а системная попытка реформировать весь ландшафт цифровой безопасности. Однако текущее состояние отрасли показывает, что до готовности ещё далеко. Основные вызовы:

  • Недостаточная осведомлённость;
  • Размытость ролей и зон ответственности;
  • Ограниченные ресурсы open source-сообщества;
  • Страх разработчиков и неопределённость юридических границ.

Рекомендации:

  1. Производителям — стать активными участниками open source, создавать SBOM, интегрировать безопасность в SDLC.
  2. Опекунам — стандартизировать процессы, усиливать сотрудничество с пользователями, использовать практики OpenSSF.
  3. Регуляторам — предоставить понятные гайды, защищающие некоммерческие инициативы.
  4. Фондациям — играть роль мостов между индустрией и сообществами, предоставляя инфраструктуру, знания и поддержку.

Источники:

  1. Unaware and Uncertain: The Stark Realities of Cyber Resilience Act Readiness in Open Source. Adrienn Lawson, Stephen Hendrick. The Linux Foundation, March 2025.
  2. European Commission. Cyber Resilience Act Proposal, 2022.
  3. Open Source Security Foundation (OpenSSF). https://openssf.org
  4. SPDX – Software Package Data Exchange. https://spdx.dev
admin
Author: admin

Related Posts

Добавить комментарий