Доверенный open source в российских продуктах: фантазия или рабочая цель?

Дмитрий Белков

Руководитель консалтинга Application Security ГК «Солар»

Open source дал разработчикам главное — скорость и гибкость. Сторонние библиотеки ускоряют вывод релизов, снижают стоимость лицензий, расширяют функциональность. Но вместе с удобством пришли и угрозы: атаки через зависимости, бэкдоры, эксплойты. Мы все помним Log4j и OpenSSL: когда до 80% библиотек остаются не обновленными, отсутствие контроля зависимостей становится системным риском.

Может ли на этом фоне появиться доверенный open source — открытые компоненты, которые можно использовать без компромиссов по безопасности? Да. Но важно договориться о критериях и инфраструктуре.

Дмитрий Белков, руководитель консалтинга Application Security ГК «Солар», в материале для Cyber Media оценил вероятность появления доверенного open source и поговорил о процессах в основе безопасной разработки.

Что такое «доверенный open source»

Мы называем доверенным open source набор практик и свойств, которые делают использование открытого кода предсказуемым и безопасным:

• Прозрачная разработка: публичные репозитории, открытые процессы, активное сообщество, регулярные релизы.
• Внешняя проверка: независимый аудит, сертификация, подтверждение соответствия требованиям безопасности.
• Гарантии происхождения: загрузка только из официальных источников, проверка целостности (подписи, hash-суммы).
• Интеграция в процессы: DevSecOps-практики, SCA/SAST-инструменты встроены в CI/CD.

Есть ли на российском рынке условия для формирования такой инфраструктуры для появления доверенного открытого кода? Да, условия были всегда, но насколько полно все эти условия применяются, в этом важно разобраться.

Российские реалии: скорость против контроля

Сегодня скорость разработки растет быстрее, чем качество управления open source‑зависимостями. Уязвимости уходят в прод, обнаруживаются уже у заказчиков и пользователей. С появлением оборотных штрафов и усилением требований регуляторов безопасная разработка перестала быть «хорошей практикой» — это вопрос ответственности бизнеса перед партнерами и клиентами.

По данным исследования ГК «Солар» и HH.ru (июнь 2025), в ИБ‑компетенциях наблюдается дисбаланс: около 25% резюме содержат «универсальные» навыки, а доля наиболее востребованных эксперты по безопасной разработке составляет лишь 4%. Как показывает практика собеседований, современные стеки (Kubernetes, CI/CD) знакомы немногим, навыков DevSecOps не хватает. В результате техническое интервью проходят лишь 40–50% кандидатов уровня middle; среди senior-специалистов компетенции подтверждают 70–80%.

Дефицит экспертизы усиливает риски: специалисты без достаточного технического бэкграунда используют готовые модули, не оценивая сопутствующие угрозы. В результате в продукты попадают компоненты с бэкдорами, скрытыми уязвимостями и недокументированным поведением — отсюда и репутация «опасного открытого кода».

Отказаться от open source сегодня невозможно. Значит, нужно инвестировать в людей и процессы.

Как стимулировать инвестиции в безопасную разработку

Бизнес можно поддержать экономическими и организационными мерами:

• Приоритет отечественного ПО в гос- и корпоративных тендерах: усилить контроль, чтобы повысить эффективность политики импортозамещения и сократить обходные схемы.
• Точечная поддержка по сегментам: компенсировать часть затрат на внедрение российских решений (в том числе обучение и адаптацию команд).
• Развитие кадрового потенциала: поддержка образовательных программ, стажировок, повышения квалификации, формирование прикладных DevSecOps‑навыков.

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

Аудит безопасности как норма

Грамотное применение SCA/OSA‑инструментов позволяет ведомствам, крупному бизнесу и SMB минимизировать риски по всей цепочке поставок ПО — от дизайна до эксплуатации. Следующий шаг — экосистема доверия: например, федеральный центр безопасности ПО, регулярные проверки, публичный рейтинг доверия к компонентам и проектам. Это даст основу для сообщества, развивающего свободное ПО системно.

Мы уже запустили облачный сервис проверки безопасности open source‑кода для небольших IT‑команд и стартапов. В перспективе это снизит риски уязвимостей по цепочке поставок в продуктах подрядчиков.

Контуры эффективного аудита в компаниях:

• Автоматизация: SCA/OSA выявляют уязвимости, устаревшие/небезопасные зависимости и лицензионные нарушения.
• Непрерывность: новые CVE появляются ежедневно, мониторинг не может быть разовым.
• Политика работы с open source`ом: стандарты выбора, внедрения, обновления и вывода компонентов из эксплуатации.
• Верификация доверия: для критичных узлов — ручной аудит, внешние эксперты, репутационные рейтинги проектов.
• Реестр компонентов (SBOM): чтобы быстро реагировать на угрозы и управлять обновлениями.

Это не только про инструменты — это организационная задача, в которой вовлечены все участники SDLC. 

Open source — основа отечественного ПО

Это уже реальность. По действующим правилам продукт с открытыми компонентами включают в реестр отечественного ПО, если:

• исключительные права на итоговый продукт у российской компании;
• разработка, поддержка и развитие ведутся преимущественно в РФ;
• компания оперативно устраняет уязвимости и обновляет компоненты;
• аудит SCA/OSA подтверждает отсутствие известных уязвимостей и закладок.

Открытый код из «риска» превращается в инструмент соблюдения требований ГОСТ Р 56939‑2016, ГОСТ Р 56939‑2024 и приказа ФСТЭК №239 — при условии зрелых процессов.

Вместо вывода

Доверенный open source возможен. Для этого не нужен отказ от скорости, нужен баланс: культура DevSecOps, подготовленные команды, автоматизация анализа составных частей ПО, инфраструктура доверия и независимый аудит. В текущих рыночных условиях это не только про соответствие требованиям и снижение рисков, но и про конкурентное преимущество: экономически оправданная безопасность, которая ускоряет развитие отечественного софта.