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

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

Обновлённый стандарт безопасной разработки (ГОСТ Р 56939–2024) определил практики, которые не были отражены в прежней версии стандарта. В частности, в отношении работы со сторонними компонентами описываются подходы к защите цепочки поставки и необходимости применения композиционного анализа ПО.

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

ПРОБЛЕМАТИКА

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

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

Самые популярные способы подобной «доставки» — ​это:

• typosquatting — ​публикация компонента с заведомой опечаткой в названии;
• dependency confusion — ​эксплуатация механизмов управления компонентами;
• malicious code injection — ​инъекция вредоносного кода в тело легитимного пакета.

Кроме того, в последние годы обострилась ситуация с закладками и политизированным саботажем авторов компонентов.

СТАТИСТИКА

Команда CodeScoring обладает собственной экспертностью в части анализа данных о мировом Open Source, чем регулярно делится с сообществом РБПО. Приведём сокращённую статистику:

• ~100 уязвимостей и вредоносных активностей в компонентах обнаруживается ежедневно;
• ~900 вредоносных пакетов выявляется ежемесячно;
• 8 млн — ​мировая база открытых компонентов;
• 90 млн разработчиков участвуют в открытых проектах;
• ~2500 типов открытых лицензий со своими видами ограничений и разрешений.

ХРАНЕНИЕ КОМПОНЕНТОВ В КОНТУРЕ ОРГАНИЗАЦИИ

Если вы не храните компоненты, из которых производится или производилась сборка, пора начать делать это.

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

Одним из ключевых примеров здесь является открытый Nexus Repository OSS.

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

КОНТРОЛИРУЕМЫЙ РЕПОЗИТОРИЙ АРТЕФАКТОВ

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

Такую проверку можно организовать для каждого запроса компонента пользователем.

Например, наше решение для защиты цепочки поставки CodeScoring.OSA позволяет встроиться в процесс запроса компонента разработчиком и произвести проверку на соответствие политике безопасности организации. В случае если компонент нарушает принятые политики, он блокируется, а разработчику даются подробные пояснения, почему так вышло и что делать дальше.

Узнать больше про защиту цепочки поставки с CodeScoring.OSA

КОМПОЗИЦИОННЫЙ АНАЛИЗ, ИЛИ «ИЗ ЧЕГО СОСТОИТ ВАШЕ ПО»

Понятие композиционного анализа на отечественных SDL-пространствах является довольно молодым, но важным и встаёт в один ряд со статическим и динамическим анализами.

Если коротко, то этот вид анализа позволяет ответить на вопрос: «из чего состоит ваш продукт?» и проверить риски.

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

В общей практике применения композиционный анализ разделяется на три части:

1. Инвентаризация всех компонентов в составе ПО. Это крайне важная стадия, которая должна быть выполнена точным образом, с учётом особенностей применяемых языков программирования и окружений сборки. Для ПО на разных языках могут быть свои особенности определения компонентов, например для C/C++.
2. Анализ компонентов. Обогащение информации о компонентах данными об уязвимостях и лицензиях и иными известными факторами компонента: возраст, авторы, количество версий и пр.
3. Рекомендация и действие. После получения результатов анализа производится проверка политик безопасности и может быть выполнено действие: например, заблокировать сборку. Результаты проверки политик должны сопровождаться информацией о выявленных проблемах и предлагать решение, например безопасную версию компонента.

Важным артефактом реализации этапа инвентаризации и анализа является перечень программных компонентов (ППК или SBoM, Software Bill of Materials). Это машиночитаемый документ, который обеспечивает фиксацию результатов в едином формате. Им можно поделиться с коллегами или заказчиком в рамках поставки. Существует два основных формата обмена данными: CycloneDX (OWASP) и SPDX (Linux Foundation). В России больше распространён первый. 

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

За год в продукте без обновлений накапливается ~100 уязвимостей от сторонних компонентов

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

Узнать больше про композиционный анализ с CodeScoring.SCA

ПОЛЬЗА ПРИМЕНЕНИЯ КОМПОЗИЦИОННОГО АНАЛИЗА ДЛЯ РАЗРАБОТЧИКОВ

Применение практики композиционного анализа позволяет разработке комплексно следить за компонентами, которые заносятся в разрабатываемые продукты.

Своевременная актуализация компонентного состава позволяет иметь меньше проблем с обратной совместимостью со старыми версиями компонентов.

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

НА ЧТО ОБРАТИТЬ ВНИМАНИЕ ПРИ ВЫБОРЕ ИНСТРУМЕНТА КОМПОЗИЦИОННОГО АНАЛИЗА

1. Наличие своего агента для инвентаризации компонентов. Наличие своего агента для инвентаризации компонентов, как правило, даёт более полноценную, глубокую, комплексную интеграцию со всем решением. Агент важен для встраивания в систему сборки для получения более точного результата анализа. Использование открытых инструментов, таких как Trivy, cdxgen или dep-scan, накладывает ограничения: вендору приходится учитывать их особенности и зависеть от направления развития этих проектов.
2. Наличие функций, нацеленных на сокращение издержек по работе с инструментом: точность анализа, гибкие политики безопасности, удобство работы с инвентарём и качественные рекомендации.
3. Встраиваемость в действующую автоматизацию разработки. Наличие агента, программных интерфейсов, вебхуков существенно упростит.

ЗАКЛЮЧЕНИЕ

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

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

Реклама. ООО «ПРОФИСКОП», ИНН: 7813227385, Erid: 2VfnxxiV1sW