Атаки на цепочку поставок программного обеспечения (SSC) в последнее время продолжают оставаться одной из наиболее обсуждаемых тем в индустрии кибербезопасности — и не зря: некоторые источники показывают, что за последние три года количество таких атак выросло более чем на 742%.
В условиях такого продолжающегося роста организации продолжают искать способы снижения рисков атак SSC, а различные отраслевые организации продолжают публиковать руководства, чтобы помочь организациям. Последний релиз рекомендаций на эту тему поступил от Национального института стандартов и технологий США (NIST) в его специальной публикации 800-204, также известной как «Стратегии интеграции безопасности цепочки поставок программного обеспечения в конвейеры DevSecOps CI/CD».
Сегодняшние компании, занимающиеся разработкой и доставкой программного обеспечения, все чаще используют для этого облачные среды и технологии, такие как конвейеры CI/CD и методологии DevSecOps.
Такое сочетание технологий и практик позволяет организациям оптимизировать процесс разработки программного обеспечения, автоматизировать задачи и интегрировать инструменты и методы обеспечения безопасности в жизненный цикл разработки программного обеспечения (SDLC) для снижения рисков. Тем не менее, если эти среды и технологии не защищены должным образом, может произойти эксплуатация соответствующих уязвимостей, оказывающая негативное влияние на пользователей ПО.
Оглавление
Вооружение организаций рекомендациями по снижению рисков в цепочке поставок программного обеспечения
Руководство NIST направлено на то, чтобы вооружить организации рекомендациями по снижению рисков и повышению безопасности цепочки поставок ПО. Защита программного обеспечения в контексте CI/CD означает, что оно не будет скомпрометировано на различных этапах сборки, тестирования, упаковки и развертывания.
Как указывает NIST, SSC включает в себя не только результаты конкретных действий, но и гарантии того, что различные действия, которые были выполнены для создания и доставки программного обеспечения, не были скомпрометированы и имеют подтверждающие артефакты и сертификаты.
Атаки SSC будут продолжать расти из-за эффекта масштаба, который цепочка поставок дает злоумышленникам. Вместо того, чтобы атаковать одну организацию, злоумышленники могут нацелиться на востребованного поставщика, услугу или компонент или проект OSS и оказать огромное влияние на широкий круг жертв.
Современный SSC включает в себя множество различных заинтересованных сторон, организаций, отраслей, технологий и сообществ, что невероятно затрудняет реализацию единого унифицированного подхода к управлению и безопасности.
Факторы риска в цепочке поставок программного обеспечения
NIST определяет атаку SSC как трехэтапный сценарий:
- Компрометация артефактов, шагов или участников цепочки поставок ПО
- Распространение
- Эксплуатация
При работе с современными средами разработки программного обеспечения действуют различные сущности и факторы риска. К ним относятся среда разработки, субъекты угроз, векторы атак, цели и типы осуществляемой эксплуатации. Эти факторы могут выглядеть по-разному в разных организациях и отраслях, но в конечном итоге играют роль в любом сценарии компрометации SSC.
Среды разработки представляют собой основной вектор атаки для злоумышленников, желающих осуществить SSC-атаки. Они выглядят особенно привлекательно из-за характера современной распределенной рабочей силы, сценариев использования собственных устройств (BYoD) и сочетания SaaS и внутренних систем управления исходным кодом. Организации должны принимать меры для снижения риска компрометации среды разработки, учетной записи разработчика и связанных с ними конечных точек.
Атаки на цепочку поставок программного обеспечения происходят изнутри и снаружи
В модели угроз рассматриваются как внешние, так и внутренние злоумышленники. Внешние злоумышленники могут различаться в зависимости от причины вредоносной деятельности: начиная с любой кибер-активности до кибер-атак со стороны иностранных государств, стремящихся повлиять на свои противников, их государственные институты и критически важную инфраструктуру.
К числу потенциальных нарушителей также могут относиться злонамеренные инсайдеры, движимые такими мотивами, как недовольство или вымогательство. В этих атаках часто используются различные методы компрометации программного обеспечения в цепочке поставок, такие как фишинг, вредоносное ПО и социальная инженерия.
Векторы атак также могут варьироваться в зависимости от целевой среды, организации и сценария реализации. Они могут включать вредоносное ПО, социальную инженерию или сетевые и физические атаки. Каждый из этих векторов атак требует соответствующего контроля/методики ликвидации последствий, что затрудняет постоянное смягчение каждого вектора атаки, в частности, для крупных организаций со сложной инфраструктурой.
Цели атаки включают исходный код, учетные и конфиденциальные данные. Типы эксплойтов варьируются от таких действий, как создание уязвимостей, кража учетных данных и внедрение вредоносного кода в репозитории ПО. NIST перечисляет надежный набор мер по смягчению последствий: от фундаментальных действий, таких как управление исправлениями и контроль доступа, до аудита и мониторинга, а также приведения в соответствие с применимой нормативной базой.
Конвейеры CI/CD – доверие, цели и безопасные результаты
Современные среды DevSecOps используют платформы и технологии комбинации непрерывной интеграции и непрерывного развертывания ПО в процессе разработки (CI/CD). По мере того, как программное обеспечение проходит различные этапы сборки, упаковки, тестирования и развертывания, на этих этапах создаются метаданные, которые помогают обеспечить уверенность в происхождении программного обеспечения, а также в шагах и мерах, которые были предприняты для его создания.
Нарушение любого из этапов, а также базовых сред и платформ CI/CD может оказать влияние на целостность создаваемых и распространяемых программных артефактов.
Организации должны принимать меры безопасности как для внутреннего (собственного) кода, так и для сторонних компонентов, таких как программное обеспечение с открытым исходным кодом, которое все чаще составляет основную часть современного программного обеспечения, по крайней мере, с точки зрения исходного кода.
В конечном итоге организации стремятся гарантировать, что злоумышленники не смогут вмешиваться в процесс производства программного обеспечения, внедрять вредоносные обновления программного обеспечения или подвергать риску целостность артефактов и действий конвейера CI/CD. NIST предоставляет приведенную ниже таблицу, демонстрирующую артефакты, которым необходимо доверять в типичных средах CI/CD, а также репозиторий, в котором обычно находятся артефакты или от которого они зависят:
| Артефакт | Репозиторий |
| Собственный код – исходный код или двоичный код | Управление цепочками поставок (SCM) |
| Сторонний код – с открытым исходным кодом или коммерческий | Менеджеры артефактов для языка, контейнера и т. д. |
| Сборки | Репозиторий сборок |
| Пакеты | Репозиторий пакетов |
Безопасность цепочки поставок программного обеспечения в конвейерах CI/CD
Теперь, когда мы обсудили некоторые предпосылки, цели безопасности и объекты, участвующие в доверенных конвейерах CI/CD, давайте взглянем на некоторые конкретные действия по обеспечению безопасности SSC, которые NIST предлагает в своих руководствах.
Неудивительно, что NIST и здесь пропагандирует принципы нулевого доверия , учитывая их публикацию 800-207 «Архитектура нулевого доверия». Приведенные рекомендации включают определение ролей для системных операторов, сопоставление их с конкретными разрешениями и реализацию принципа минимизации привилегий в соответствии с концепцией ролевого доступа (RBAC). Подобные действия снижают риск, если учетная запись или активы конкретного субъекта будут скомпрометированы.
NIST также рекомендует автоматизировать использование SAST и DAST, а также декларативно определять разработку и развертывание кода приложения и действий CI/CD с помощью таких методов, как инфраструктура как код (IaC) и политика/конфигурация как код, в которых можно определить настройки времени выполнения в целях безопасности и соответствия требованиям. Рабочие процессы конвейеров CI/CD также должны быть безопасными, включая сборку, отправку/извлечение артефактов из репозиториев, а также обновления программного обеспечения или фиксацию кода.
Рекомендации NIST для сборок
Что касается сборки, рекомендации включают в себя ключевые действия, такие как определение политик сборки и использование изолированных платформ сборки, а также разрешения для тех, кто выполняет действия по сборке. Организациям также следует использовать механизмы обеспечения соблюдения политик и гарантировать, что в процессе сборки программного обеспечения создаются доказательства и свидетельства безопасных процессов сборки.
Они могут включать в себя свидетельства безопасности окружения, процессов, материалов и задействованных артефактов. NIST рекомендует использовать хеширование для включения итогового артефакта сборки, файлов, библиотек и событий, создающих окончательные артефакты.
Затем рекомендуется подписать свидетельства и надежно хранить их, чтобы потом использовать для демонстрации соответствия политике. Это может помочь продемонстрировать, что программное обеспечение было создано уполномоченными организациями и инструментами и в соответствии с определенными политиками.
В дополнение к необходимости безопасной сборки NIST также рекомендует обеспечить безопасность операций pull-push в репозиториях SCM. Это включает в себя извлечение кода разработчиками из репозиториев, его модификацию и последующую отправку кода обратно в репозиторий. Рекомендации включают автоматические проверки безопасности артефактов, обеспечение уверенности в происхождении исходного кода и требование явного одобрения для всех внешних соавторов, желающих получать и извлекать данные из репозитория.
Среди других ключевых рекомендаций NIST советует поддерживать целостность генерации доказательств во время обновлений программного обеспечения, обеспечивать безопасность коммитов кода и безопасность рабочих процессов в конвейерах CD. Злоумышленники могут попытаться стереть или подделать следы обновлений ПО.
Кроме того, чтобы гарантировать, что при фиксации кода не будет вредоносного или уязвимого кода, NIST рекомендует использовать инструменты SAST/DAST в конвейерах CI/CD с широким языковым охватом, а также использовать инструменты анализа состава ПО (SCA) для проверки безопасности компонентов cистемы эксплуатационной поддержки (OSS) и их зависимостей.
Поскольку конвейеры CD вращаются вокруг рабочих процессов, а во многих современных средах используются такие технологии, как контейнеризация, NIST рекомендует убедиться, что развертываемые контейнеры действительно были созданы в ходе установленного процесса сборки и что они были проверены на наличие уязвимостей в соответствии с установленными в организации требованиями.
Наконец, учитывая множество громких разоблачений секретов, произошедших в отрасли в последнее время, NIST рекомендует организациям проверять наличие секретов в коде, таких как ключи или токены доступа, которые могут быть использованы злоумышленниками в гнусных целях.