Популярность платформ контейнеризации и сам подход к разработке систем через микросервисы подняли новую волну спроса на решения Open Source. Вместе с этим начал всплывать и былой спор: что безопаснее — проприетарные решения или открытый код?
- Введение
- «Плюшки» за «жуков»
- О безопасности Open Source
- Преимущества и недостатки использования решений Open Source
- О Software Composition Analyzers
- Выводы
Введение
Подходы к информационной безопасности в мире ИТ со временем эволюционируют и развиваются. Вопросы цифровой безопасности уже не стоят на дальнем плане в приоритетах большинства компаний и продуктов. Репутационные риски стали не эфемерной угрозой, а реальным бизнес-инструментом. Вспомним, например, что после выявления системных проблем ИБ в своих микропроцессорах компания Intel заказала аналогичное исследование для процессоров AMD. Крупные корпорации активно вкладываются в программы Bug Bounty, а также развивают процессы управления информационной безопасностью и безопасной разработки.
Визионер мирового рынка DevSecOps компания Sonatype совместно с партнёрами выпустила очередной анализ рынка ПО с открытым кодом — State of the Software Supply Chain 2019 (SSSC). Согласно 5-му выпуску SSSC, сохраняются тенденции активного роста распространения Open Source. Растущий спрос на инновации ускорил внедрение автоматизированных конвейеров разработки ПО (development pipelines), одновременно поднимая на новые высоты распространение Open Source во всех экосистемах.
Исследователи отметили, что 95 % кода современных веб-приложений составляют компоненты, загруженные из npm-репозитория. Большинство команд программистов опрошенных компаний включает обновление зависимостей в свой ежедневный процесс разработки. Таким образом, количество включений уязвимого ПО в проекты постепенно снижается.
В исследовании рассматривается важный класс метрик — время обновления и исправления компонентов и зависимостей. Приводятся выводы, что своевременная плановая установка общих обновлений сокращает время на исправление найденных в продукте уязвимостей. То есть сокращение времени установки обновлений, не связанных с безопасностью — MTTU (Mean Time To Update), — снижает также время исправления уязвимостей в продукте — MTTR (Mean Time To Remediate). Для повышения общей защищённости эксперты рекомендуют всегда обновлять пакеты и их зависимости до актуальных версий.
Это подтверждается цитатой Джереми Лонга, основателя The OWASP Dependency Check: проект предполагает, что «только 25 % организаций сообщают об уязвимостях пользователям, и только 10 % уязвимостей зарегистрированы как Common Vulnerabilities and Exposures (CVE)». В качестве примера Лонг приводит уязвимость безопасности, обнаруженную в PrimeFaces — инфраструктуре пользовательского интерфейса Java. Проект PrimeFaces узнал об уязвимости и устранил её в феврале 2016 года. В 2017 году этой уязвимости была назначена CVE (CVE-2017-1000486). Затем CVE была опубликована в национальном каталоге 3 января 2018 г. После публикации CVE криптомайнеры начали активно эксплуатировать уязвимые версии компонента. Разработчики, которые практиковали обновление до последних выпущенных версий PrimeFaces, подвергались меньшему риску, чем те их коллеги, которые полагались на публикацию CVE для запуска процесса по исправлению.
Рисунок 1. Инфографика основных выводов исследования State of the Software Supply Chain 2019
Если в цифрах, то основные выводы отчёта — следующие:
- Распространение компонентов Open Source в коммерческих и промышленных средах показало 75-процентный рост (рис. 2) — во многом благодаря распространению JavaScript и открытых репозиториев пакетов и библиотек, а также активному сообществу разработчиков и росту версионности как для исправления ошибок, так и для внедрения функциональности.
Рисунок 2. Динамика распространения компонентов Open Source в коммерческих и промышленных средах, 2017–2019 гг.
- Проекты, где обновление происходит регулярно, а не по обнародованию CVE и выходу соответствующего патча, показывают более защищённый статус продукта (рис. 3). В целом отмечен тренд на снижение использования уязвимых компонентов в проектах (рис. 4).
Рисунок 3. Сравнение среднего времени на обновление и установку программных исправлений продуктов Open Source
Рисунок 4. Динамика использования компонентов с известными уязвимостями
- Количество подтверждённых взломов открытого ПО по сравнению с 2014 годом выросло на 71 %. Однако в сравнении с 2018 годом имеется тренд на понижение, который, как предполагают эксперты, формируется благодаря внедрению процессов цифровой гигиены в содержании пакетов (Open Source Hygiene) (рис. 5).
Рисунок 5. Предполагаемые или подтверждённые взломы, связанные с открытым исходным кодом, в течение четырёх лет
«Плюшки» за «жуков»
С одной стороны, корпорации усиленно развивают защищённость своих проприетарных продуктов. Один только рост премии за найденные уязвимости — программы Bug Bounty — за последние годы свидетельствует о росте ценности информационной безопасности в глазах высшего управленческого состава ИТ-компаний. По данным платформы HackerOne, статистика премий и согласования вознаграждений в области обмена данными об уязвимостях к 2020 году уже подошла к отметке в 100 млн долларов США (рис. 6). С другой стороны, популярность проприетарных продуктов и низкая техническая квалификация их пользователей всё ещё предоставляют злоумышленникам широкие возможности.
Рисунок 6. Динамика вознаграждений Bug Bounty, полученных через платформу HackerOne
Но надо отметить, что программа Bug Bounty оказывает положительное влияние и на решения Open Source. Программы Bug Bounty открывают не только гиганты проприетарных решений, такие как Microsoft и Apple, но и те корпорации, чьим продуктом являются сервисы и микросервисы — например, Facebook или Google. Эти компании активно используют именно ПО с открытым кодом и собственные разработки. Таким образом, внимание сообщества этичных хакеров привлечено к решениям Open Source не только репутационными, но и финансовыми «плюшками».
Что касается устранения найденных уязвимостей — для ПО с открытым кодом вопросы репутации более важны, чем для крупных проприетарных гигантов. Активный (идейный) пользователь Apple не изменит платформу, несмотря на любые найденные в ней уязвимости, так как такая миграция для него является слишком трудоёмкой. С другой стороны, сменить одно открытое ПО на другое, более качественно обслуживаемое командой разработчиков — куда более простая задача. Поэтому оперативный патчинг для Open Source более важен. Если обратиться к примерам, то обнаруженная в этом году уязвимость ZeroLogon была обнародована в августе, тогда же вышел патч от Microsoft для этой уязвимости, и уже через месяц был опубликован патч от команды Samba, так как они используют этот же протокол (NetLogon) для сетевого общения с компонентами домена.
О безопасности Open Source
Организация Linux Foundation совместно с GitHub, Google, IBM, JPMorgan Chase, Microsoft, NCC Group, OWASP Foundation и Red Hat учредила новый совместный проект OpenSSF (Open Source Security Foundation), целью которого является повышение безопасности ПО с открытым кодом. OpenSSF продолжает развитие инициатив Core Infrastructure Initiative и Open Source Security Coalition и включает в свои функции:
- раскрытие информации об уязвимостях и распространение исправлений;
- разработку инструментов для обеспечения безопасности;
- разработку и публикацию лучших практик по ИБ при организации разработки;
- выявление угроз в открытом ПО, аудит и усиление ИБ критически важных открытых проектов;
- организацию идентификации и подтверждения личности разработчиков для исключения внесения нелегитимных изменений в код.
Это — новый проект, и все процессы пока находятся в инкубационном статусе. К проекту уже присоединились GitLab, HackerOne, Intel, Uber, VMware, ElevenPaths, Okta, Purdue, SAFECode, StackHawk и Trail of Bits.
Linux Foundation’s Core Infrastructure Initiative (CII) и Гарвардская лаборатория инноваций (Laboratory for Innovation Science at Harvard, LISH) в начале 2020 года выпустили вторую перепись важного ПО с открытым кодом (Census II of Open Source Software), в которой исследуются наиболее важные и часто используемые свободно распространяемые пакеты по вопросам ИБ. В том числе пропагандируется подход на основе гигиены доставки компонентов в свой код и их использования (Supply Chain Hygiene), которая подразумевает следующие принципы:
- использовать меньшее разнообразие компонентов;
- использовать только высококачественные компоненты, что означает отказ в крупных проектах от «сырых» компонентов в пользу стабильных, даже если последние уступают по функциональности;
- постоянно контролировать и информировать, какие компоненты используются и где.
Также существует ряд проектов, занимающихся регулярным исследованием уровня защищённости открытого ПО. Например, проект Coverity в сотрудничестве со Стэнфордским университетом, а ныне анализатор кода компании Synopsys — яркий пример предприятия по систематическим исследованиям Open Source и один из лидеров в данном сегменте. Компания проводит автоматическое обнаружение дефектов и критических типов ошибок в открытом ПО, уровень качества и безопасности в их идеологии измеряется ступенями. Ступени не имеют окончательного значения и могут изменяться по мере того, как Coverity выпускает новые инструменты. Ранги основаны на прогрессе исправления проблем, обнаруженных по результатам анализа, и степени сотрудничества разработчика ПО с Coverity. Ранги начинаются со ступени 0 и в настоящее время идут до ступени 2:
- Ступень 0. Проект был проанализирован инфраструктурой Coverity Scan, но ни один представитель сообщества ПО с открытым исходным кодом не сообщил о результатах.
- Ступень 1. Происходит сотрудничество между Coverity и командой разработчиков. ПО анализируется с помощью подмножества функций сканирования, чтобы не перегружать команду разработчиков.
- Ступень 2. Было проанализировано 11 проектов, получивших статус «Rung 2», в результате чего в первый год сканирования было достигнуто нулевое значение количества дефектов. Эти проекты — AMANDA, ntp, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba и tcl.
Ресурс Coverity открыт, и с его помощью можно проверить необходимый пакет Open Source на наличие опасных уязвимостей и уровень поддержки проекта разработчиками. Пример анализа для одного из пакетов bind приведён на рис. 7.
Рисунок 7. Анализ ПО bind через проект Synopsys Coverity
Есть несколько аналогичных проектов, занимающихся регулярным тестированием приложений и библиотек Open Source — например, PVS-Studio. Для веб-приложений существует сообщество Open Web Application Security Project (OWASP) — открытый проект по обеспечению их безопасности.
Преимущества и недостатки использования решений Open Source
Переход на использование решений Open Source, как и любая другая парадигма, имеет свои преимущества и недостатки (см. табл. 1).
Таблица 1. Преимущества и недостатки перехода на решения с открытым исходным кодом
| Преимущества | Недостатки |
| Проприетарное ПО вынуждает пользователя принять тот уровень безопасности, который поставщик ПО готов предоставить, а также скорость выпуска исправлений и обновлений. Для проектов Open Source в области ИБ репутационные риски более высоки, поэтому уважающие себя проекты оперативно исправляют критически важные для ИБ уязвимости. | Нужны ещё более чёткие процессы по администрированию и — особенно — обновлению ПО, отслеживать обновления придётся самостоятельно. К тому же открытость кода, в том числе патчей, делает необходимость оперативного обновления ещё более острой. Хакеры тоже умеют читать код и могут понять из него, какую именно уязвимость он закрывает. Проприетарные решения обновляются автоматически или по оповещению от производителя, причём включая компоненты Open Source внутри системы. |
| Открытый код даёт возможность его самостоятельного анализа и доработки. При достаточно большом штате администраторов и разработчиков это — безусловный плюс. | Нет технической поддержки, особенно пользовательского уровня. В основном у проектов есть разработчики (мейнтейнеры) и сообщество, но это — не техническая поддержка, которая возможна с проприетарным ПО. Имеется небольшое количество проектов с платной поддержкой и аналогичными уровнями, как в проприетарных компаниях, например у некоторых версий платформы Linux. |
| В коде Open Source нет программных закладок, бэкдоров и другой скрытой функциональности. Нет жёсткой зависимости от платформы. Можно бесконечно масштабироваться без лицензионных ограничений. Вопрос — только в аппаратном обеспечении. | Наличие возможности анализа кода может дать ложное чувство безопасности. Если большое число аналитиков и пользователей ПО исследуют исходный код, это не гарантирует, что все недостатки безопасности будут обнаружены и исправлены. |
О Software Composition Analyzers
Для осуществления мониторинга и определения потенциальных рисков для компонентов Open Source, используемых в проектах, существует класс решений Software Composition Analyzers — SCA. Основные функции, реализуемые SCA-провайдерами, включают в себя:
- контроль и уведомление на раннем этапе жизненного цикла ПО (SDLC) о рисках, связанных с безопасностью или лицензиями используемых компонентов Open Source и библиотек, и о методах их устранения;
- создание согласованных политик для разных бизнес-единиц и типов приложений;
- создание среды наглядности стратегических рисков для специалистов по безопасности и руководителей по информационной безопасности.
Компания Forrester произвела исследование основных SCA-поставщиков и определила 10 наиболее значимых из них в 2019 г. Это — Flexera, FOSSA, GitLab, JFrog, Snyk, Sonatype, Synopsys, Veracode, WhiteHat Security и WhiteSource. Исследователи проанализировали, оценили их и составили традиционную шкалу для помощи специалистам по безопасности в выборе подходящей платформы (рис. 8).
Рисунок 8. SCA-провайдеры: Forrester Wave, 2019 г.
Выводы
Если ваш продукт не является смежным с ИТ (а, например, сфокусирован на юридических услугах) и ваш ИТ-штат ограничен, решения Open Source, скорее всего, принесут вам больше проблем. Если вы — технологичная компания с собственным штатом разработчиков, то, скорее всего, вопрос о применении открытого ПО для вас уже не стоит — вы давно и успешно его используете. К тому же эти две идеологии неплохо совмещаются.
Для минимизации рисков в данном случае, как и в любой другой сфере, важна грамотная организация процессов, ИТ- и ИБ-гигиены, равно как и внедрение современных технических практик, включая интеграцию процесса обновления зависимостей в повседневную работу команды разработчиков (Update Hygiene), а также тщательный осознанный подбор включаемых в проект компонентов.
