Как выбрать решения open source для организации?

Приложения с открытым исходным кодом используются уже в 96% компаний. Широкий выбор, возможность доработок и нулевая стоимость лицензии очень привлекательны, но более половины фирм, опрошенных в рамках отчета 2025 State of Open Source, испытывают серьезные проблемы с их сопровождением. 63% не успевают обновлять решение и применять патчи, немногим меньше проблем с кибербезопасностью, регуляторным соответствием и наличием open-source-софта с истекшим сроком службы (EOL, более неподдерживаемым). Как минимизировать вероятность возникновения этих проблем и куда смотреть еще на этапе выбора open-source-приложения для внедрения?

Обновления и патчи

Поскольку своевременные обновления — самая широко распространенная проблема, смотреть на приложение-кандидата с этой точки зрения нужно особенно внимательно. Прямо в публичном репозитории приложения несложно проверить частоту и масштабность обновлений, а также их состав. Обращать внимание нужно на то, насколько хорошо задокументированы обновления; какого рода проблемы в них решаются и какие функции добавляются; часты ли ситуации, когда следом за выходом новой версии через несколько дней или недель выходят мелкие фиксы; насколько быстро закрываются запросы, связанные с устранением ошибок?

Ответить на эти вопросы помогут стандартные инструменты вроде GitHub Insights, а также вспомогательные сервисы, например Is it maintained, Repology, Libraries.io. Последний сразу отображает, какие устаревшие зависимости используются в текущей версии.

Отдельное внимание стоит уделять обновлениям, связанным с безопасностью. Выходят они отдельным треком или их выпускают вместе с функциональными обновлениями? Как правило, разработчики идут по второму пути, и тогда надо разобраться, долго ли обновления безопасности ждали своего выпуска.

Также надо оценить, насколько сложна установка обновлений. Для этого недостаточно официальной документации и помощи (хотя с ее изучения можно начать). Но тут скорее поможет внимательное изучение отзывов в сообществах пользователей.

Все это поможет понять, сколько сил будет уходить на сопровождение продукта. На поддержку придется выделять внутренние ресурсы, причем недостаточно просто назначить ответственных, им потребуется определенное количество выделенных рабочих часов только на эту и сопутствующие задачи.

Уязвимости

Чтобы спрогнозировать, насколько часто придется сталкиваться с проблемами кибербезопасности, желательно сразу оценивать продукт с точки зрения инженерной культуры и ИБ-гигиены. Это трудоемко, но первый поверхностный анализ можно провести автоматизированными инструментами.

Подход, применимый для популярных продуктов и пакетов, — проверить готовые результаты эвристической оценки, например с помощью инструмента OpenSSF Scorecard. Здесь сразу доступны разнообразные данные об ИБ-гигиене: от числа неустраненных уязвимостей и наличия политик безопасности до использования фаззинга и закрепления (pinning) зависимостей.

Также необходимо изучить публичные репозитории уязвимостей (NVD, БДУ, GitHub Advisory Database), чтобы понять, сколько дефектов было обнаружено в проекте, насколько они критичны и быстро ли были устранены. Само по себе изобилие уязвимостей говорит скорее о популярности проекта, чем о низкой культуре разработки, но вот типы дефектов и то, как на них реагировали разработчики, — важно.

Зависимости и цепочка поставок

Почти каждый OSS-проект использует сторонние компоненты open source, которые часто не документированы. Эти компоненты обновляются по своему графику, могут содержать ошибки и уязвимости, даже вредоносный код, но вот насколько быстро исправленные обновления компонентов попадают в рассматриваемый вами проект?

Для оценки потребуются инструменты SBOM (Software Bill of Materials) или SCA (Software Composition Analysis). Доступные open-source-решения вроде OWASP DependencyCheck или syft позволяют построить дерево зависимостей проекта, но они обычно предназначены для уже эксплуатируемых проектов: собственных репозиториев, образов контейнеров и так далее. Поэтому глубокий анализ зависимостей лучше проводить с продуктом, который уже прошел предварительные стадии оценки и серьезно претендует на место в инфраструктуре.

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

Проверять уязвимости в зависимостях теоретически можно вручную, но, если OSS-проект уже развернут в тестовой инфраструктуре, лучше опять использовать инструменты, такие как Grype.

Огромным подводным камнем является мониторинг обновлений — теоретически каждое обновление зависимостей проекта нужно проверять заново. Но на практике это реализуемо только автоматизированными сканерами, другие подходы слишком дороги.

Если проект использует устаревшие зависимости и в целом не идеален с точки зрения ИБ, лучше, конечно, выбрать что-то иное. Но что делать, если бизнес настаивает на конкретном решении, оптимальном по основной функциональности? Все, как обычно: более глубокий анализ рисков, проработка компенсирующих мер, а главное — выделение больших ресурсов на сопровождение. Внутренних ресурсов часто не хватает, поэтому сразу стоит оценить варианты профессиональной техподдержки конкретного продукта.

Соответствие внутренним и регуляторным требованиям

Если применимые к компании регуляторные политики относятся к выбранному ПО и данным в нем, нужно сразу разработать план прохождения аудитов соответствия. У очень крупных приложений open source для корпораций иногда есть вспомогательные документы, упрощающие прохождение некоторых видов аудита. Если же их нет, придется разрабатывать все самостоятельно — опять закладывая время и ресурсы.

Практически в любом ПО и в любой индустрии потребуется аудит соответствия лицензионным требованиям. Некоторые компоненты и приложения open source поставляются со строгими лицензиями вроде AGPL, которые ограничивают возможности распространения и использования ПО. Благодаря анализу SBOM/SCA можно собрать все лицензии не только на ПО, но ни на его зависимости, а затем убедиться, что ваша модель использования не нарушает ни одну из лицензий. Эти процессы можно в значительной мере автоматизировать при помощи специализированных инструментов, таких как OSS Review Toolkit, но автоматизация потребует четких политик и сил команды разработки.

Стоимость поддержки

После анализа всех этих аспектов сложится картина, позволяющая сравнить разные способы поддержки приложения. Для поддержки внутренней командой придется выделить человеко-часы профильных специалистов, а если нужных компетенций в команде нет — придется кого-то нанимать. Тем, кто в основном занимается вопросами поддержки OSS и безопасности этих проектов, нужно выделить время и бюджет еще и на регулярное повышение квалификации.

Если ресурсы внутренней команды недостаточны для поддержки (мало людей, нет экспертизы), есть как минимум два вида профессиональной техподдержки на аутсорсинге: фирмы, специализирующиеся на поддержке эксплуатации приложений (Red Hat), или провайдеры управляемого хостинга на базе конкретных приложений (Kube Clusters, MongoDB Atlas и тому подобные).

Кроме фактора времени и экспертизы, на стоимость и сложность техподдержки влияет общая готовность организации к широкой эксплуатации open source:

• есть ли у службы ИБ сканеры уязвимостей и инструменты управления рисками, хорошо адаптированные к OSS;
• поддерживают ли инструменты учета ИТ-активов и мониторинга работы с проектами и компонентами OSS;
• для команд, ведущих собственную разработку, — включены ли процессы сканирования образов, репозиториев и других источников кода в конвейер CI/CD. Специализированные защитные решения, такие как Kaspersky Hybrid Cloud Security, позволяют автоматизировать этот аспект;
• разработана ли в компании политика, регламентирующая применение OSS, и есть ли четкое понимание, кто принимает решения и кто отвечает за вопросы эксплуатации.

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