В последние годы вопросы кибербезопасности стали одним из ключевых направлений развития информационных технологий. В ответ на растущие угрозы Европейский Союз разработал и внедряет ряд нормативных актов, среди которых выделяется закон о киберустойчивости — Cyber Resilience Act (CRA). Данный закон призван повысить уровень защиты цифровых продуктов и сервисов, устанавливая строжайшие требования к безопасности ПО. И хотя полномасштабное вступление CRA в силу запланировано на начало 2027 года, уже сейчас разработчики и поддерживающие проекты с открытым исходным кодом ощущают его влияние и сталкиваются с новыми требованиями со стороны коммерческих компаний. Одним из ярких примеров является ситуация с Дэниэлом Стенбергом, создателем cURL — известного в мире программного обеспечения проекта с открытым исходным кодом и библиотеки для передачи данных по URL.
Он получил официальное письмо от крупной корпорации из списка Fortune 500 с просьбой предоставить подробную информацию по безопасности и составу программного обеспечения (SBOM — Software Bill of Materials) относительно одной из старых версий libcurl. Несмотря на отсутствие какого-либо прямого договора или коммерческих обязательств, запрос был оформлен в рамках подготовки компании к требованиям Закона о киберустойчивости, при этом срок ответа поставлен в очень сжатые рамки — всего две недели. Как показывают комментарии самого Стенберга, подобные запросы начинают становиться повсеместными и являются тревожным сигналом для сообщества открытого исходного кода. Многие добровольцы, поддерживающие проекты, не имеют ресурсов, времени и даже юридической подготовки для полноценного выполнения подобных требований. При этом крупные предприятия зачастую ожидают от них мгновенного и формального ответа, ставя их в неудобное положение.
Такой дисбаланс в ожиданиях наглядно демонстрирует разрыв между коммерческими организациями и волонтерами, создающими и развивающими базу современных технологий. Необходимо понимать, что закон CRA предъявляет определённые обязательства к «производителям цифровых продуктов», включая ведение подробного списока компонентов ПО, регулярный мониторинг уязвимостей, обеспечение безопасности по умолчанию и предоставление механизмов для уведомления о инцидентах после выпуска продукта на рынок. Для коммерческих фирм, использующих открытое программное обеспечение в своих продуктах, это проблему усложняет, так как им необходимо тщательно отслеживать все зависимости и компоненты, что неминуемо ведет к необходимости обращаться к разработчикам этих компонентов. Однако большинство разработчиков OSS не являются «производителями» в юридическом смысле. По официальным рекомендациям Open Source Security Foundation (OpenSSF), добровольцы, которые публикуют код без коммерческой цели, как правило, не подпадают под прямые обязательства CRA.
Но такая классификация не всегда решает проблемы на практике, поскольку компании продолжают отправлять формальные запросы с требованием информационной поддержки и аудита. Открытое программное обеспечение традиционно основано на добровольной работе большого числа людей, которые поддерживают и развивают проекты за счет собственного времени и усилий, а не в рамках трудовых контрактов. Внезапное возложение на них ответственности за выполнение регуляторных требований, особенно с жесткими дедлайнами и детализацией, создает серьезные этические и организационные противоречия. Многие разработчики ощущают давление и вынуждены отвечать отказом или перенаправлять коммерческие организации к специализированным фирмам, способным предоставлять поддержку на коммерческой основе. Возможные последствия закона не ограничиваются только нагрузкой на разработчиков.
Общественные организации, такие как Open Source Initiative, Eclipse Foundation и Linux Foundation, выражают опасения, что такие требования могут отпугнуть новых участников от вклада в открытое ПО, а также привести к юридической неопределенности и стимулировать компании создавать форки проектов для сохранения контроля над использованием и безопасностью. Еще одной значимой проблемой становится вопрос определения, кто именно считается производителем в рамках CRA, особенно это касается индивидуальных разработчиков и малых консалтинговых компаний, где граница между коммерческой деятельностью и добровольной работой часто размыта. Правовые трактовки могут варьироваться, что создает дополнительную неясность и тревогу у независимых специалистов. Все эти факторы поднимают очень важный вопрос — кто должен нести ответственность и расходы, связанные с соблюдением требований безопасности. Если коммерческие компании получают существенную выгоду от использования открытого кода, логично предположить, что именно они должны инвестировать в обеспечение безопасности и поддержку этих проектов, а не перекладывать этот груз на хрупкий и в основном некоммерческий волонтерский сектор.
Некоторые представители сообщества подчеркивают, что закон CRA выставляет перед бизнесом возможность пересмотреть отношение к поддержке и финансированию открытого программного обеспечения — не просто как к бесплатному инструменту, а как к критически важной инфраструктуре, заслуживающей инвестиций и профессионального обслуживания. В идеале это должно привести к появлению новых моделей сотрудничества, где компании будут активнее вовлекаться в обеспечение надежности используемых ими компонентов. Несмотря на все сложности, истории с договорами и запросами, подобными Дэниэлу Стенбергу, служат своего рода радаром и показателем изменений. Как будет развиваться ситуация — зависит от того, смогут ли законодатели и регулирующие органы учесть особенности открытого программного обеспечения, а бизнес — скорректировать свои ожидания и найти баланс, при котором не будет подорвана жизнеспособность добровольных проектов. В целом, ситуация вокруг закона о киберустойчивости — это вызов и для всей индустрии, и для сообщества открытого кода.
На кону стоит не только безопасность программных продуктов, но и будущее инноваций, основанных на свободных и доступных технологиях. Правильное понимание и сотрудничество между всеми участниками экосистемы станет ключевым фактором успеха в эру новых цифровых правил и требований безопасности.
