Всем привет!

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

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

Может ли на этом фоне появиться доверенный 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‑навыков.

Позиция профессионального сообщества здесь критична: важно переносить отраслевой опыт в программы переподготовки, чтобы выпускники приходили в проекты с практическими компетенциями. Например, «Солар» с 2024 года является технологическим партнером НГТУ НЭТИ. Более 300 студентов курса «Методология безопасной разработки и эксплуатации ПО» пользуются образовательной лицензией на комплексную платформу Solar appScreener и осваивают DevOps/DevSecOps, включая работу с open source. Аналогичные проекты развиваем с другими региональными вузами.

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

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

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

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

• Автоматизация: SCA/OSA выявляют уязвимости, устаревшие/небезопасные зависимости и лицензионные нарушения.

• Непрерывность: новые CVE появляются ежедневно, мониторинг не может быть разовым.

• Политика работы с open source`ом: стандарты выбора, внедрения, обновления и вывода компонентов из эксплуатации.

• Верификация доверия: для критичных узлов — ручной аудит, внешние эксперты, репутационные рейтинги проектов.

• Реестр компонентов (SBOM): чтобы быстро реагировать на угрозы и управлять обновлениями.

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

Также «Солар» развивает направление консалтинга безопасности приложений (Application Security), помогая клиентам выстраивать и процессы, и технологический стек. В результате повышаем и безопасность, и качество разработки и жизненного цикла софта в целом.

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

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

• Исключительные права на итоговый продукт у российской компании;

• Разработка, поддержка и развитие ведутся преимущественно в РФ;

• Компания оперативно устраняет уязвимости и обновляет компоненты;

• Аудит SCA/OSA подтверждает отсутствие известных уязвимостей и закладок.

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

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

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