Alice: Привет, Bob, ты знаешь, что уязвимости во внешних зависимостях твоего проекта — это и твои уязвимости?
Bob: Да. Поэтому у меня есть SCA.
Alice: А как думаешь, SCA для внешних компонент достаточно, чтобы выявить все уязвимости?
Bob: Если мы говорим об известных CVE, то да. Я всегда обновляю базу уязвимостей и регулярно провожу сканы.
Alice: А если уязвимости ещё не были найдены и их нет в базе? Ты просматриваешь сам код внешних зависимостей на уязвимости?
Bob: Ммм… Нет, так почти никто не делает. Это трудозатратно.
Alice: Но ведь код внешних зависимостей — твой код. Может быть, ты тогда, например, запускаешь SAST на код внешних зависимостей?
Bob: Ну, не всегда, мне бы найти время на верификацию всех SAST-результатов моего кода.
Alice: Ладно. А есть ли у тебя какой-то критерий, по которому ты можешь запретить себе использовать стороннюю библиотеку в проекте?
Bob: Наверное, если у библиотеки есть известный CVE, а патча нет. Хотя… Я, скорее всего, просто выжду время, когда выйдет патч, и всё. А к чему ты клонишь?
Alice: А если библиотека не поддерживается и уже не обновляется несколько лет? А если сам разработчик библиотеки с плохой репутацией? А если злоумышленник уже закоммитил закладку в код твоей внешней компоненты, ведь далеко не всё в open source проектах проверяется? Я тут просто прочитала статью, где предлагают оценивать библиотеку на основе состояния самого репозитория сторонней зависимости: популярность, авторский состав, активность сообщества, заинтересованность в безопасности и… В общем, сейчас расскажу!
Eva: Вот это я удачно подслушала!
Это был обычный диалог между Alice и Bob, который удалось подслушать Eva. Теперь попробуем представить, какие злонамеренные действия может предпринять Eva после услышанного. Другими словами, что может произойти, если ваша компания ещё не готова к атакам на цепочку поставок (Supply Chain) через сторонние зависимости, а злоумышленник готов?
Supply Chain ваших зависимостей
Статья, которую прочитала Alice
В современных проектах зависимости стали неотъемлемой частью разработки. Без них сложно представить себе создание программного обеспечения, так как они позволяют использовать готовые решения и тем самым ускоряют процесс разработки. Однако с увеличением числа зависимостей возрастает и количество уязвимых компонентов, что делает проект менее защищённым перед потенциальными угрозами безопасности. Для борьбы с этой проблемой существует инструмент SCA (Software Composition Analysis), который специализируется на выявлении уже известных уязвимостей в зависимостях проекта (CVE) и иногда даже на поиске опасных лицензий.
Попробуем сформулировать общее понятие безопасности цепочки поставок (Supply Chain Security) в контексте разработки: это обеспечение безопасности на всех этапах пути, по которому ПО попадает в организацию, от момента их создания или покупки до этапа использования. Грубо говоря, это слежка за разрабатываемым ПО: откуда, с кем пришло и куда путь свой держит.
Для начала посмотрим, что в ответ на эту задачу предлагает нам ИБ-сообщество.
SLSA (Supply-chain Levels for Software Artifacts)
Фреймворк SLSA — это чеклист требований, которые должны быть учтены в безопасной цепочке поставок (Supply Chain). На момент написания статьи вышла версия 1.0 этих требований. В нем ещё не раскрыты полностью все пункты и рекомендации, но, несмотря на это, именно на него стараются опираться все, кто задумывается об этой проблеме. В рамках стандарта безопасность цепочки поставок оценивается с точки зрения целостности всего процесса разработки ПО: а) исходного кода, б) сборки и в) зависимостей.
а) Целостность исходного кода: убедитесь, что все изменения в исходном коде отражают намерения производителя программного обеспечения. Определить их трудно, поэтому в рекомендациях SLSA — одобрение от двух уполномоченных представителей или, например, проверка целостности при передаче исходного кода.
Пример. Злоумышленник с правами разработчика проекта создаёт pull request с закладкой, который попадает в основной код проекта.
Решение. Без одобрения хотя бы ещё одного участника проекта подобный pull request не попадёт в исходный код.
б) Целостность сборки: убедитесь, что пакет собран из правильного, неизменённого исходного кода и зависимостей, соответствует инструкции сборки, которую определил производитель программного обеспечения, а также, что артефакты не изменяются при переходе между этапами сборки.
Пример: Злоумышленник добавил вредоносный артефакт в кэш сборки, который на следующем этапе считывается и попадает в прод.
Решение: Кэши сборок должны быть изолированы друг от друга.
в) Целостность зависимостей: поскольку в SLSA ещё не описано, как именно митигировать эти риски, предлагается рекурсивно накладывать требования SLSA, применяемые к целостности сборки и исходного кода, и на зависимости.
Пример: Злоумышленник регистрирует имя пакета, похожее на популярное, и, таким образом, обманом заставляет разработчика использовать вредоносный пакет вместо оригинального.
Решение: Ограничение на скачивание пакета со временем жизни меньше трех месяцев.
OWASP Software Component Verification Standard (SCVS)
Стандарт OWASP SCVS, который также направлен на улучшение безопасности и качества цепочек поставок программного обеспечения, сформулирован достаточно кратко и состоит из шести контролей. Они предназначены для поэтапной реализации и улучшения безопасности и качества компонентов ПО.
V1: Необходимость инвентаризации
V2: Требования к содержимому спецификации программного обеспечения (SBOM)
V3: Требования к правильной настройке среды сборки
V4: Требования к управлению пакетами
V5: Анализ компонентов на уязвимости, качество и наличие опасных лицензий
V6: Сбор информации о происхождении пакетов и их модификаций
Каждый контроль имеет свои подпункты, в рамках этой статьи мы их не детализируем.
CIS Software Supply Chain Security Guide
Это руководство описывает этапы цепочки поставок программного обеспечения, начиная с добавления кода разработчиком и заканчивая доставкой ПО клиенту. Гайд согласуется со стандартами безопасности, такими как SLSA и TUF, и включает более 100 рекомендаций в пяти основных категориях. Вот как они сформулированы в настоящее время.
1. Source Code: управление исходным кодом приложения.
2. Build Pipelines: безопасность компонентов конвейера сборки. Нарушения в этой категории как раз приводят к атакам, как мы видели на примере Codecov или SolarWinds.
3. Dependencies: управление зависимостями в процессе сборки и выпуска. К последствиям нарушений этой категории можно отнести, например, уязвимость в библиотеке log4j (Log4shell).
4. Артефакты: безопасность управления артефактами сборки.
5. Deployment: защита процесса развертывания приложения и связанных файлов и конфигураций.
Большинство требований, связанных с обеспечением безопасности цепочки поставок (Supply Chain Security), имеют архитектурный характер и могут быть проверены, например, в процессе аудита компании или используя методы сбора «provenance» и его проверки. Они касаются таких аспектов как, например, ролевая модель пользователей в системах сборки, контроль доступа к интернету для сборочных систем, методы проверки нового кода и многое другое.
В данной статье мы ограничимся рассуждениями на тему зависимостей разрабатываемого ПО в цепочке поставок, где помимо коммерческих решений зачастую присутствуют компоненты с открытым исходным кодом. Попробуем выяснить, как можно оценить риск компрометации каждой зависимости в нашем проекте.
Оценка риска компрометации цепочки поставок для сторонних зависимостей
Мы выяснили, что безопасность цепочки поставок (Supply Chain Security) выходит за пределы традиционного SCA. Попробуем рассмотреть компрометацию цепочки поставок на примере.
Если злоумышленник захотел взломать какую-то крупную компанию, то ему иногда бывает проще скомпрометировать ту или иную зависимость в проекте, чем сам проект. В случае open source зависимостей, контрибьютер — мимопроходящий разработчик — не проверяется никакими корпоративными службами безопасности при внесении изменений в код проекта, а владельцы проектов редко задумываются о безопасности своих репозиториев. Впоследствии та самая крупная компания-мишень самостоятельно занесёт в свой контур вредоносный код из коммита по цепочке поставок (Supply Chain), например, при обновлении зависимостей. Теперь злоумышленник сможет получить доступ к системе через этот код.
Подобной технике отведено отдельное место в матрице Mitre Attack — Supply Chain Compomise. Злоумышленники используют её для получения первоначального доступа в систему. Так было с SolarWinds — самый заметный инцидент случился в 2020 году. Киберпреступники взломали систему компании, а именно Orion, и внедрили вредоносный код в обновление этого продукта. После этого пользователи этого продукта — тысячи компаний и организаций по всему миру — самостоятельно установили скомпрометированное обновление.
Получить доступ к репозиторию open source библиотеки злоумышленник может разными путями. Например, сделать в репозиторий библиотеки pull request с невероятной фичей, но с маленькой закладкой. Или предложить разработчику передать права на его заброшенный репозиторий, чтобы потом самостоятельно внести любой функционал. В ответ на проблему требуется решение с оценкой риска компрометации цепочки поставок для каждой сторонней библиотеки в проекте. Иными словами, нужно задать самый главный вопрос.
Достойна ли ты, библиотека, быть с моим проектом в горе и радости, болезни и здравии?
Почти каждая сторонняя зависимость в проекте имеет ссылку на свой хостинг, где, собственно, и хранится исходный код, чаще всего это Github или Gitlab. Проанализировав репозиторий библиотеки, можно попробовать оценить состояние библиотеки и даже степень риска. Ниже перечислены метрики, с помощью которых можно оценить риски для каждой зависимости в проекте, после чего уже либо принять их, либо полностью отказаться от ее использования.
1. Популярность библиотеки
О чём нам говорит высокая популярность? Обычно о том, что библиотека надежная и работает хорошо. Когда множество разработчиков делает форки, добавляет репозиторий в избранное, активно вносит свой вклад в проект, это может указывать на высокую степень доверия к этой библиотеке. Вероятно, она соответствует стандартам и лучшим практикам разработки. Это должно быть важным фактором при выборе.
Пример: какая NPM-библиотека для работы с zip внушает Вам больше доверия?
2. Авторский состав библиотеки
Оценка авторского состава зависит от квалификации и надежности контрибьютеров. Чтобы избежать проблем, связанных с недобросовестными или злонамеренными контрибьютерами, стоит проверить их на наличие предыдущего негативного опыта или связей со злонамеренными проектами. А опытные и активные разработчики — это, наоборот, признак высокого уровня качества и надежности проекта. Контрибьютеры или владельцы репозитория с пустым или неактивным профилем могут иметь низкую квалификацию в разработке, а то и вовсе могли быть созданы только с целью внесения злонамеренного функционала в репозиторий.
Пример: готовы ли вы со спокойной совестью использовать компоненты от пользователя RIAEvangelist (вот один из его пакетов) после того, как увидели новости ниже?
3. Активность сообщества
Эта метрика позволяет оценить, насколько быстро сообщество реагирует на проблемы и есть ли процессы для их решения. Если сообщество проекта не поддерживает и не обновляет репозиторий, то новые уязвимости могут оставаться незамеченными и неисправленными длительное время. Частота коммитов также является показателем жизнеспособности проекта и уровня интереса к его разработке.
Кстати, в руководстве CIS Software Supply Chain Security Guidelines есть пункт 1.2.7 — ensure inactive repositories are reviewed and archived periodically. Согласно ему необходимо периодически проверять активность репозиториев и не использовать устаревшие.
Пример: готовы ли вы использовать в своем проекте библиотеку, которая несколько лет не обновлялась и уже даже помечена как устаревшая?
4. Заинтересованность в безопасности
Этот полезный индикатор помогает оценить, уделяют ли разработчики внимание безопасности своего проекта. Если разработчики серьезно относятся к этому вопросу и стремятся поддерживать проект в защищённом состоянии, будет видна активность в устранении уязвимостей и включенные функции безопасности в репозитории.
Об этом нам говорят следующие пункты CIS Software Supply Chain Security Guidelines:
1.1.18. Ensure any merging of code is automatically scanned for risks.
1.2.1. Ensure all public repositories contain a SECURITY.md file.
Пример: не правда ли, чуть больше доверия к библиотеке с хорошо оформленным SECURITY.md или, например, с закрытыми проблемами безопасности от dependabot (SCA GitHub'а)?
5. Выполнение требований к изменению кода
SLSA диктует, что после того, как были выполнены проверки целостности кода и сборки основного проекта, необходимо повторить процедуру с зависимостями в коде. Это помогает уменьшить поверхности атаки и увеличить общий уровень безопасности проекта. Например, CIS Software Supply Chain Security Guidelines в пункте 1.1.3 требует рецензии минимум двух людей для внесения изменения в код.
По нашему мнению, open source код пока ещё не готов к таким строгим проверкам, поэтому этот критерий должен пока иметь лишь информативный характер и не сильно влиять на итоговую оценку для библиотеки.
Пробуем на практике
Загрузим SBOM на анализ и посмотрим оценку риска для некоторых его зависимостей. Для автоматизации этого процесса будем использовать инструмент AppScreener с включённой опцией анализа Supply Chain (модуль SCS).
Результат анализа для зависимостей:
Итак, библиотека easy-stack получила низкую оценку Supply Chain — 0,5. Значит, риск компрометации цепочки поставок через эту компоненту высокий. А почему?
● Лейбл «Автор библиотеки недоверенный» и, как следствие, нулевой показатель авторского состава. Владельцем этого пакета является тот самый хактивист RIAEvangelist, о котором мы говорили выше.
● Низкая популярность пакета.
● Низкая активность сообщества.
В такой ситуации рекомендуем разработчику заменить пакет на более доверенный аналог или провести ручной аудит кода для этой зависимости, если замены найти не удастся.
Можно также заметить, что у некоторых библиотек были найдены CVE. Например, пакет semver содержит в версиях ниже 7.2 угрозу ReDoS. С другой стороны, в самом пакете вовремя устраняются найденные уязвимости, сообщество активно, пакет привлекает большое внимание разработчиков. Поэтому и общая оценка 5,0 — безопасности Supply Chain на отлично.
Вывод
Что понял Bob после разговора с Alice
Open source всегда открыт разработчикам для обновления или добавления нового функционала. Это означает, что любой, включая злоумышленника, может предоставить свой код и внести вклад в проект с открытым исходным кодом. По этой причине будем считать, что внешние зависимости проекта — это наиболее уязвимое звено в цепочке поставок, особенно open source зависимости.
К сожалению, статический анализ исходного кода (SAST) не всегда запускается на внешний код, а использование только традиционной системы анализа зависимостей SCA может оказаться недостаточным. При работе с компонентами с открытым исходным кодом требуется проводить анализ самого репозитория кода, оценивать репутацию участников, их активность, время жизни, а также мониторить поведение пакета, чтобы выявлять и предотвращать потенциальные угрозы.
Оценка безопасности цепочки поставок (Supply Chain Security) — важный аспект в обеспечении безопасности ПО. Она может помочь определить дополнительные риски, связанные с использованием программного обеспечения с open source зависимостями. Ведь лучше найти хороший аналог для библиотеки, чем остаться с инцидентом компрометации через цепочку поставок.
Автор: Татьяна Куцовол
ведущий аналитик-исследователь ИБ в ГК «Солар»