Управляем безопасностью
Open Source-решений

Открытый исходный код используют многие ИТ-компании и организации. С годами их становится все больше. Привлекательные стороны решений с открытым кодом нередко затмевают их очевидные недостатки. Но есть среди них такие, которые всегда держат в напряжении как разработчиков, так и специалистов по ИБ. Главный из них – безопасность Open Source.

На вопросы «СА» отвечают эксперты ИТ-отрасли

1. Как вы подходите к оценке и выбору открытых решений для ключевых бизнес-процессов?
2. Какие методы вы применяете для оценки безопасности Open Source-библиотек и компонентов? Какие инструменты или сервисы вы выбираете для мониторинга безопасности Open Source-проектов?
3. Используете ли вы автоматизированные инструменты для управления безопасностью Open Source-решений, и если да, то какие?
4. Насколько важны обновления и патчи для открытых решений? Как часто вы их применяете?
5. Ваше отношение к использованию сторонних репозиториев для установки Open Source-программ?
6. Эффективно ли, по вашему мнению, сообщество разработчиков ПО с открытым исходным кодом обеспечивает безопасность своих продуктов?
7. Какой подход к лицензированию Open Source вы предпочитаете с точки зрения безопасности?
8. Какую документацию или ресурсы вы считаете наиболее полезными для обеспечения безопасности Open Source-решений?
9. Каковы основные трудности, с которыми вы сталкиваетесь при внедрении и использовании Open Source-решений в вашей организации?
10. Ваши рекомендации ИТ-специалистам, работающим с открытыми решениями?

Максим Захаренко,
СЕО «Облакотека»

«Сообщество Open Source эффективно справляется с обеспечением безопасности только в том случае, когда есть активное ядро разработчиков и сильная поддержка от крупных компаний»

В «Облакотеке» мы активно используем Open Source и считаем его огромным плюсом для бизнеса. Но есть нюанс – свободное ПО не равно бесконтрольному использованию. Открытый код может быть прекрасен, но только если не превращать его в стихийный рынок, где каждый берёт всё подряд.

При выборе открытых решений мы смотрим прежде всего на зрелость проекта, его сообщество и историю обновлений. Если репозиторий «живой», разработчики активно реагируют на баги и уязвимости – это хороший знак. Если же проект полумёртвый или без четкой поддержки, использовать его рискованно.

В вопросах безопасности Open Source мы не полагаемся только на ручную проверку. Применяем комбинацию инструментов вроде OWASP Dependency-Check, Snyk и GitLab Dependency Scanning, которые автоматически мониторят уязвимости в используемых библиотеках и компонентах. Сканируем код регулярно, как на этапе разработки, так и в продакшене – это уже обязательная часть нашей рутины.

Автоматизация в управлении безопасностью тоже необходима, иначе ручной мониторинг становится слишком трудоемким и неэффективным. Мы используем автоматизированные CI/CD-пайплайны, которые проверяют безопасность при каждом релизе и сразу сигнализируют, если что-то не так. Например, тот же SonarQube или GitLab CI/CD дают быстрый и наглядный результат по качеству кода и безопасности.

Обновления и патчи – это вообще больная тема. Их нельзя откладывать в долгий ящик, но и применять «в лоб» каждое мелкое обновление не всегда практично. Поэтому критические апдейты (особенно касающиеся безопасности) мы устанавливаем практически сразу, менее срочные – по расписанию, обычно еженедельно или ежемесячно.

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

Считаю, что сообщество Open Source эффективно справляется с обеспечением безопасности только в том случае, когда есть активное ядро разработчиков и сильная поддержка от крупных компаний. Это важно, потому что реально серьёзные уязвимости не закрываются за пару дней силами двух-трех энтузиастов.

Наш выбор чаще всего – в пользу permissive-лицензий вроде MIT, Apache 2.0 или BSD. Они простые и прозрачные с точки зрения рисков и безопасности. Строгие лицензии типа GPL хороши для сообщества, но бизнесу иногда несут юридические и операционные риски.

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

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

Совет ИТ-специалистам простой: контролируйте, автоматизируйте и не бойтесь отказываться от решений, которые выглядят рискованно или слишком сыро. Open Source – это свобода, но не анархия.

Алексей Рубаков,
основатель компании NETRACK, ведущий оператор комплексных решений в области ЦОД

«При выборе конкретных Open Source-библиотек и компонентов мы применяем автоматизированные инструменты для проверки безопасности и контроля зависимостей»

Open Source давно стал неотъемлемой частью современной ИТ-инфраструктуры, включая ключевые бизнес-процессы. Однако открытость кода не гарантирует автоматическую безопасность и стабильность – поэтому мы подходим к выбору и эксплуатации таких решений с особой тщательностью.

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

Мы также учитываем лицензирование – предпочитаем открытые, но предсказуемые лицензии типа MIT и Apache 2.0, которые минимизируют юридические риски.

При выборе конкретных Open Source-библиотек и компонентов мы применяем автоматизированные инструменты для проверки безопасности и контроля зависимостей.

Среди используемых нами – OWASP Dependency-Check, Snyk и Trivy, которые позволяют выявлять известные уязвимости, а также следить за новыми CVE. Мониторинг ведется постоянно, включая интеграцию с CI/CD, что позволяет не пропускать критичные обновления.

Обновления и патчи для Open Source – это одна из основ безопасности. Мы строго придерживаемся политики регулярного обновления: планируем еженедельные или ежемесячные релизы с последующим тестированием, а для критичных уязвимостей действуем незамедлительно. При этом важна автоматизация процессов обновления, но без потери контроля – каждый патч проходит этап тестирования в безопасной среде.

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

Вопросы безопасности в Open Source-сообществе неоднородны. Есть проекты с высоким уровнем ответственности, где внедрены передовые практики secure coding, аудит и автоматизированное тестирование. Однако встречаются и менее зрелые решения, где реакция на уязвимости замедлена или отсутствует вовсе. Поэтому мы не полагаемся на сообщество как на единственный источник безопасности – всегда проводим собственный аудит и анализ рисков.

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

Рекомендации ИТ-специалистам: Следует относиться к Open Source с таким же вниманием и дисциплиной, как к коммерческому ПО. Важно системно оценивать каждое решение, использовать автоматизированные средства безопасности, регулярно обновлять компоненты и вести прозрачную документацию. Это позволит снизить риски, повысить устойчивость инфраструктуры и воспользоваться всеми преимуществами открытых технологий.

Виталий Янко,
управляющий партнер, Инвестбутик SPBF Global x SoftwareLead, г. Санкт-Петербург

«Многие продукты, хоть открытые, хоть закрытые, состоят из одного и того же набора компонентов (открытых). Так что социальные механики open source- разработки неизбежно помогают всему рынку ПО»

В контексте ухода из России крупных вендоров часто говорили об импортозамещении и совсем забыли про open source. Решений много, и часто они созданы именно как замена популярным сервисам, но с упором на безопасность или какие-то другие значимые функции. Причём создавались они годами, а не на коленке, в попытке быстро заменить какой-то иностранный продукт.

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

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

Репозиторий – это просто инструмент распространения. Если код один и тот же везде, вопросов нет.

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

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

В конечном счёте, многие продукты – хоть открытые, хоть закрытые – состоят из одного и того же набора компонентов (открытых). Так что социальные механики open source- разработки неизбежно помогают всему рынку ПО.

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

Евгений Лощаков,
заместитель директора по производству MD Audit (ГК Softline)

«Главная рекомендация ИТ-специалистам – не рассматривать Open Source как «бесплатное и безопасное по умолчанию»

К выбору Open Source-решений для ключевых бизнес-процессов мы подходим комплексно: оцениваем зрелость проекта, частоту обновлений, активность комьюнити и практический опыт применения в индустрии. Мы выбираем те решения, за которыми стоит стабильное сообщество или коммерческая поддержка, и которые имеют прозрачную дорожную карту. Обязательно проверяем, кто и как мержит pull-запросы, есть ли процессы code review, наличие автоматических тестов и как быстро реагируют на уязвимости.

Для оценки безопасности библиотек и компонентов обычно применяются SCA (Software Composition Analysis) – как встроенные инструменты CI/CD, так и внешние сервисы: GitHub Dependabot, Sonatype OSS Index, Snyk, OWASP Dependency-Check, иногда – Black Duck. Это позволяет видеть не только известные уязвимости (CVE), но и устаревшие зависимости, неактивные мейнтейнеры и подозрительную активность.

Автоматизация для управления безопасностью Open Source-решений критична. Инструменты SAST/DAST работают в паре с SCA, интегрированные в пайплайн, чтобы отслеживать риски ещё на этапе коммита.

Для мониторинга готовых компонентов применяется регулярное сканирование с помощью Trivy, Grype, Clair и Watchtower (в Docker-контейнерах).

Если проект критичен, то задействуется внутренний сканер соответствия политике – чтобы выявить недопустимые лицензии или потенциально опасные зависимости.

Обновления и патчи для Open Source-решений жизненно важны. Мы применяем их регулярно, чаще всего в полуавтоматическом режиме: часть обновлений внедряется сразу после регрессионного тестирования, критические патчи – внепланово, с приоритетной проверкой. Без своевременных обновлений open source превращается в зону риска, особенно в ИБ-чувствительных зонах (reverse proxy, IAM, CI/CD, базы данных).

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

Что касается сообщества, то многое зависит от зрелости проекта. У крупных и популярных решений (например, NGINX, PostgreSQL, Keycloak) – отличная реакция на инциденты и быстрое закрытие уязвимостей. Но у нишевых библиотек или молодых проектов может быть плохая коммуникация или низкий приоритет безопасности. Поэтому мы всегда «страхуемся» – изолируем такие компоненты и применяем sandboxing.

С точки зрения лицензий предпочтительнее Apache 2.0, BSD, MIT – они прозрачны, не конфликтуют с корпоративной политикой и не создают «юридического шума». GPL или AGPL используются только при юридической проработке, чтобы исключить риски публикации закрытого кода.

Для поддержки уровня безопасности активно используется документация OWASP, проекты типа OpenSSF, а также регламенты NIST и CIS. Важно не только техническое описание, но и наличие чек-листов и гайдлайнов по безопасному внедрению.

Среди трудностей выделил бы отсутствие чёткой документации, плохую интеграцию с корпоративной инфраструктурой (особенно в части логирования и аутентификации), а также задержки в исправлении уязвимостей в проектах без активной поддержки.

Главная рекомендация ИТ-специалистам – не рассматривать Open Source как «бесплатное и безопасное по умолчанию». Это мощный инструмент, но только при наличии внутренней экспертизы, процессов управления обновлениями и оценки рисков. Без этих элементов даже самое популярное решение может стать уязвимым звеном.

Григорий Сизоненко,
генеральный директор АО «ИВК»

«Обменивайтесь с мировым сообществом СПО своими наработками, чтобы эти проекты развивались мировым сообществом с учетом ваших наработок»

Ключевой принцип выбора открытых решений для нужд компании – программный продукт должен быть отечественной разработкой, а не клоном импортного. ПО должно разрабатываться на основе репозитория, который самостоятельно развивает российская компания-разработчи, репозиторий находится на территории и под юрисдикцией Российской Федерации. Пример – открытый независимый репозиторий проекта «Сизиф».

Для анализа кода на наличие дефектов применяются единые методологии и единый набор инструментов от ИСП РАН, одобренных ФСТЭК России, а также инструментарий собственной разработки и свободные инструменты. Это инструменты фаззинг-тестирования, статического и динамического анализа. Код тщательно и всесторонне исследуется на всех стадиях разработки, в том числе – с использованием автоматизированных процедур проверки.

Мы используем методологии и набор инструментов от ИСП РАН, свободные инструменты. А также и разработки «Базальт СПО», например, Hasher – инструмент динамического создания «чистого», изолированного, безопасного окружения, в том числе для сборочной среды, Gear – инструмент сборки непосредственно из системы версионирования git, Buildreq – инструмент, позволяющий искать зависимости сборки и оптимизировать их, и др.

Обновления очень важны, особенно обновления по обнаруженным и устраненным уязвимостям. Такие обновления мы применяем непосредственно после получения.

Мое отношение к использованию сторонних репозиториев для установки Open Source-программ? Если речь идет о зарубежных репозиториях, то отрицательно. Безопасность такого ПО невозможно гарантировать.

Сообщество разработчиков ПО с открытым исходным кодом эффективно обеспечивает безопасность своих продуктов. Поскольку код открыт, ошибки, уязвимости и «закладки» в нем находят все заинтересованные разработчики.

Мы руководствуемся, прежде всего, нормативными документами.

ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» устанавливает условия к содержанию и порядку выполнения работ по созданию безопасного ПО и формированию среды обеспечения оперативного устранения выявленных пользователями ошибок и уязвимостей программы.

ГОСТ 15408-1 «Методы и средства обеспечения безопасности. Критерии оценки безопасности ИТ». Документ определяет общую модель безопасности, определяет ключевые понятия профилей защиты (ПЗ), устанавливает структуру и содержание компонентов функциональных требований безопасности для оценки безопасности, а также требования доверия безопасности.

1 апреля 2024 года введён в действие новый ГОСТ Р 71207 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования». Документ разработан ФСТЭК России и ИСП РАН, он устанавливает требования к внедрению и выполнению статического анализа ПО, методам статического анализа, инструментам анализа, специалистам, участвующим в анализе, методике проверки соответствия статических анализаторов ГОСТ (испытательными лабораториями).

Рекомендации ИТ-специалистам. Развивайте собственный независимый репозиторий или создавайте свои решения на базе открытого независимого репозитория «Сизиф». Не заимствуйте готовые решения их зарубежных репозиториев. Практика показывает, что в сегодняшней ситуации усиливающейся санкционной активности недружественных государств зависимость от зарубежных репозиториев может привести к фатальным последствиям: для разработчиков – к невозможности дальше развивать программный продукт, для пользователей – к большим внеплановым затратам на замену в своей ИТ-инфраструктуре неразвивающегося продукта, для государства – к искажению сути госпрограммы обеспечения технологической независимости в сфере ИТ.

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

Приобретая в пользование программный продукт, обращайте пристальное внимание на условия его лицензирования. В дистрибутиве программного продукта, как правило, в корне лежит файл Licence.txt; лицензия видна и при установке ПО. Прочтите ее внимательно! Незнание не освобождает от ответственности, поэтому вы можете столкнуться с очень неприятными сюрпризами.

Ключевые слова: безопасность Open Source-решений

Комментарии могут оставлять только зарегистрированные пользователи