Open Source: топ 10 рисков для предприятия

Приложения Open Source требуют правильного внедрения и сопровождения, в противном случае компания может столкнуться со множеством угроз.

Открытый исходный код стал тенденцией в ИТ-компаниях, а затем — и во многих крупных организациях. Возможность переиспользовать и самостоятельно дополнять код, исправлять ошибки создает условия для быстрых инноваций и снижения расходов.

Но есть у Open Source и присущие именно ему негативные особенности, которые связаны с размытой ответственностью за создание и сопровождение этого кода. Эксперты Endor Labs провели систематический анализ этих рисков с привлечением CISO и CTO двух десятков крупных ИТ-компаний, и вот какие приоритеты выстроила эта группа экспертов.

Известные уязвимости

Самым существенным риском были признаны уязвимости как в самом проекте Open Source, так и в его зависимостях, то есть внешних компонентах Open Source, которые загружаются и используются этим проектом. Именно уязвимости в зависимостях могут породить масштабные проблемы для десятков крупных коммерческих пакетов ПО, как это было со скромным компонентом логирования — Apache Log4j (CVE-2021-44228).

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

Компрометация легитимного пакета

Поскольку до 80% кода в проектах Open Source наследуется из других проектов в виде тех самых зависимостей, всегда есть вероятность, что используемые в вашем приложении чужие компоненты будут троянизированы. Это возможно, когда разработчика этих компонентов взламывают или в системе распространения компонентов, то есть менеджере пакетов, обнаруживается уязвимость, допускающая подмену пакета. Тогда внутри вашего приложения неожиданно оказывается чужой вредоносный код, который на практике часто используется для кражи информации или различных нелегальных схем обогащения (спам, рекламное мошенничество, майнинг).

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

Атака «однофамильцев»

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

Меры защиты. Учите разработчиков внимательности. В рамках стандартной процедуры они должны проверять исходный код пакетов перед использованием, уделяя внимания таким странным характеристикам, как наличие зашифрованных фрагментов в коде, перехват несвойственных функций и так далее. Желательно проверять цифровые подписи пакетов (при наличии).

Код без поддержки

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

Меры защиты. Оценивайте зрелость проекта и вероятность его развития/поддержки перед интеграцией в бизнес-процессы и в свой код. Обратите внимание на число разработчиков, сопровождающих проект, и на частоту релизов. Проверяйте, есть ли релизы с продленной поддержкой (LTS) и когда они выходили. Для некоторых стабильных проектов, впрочем, вполне нормальна ситуация, когда релизы нечасты и в них только исправляются ошибки.

Устаревшее ПО

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

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

Неотслеживаемые зависимости

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

Меры защиты. Вести детальный Software Bill of Materials (SBOM), используя инструменты сканирования, которые «видят» даже зависимости, используемые без менеджера пакетов.

Регуляторные и лицензионные риски

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

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

Незрелое ПО

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

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

Неодобренные изменения

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

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

Слишком крупные или слишком малые зависимости

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

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