Программное обеспечение с открытым кодом сейчас применяют 96% организаций. Бесплатные лицензии, возможность кастомизации и большой выбор привлекают бизнес, но больше 50% компаний в исследовании 2025 State of Open Source столкнулись с трудностями в обслуживании таких решений. 63% не успевают устанавливать обновления и исправления, аналогичные проблемы возникают с кибербезопасностью, соответствием нормам и использованием неподдерживаемых версий ПО (EOL). Как избежать этих сложностей и на что обращать внимание при выборе open-source продукта?
Обновления и исправления
Установка обновлений — самая частая проблема, поэтому требует особого внимания. В публичном репозитории проекта можно оценить регулярность выхода новых версий, их значимость и содержание: качество документации, типы исправляемых ошибок, частоту появления дополнительных патчей после релиза, скорость реакции разработчиков на проблемы.
Для анализа подойдут инструменты GitHub Insights или сервисы вроде Is it maintained, Repology, Libraries.io. Последний показывает устаревшие компоненты в текущей сборке.
Важно отслеживать обновления безопасности: выпускаются ли они отдельно или в рамках общих релизов? Обычно выбирают второй вариант, поэтому стоит проверить, как долго критические исправления оставались невнедренными.
Также нужно оценить сложность установки обновлений — официальных документов может быть недостаточно. Рекомендуется изучать отзывы пользователей в сообществах.
Эти шаги помогут спрогнозировать ресурсы на поддержку. Потребуются выделенные сотрудники с достаточным количеством рабочего времени.
Безопасность
Чтобы предсказать частоту проблем с безопасностью, проанализируйте культуру разработки проекта. Первичную оценку можно провести автоматизированными средствами.
Для популярных продуктов используйте OpenSSF Scorecard — он показывает количество открытых уязвимостей, наличие политик безопасности, применение инструментов фаззинга и другие аспекты.
Изучите базы данных уязвимостей (NVD, БДУ, GitHub Advisory Database) для оценки критичности обнаруженных дефектов и скорости их устранения. Большое количество проблем не всегда свидетельствует о низком качестве кода — важнее реакция команды разработки.
Компоненты и цепочка поставок
Большинство проектов включают сторонние open-source компоненты, которые часто не задокументированы. Они обновляются независимо, могут содержать уязвимости или вредоносный код — важно оценить скорость интеграции исправлений в основной продукт.
Для анализа используйте SBOM (Software Bill of Materials) или SCA (Software Composition Analysis). Инструменты OWASP DependencyCheck и syft помогают построить дерево зависимостей, но подходят скорее для уже развернутых проектов. Глубокий анализ лучше проводить после предварительного отбора кандидатов.
Проверьте источники зависимостей: доверенные репозитории, популярность компонентов, наличие цифровых подписей. Выявление уязвимостей в зависимостях вручную сложно — используйте автоматику, например Grype.
Постоянное отслеживание обновлений всех компонентов невозможно без автоматизированных сканеров. Если проект содержит устаревшие зависимости и проблемы с безопасностью, рассмотрите альтернативы. При выборе такого ПО заложите дополнительные ресурсы на поддержку или оцените варианты внешнего обслуживания.
Соответствие нормам
Если регуляторные требования распространяются на ПО и обрабатываемые данные, заранее подготовьте план аудитов. Крупные корпоративные open-source решения могут иметь вспомогательную документацию для упрощения проверок. В остальных случаях всю работу придется выполнять своими силами.
Аудит лицензионной совместимости обязателен почти всегда. Некоторые компоненты (например, под лицензией AGPL) накладывают ограничения на использование. Инструменты SBOM/SCA и OSS Review Toolkit помогут автоматизировать сбор лицензий и проверку их соответствия бизнес-модели.
Расходы на поддержку
После анализа всех факторов станет ясно, какие подходы к обслуживанию оптимальны. При внутренней поддержке потребуются человеко-часы специалистов, а при отсутствии экспертизы — затраты на найм сотрудников. Запланируйте бюджет на регулярное обучение команды.
При недостатке ресурсов рассмотрите профессиональную поддержку: специализированные компании (например, Red Hat) или управляемые платформы (Kube Clusters, MongoDB Atlas и аналоги).
Сложность и стоимость сопровождения зависят от уровня готовности компании к работе с open source:
- наличие сканеров уязвимостей и инструментов управления рисками для OSS;
- поддержка учета open-source компонентов в системах мониторинга ИТ-активов;
- интеграция проверок кода в CI/CD для собственной разработки. Решения вроде Kaspersky Hybrid Cloud Security помогают автоматизировать процесс;
- наличие корпоративной политики по использованию open source с четким распределением ответственности.
Дополнительные риски включают внезапное прекращение развития проекта и проблемы в цепочке поставок компонентов.