Open Source Security

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

Угрозы, связанные с использованием Open Source-компонентов

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

• Подменять легитимные пакеты данных. В результате в приложение попадает вредоносный код, который может использоваться злоумышленниками для кражи персональной информация и финансов пользователей.
• Использовать неотслеживаемые зависимости и внедрять вредоносные компоненты в заимствованные фрагменты кода.
• Создавать «однофамильцев» — пакеты с именами, очень похожими на легитимные. Разработчики могут, не заметив подмены, загрузить такой пакет и создать заведомо уязвимое приложение.

Также угрозы безопасности ПО могут возникнуть, если разработчики использовали устаревшие библиотеки, пакеты из которых давно не проверялись на уязвимости. Если авторы приложений пренебрегают Open Source Security, практически 100% готовых продуктов будут иметь слабые места. Кроме того, могут возникнуть проблемы с лицензированием.

Теперь о последствиях, которые могут ожидать пользователей небезопасного ПО:

• Утечка конфиденциальной информации и финансов.
• Репутационный ущерб.
• Сбои в работе корпоративных сервисов.

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

Software Composition Analysis (SCA)

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

Алгоритм выполнения SCA-анализа:

• Загрузка файлов сборки программного обеспечения в автоматический анализатор.
• Сканирование кодовой базы с применением эффективных тактик идентификации. Например, анализатор может вычислять хеши анализируемого продукта и сравнивать их с перечнем сторонних компонентов.
• Проверка заимствованных компонентов на наличие слабых мест. Она реализуется путем сравнения с общедоступными базами уязвимостей. Некоторые анализаторы, например, Solar appScreener, также используют собственные базы уязвимых компонентов.
• После анализа безопасности Open Source формируются отчеты с перечнем обнаруженных проблем заимствованных компонентов.

SCA-анализ можно интегрировать в цикл безопасной разработки программных продуктов — DevSecOps и выполнять уже на первых этапах.

Supply Chain Security для контроля безопасности Open Source

SCS-анализ — проверка безопасности цепочек поставок, которые складываются из:

• Лиц, причастных к написанию программного кода.
• Репозиториев, откуда были заимствованы компоненты.
• Зависимостей компонентов кода.
• Используемых инструментов и технологий.

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

Что проверяется в ходе SCS-анализа:

• Используемые программистами технологии.
• Действия лиц, причастных к разработке (поставщиков компонентов, авторов ПО, тестировщиков).
• Компоненты Open Source.

Метод Open Source Security можно реализовать с помощью автоматического анализатора, который отдельно проверит каждый компонент и выставит оценки доверия. По результатам исследования цепочки поставок можно предположить, какие угрозы вероятны для ПО, даже если в момент проверки уязвимости не обнаружены. То есть SCS, в отличие от SCA, не указывает на слабые места — он направлен на профилактику рисков.

Решения о безопасности Open Source-компонентов принимаются на основе нескольких метрик. Например, в анализаторе Solar appScreener это:

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

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

Для реализации подхода Open Source Security SCS-анализ целесообразно применять на этапе разработки программных продуктов в комплексе с другими видами тестирований. Это даст возможность принять меры для минимизации рисков появления уязвимостей.

Преимущества использования анализатора Solar appScreener для Open Source Security

Сертифицированный анализатор Solar appScreener предназначен для комплексного контроля безопасности программных продуктов и реализации подхода Open Source Security. С помощью платформы можно проводить проверки SCA, SCS и анализ лицензионных рисков с целью обнаружить проблемы с лицензиями и избежать юридических проблем. Эти методы контроля безопасности ПО объединены в единый модуль — OSA. Его функции:

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

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

Лучшие практики безопасности при работе с Open Source-компонентами

Как на высоком уровне поддерживать безопасность приложений с открытым исходным кодом:

• Внедрить подход Open Source Security на этапе разработки программных продуктов.
• Комбинировать несколько методик анализа кода для получения более достоверных результатов.
• Тестировать код как на начальном этапе разработки, так и уже после выпуска продуктов.
• Регулярно обновлять ПО.

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