Викиновости

Google предложил SLSA для защиты от вредоносных изменений в процессе разработки

17 июня 2021 года

Компания Google представила фреймворк SLSA (Supply-chain Levels for Software Artifacts), в котором обобщён имеющийся опыт по защите инфраструктуры разработки от атак, осуществляемых на стадии написания кода, тестирования, сборки и распространения продукта.

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

Фреймворк учитывает 8 видов атак, связанных с угрозами внесения вредоносных изменений на этапе разработки кода, сборки, тестирования и распространения продукта.

  • A. Включение в исходный код изменений, содержащих бэкдоры или скрытые ошибки, приводящие к уязвимостям.

Пример атаки: "Hypocrite Commits" - попытка продвижения в ядро Linux патчей с уязвимостями.

Предлагаемый метод защиты: независимое рецензирование каждого изменения двумя разработчиками.

  • B. Компрометация платформы управления исходным кодом.

Пример атаки: внедрение вредоносных коммитов с бэкдором в Git-репозиторий проекта PHP после утечки паролей разработчиков.

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

  • C. Внесение изменений на этапе передачи кода в систему сборки или непрерывной интеграции (собирается код, не соответствующий коду из репозитория).

Пример атаки: внедрение бэкдора в Webmin путем внесения изменений в сборочную инфраструктуру, приведших к использованию файлов с кодом, отличающихся от файлов в репозитории.

Предлагаемый метод защиты: Проверка целостности и идентификация источника поступления кода на сборочном сервере.

  • D. Компрометация сборочной платформы.

Пример атаки: атака SolarWinds, в ходе которой на этапе сборки было обеспечено внедрение бэкдора в продукт SolarWinds Orion.

Предлагаемый метод защиты: внедрение расширенных мер обеспечения безопасности сборочной платформы.

  • E. Продвижение вредоносного кода через некачественные зависимости.

Пример атаки: внедрение бэкдора в популярную библиотеку event-stream, через добавление безобидной зависимости с последующим включением в одном из обновлений этой зависимости вредоносного кода (вредоносное изменение не было отражено в git-репозитории, а присутствовало только в готовом MNP-пакете).

Предлагаемый метод защиты: рекурсивное применение требований SLSA ко всем зависимостям (в случае event-stream проверка бы выявила сборку кода, не соответствующего содержимому основного Git-репозитория).


  • F. Загрузка артефактов, не созданных в системе CI/CD.

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

Предлагаемый метод защиты: контроль за источником и целостностью артефактов (в случае с CodeCov могло быть выявлено, что отдаваемый с сайта codecov.io скрипт Bash Uploader не соответствует коду из репозитория проекта).

  • G. Компрометация репозитория пакетов.

Пример атаки: исследователям удалось развернуть зеркала некоторых популярных репозиториев пакетов с целью распространения через них вредоносных пакетов.

Предлагаемый метод защиты: Проверка, что распространяемые артефакты собраны из заявленных исходных текстов.

  • H. Введение в замешательство пользователя для установки не того пакета.

Пример атаки: использование тайпсквоттинга ( NPM, RubyGems, PyPI) для размещения в репозиториях пакетов, похожих по написанию на популярные приложения ( например, coffe-script вместо coffee-script).

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

  • SLSA 1 - требует, чтобы сборочный процесс был полностью автоматизирован и генерировал метаданные ("provenance") о том, как артефакты собраны, включая сведения об исходных текстах, зависимостях и процессе сборки (для GitHub Actions предложен пример генератора метаданных для аудита). SLSA 1 не включает элементы защиты от внесения вредоносных изменений, а лишь простейшим образом идентифицирует код и предоставляет метаданные для управления уязвимостями и анализа рисков.
  • SLSA 2 - расширяет первый уровень требованием использования системы управления версиями и сборочных сервисов, генерирующих аутентифицированные метаданные. Применение SLSA 2 позволяет отследить происхождение кода и предотвращает внесение несанкционированных изменений в код, в случае применения заслуживающих доверия сборочных сервисов.
  • SLSA 3 - гарантирует, что исходные тексты и сборочная платформа соответствуют требованиям стандартов, гарантирующих возможность проведения аудита кода и обеспечение целостности предоставленных метаданных. Предполагается, что аудиторы могут сертифицировать платформы на предмет соответствия требованиям стандартов.
  • SLSA 4 - наивысший уровень, дополняющий предыдущие уровни следующими требованиями:
  • Обязательное рецензирование всех изменений двумя разными разработчиками.
  • Все шаги сборки, код и зависимости должны быть полностью декларированы, все зависимости должны быть отдельно извлечены и проверены, а процесс сборки должен выполняться без доступа к сети.
  • Применение процесса повторяемой сборки - возможность повторить процесс сборки своими силами и убедиться, что исполняемый файл собран из предоставленных исходных текстов.

Источники править


 
 
Creative Commons
Эта статья содержит материалы из статьи «Google предложил SLSA для защиты от вредоносных изменений в процессе разработки», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию.
 
Эта статья загружена автоматически ботом NewsBots и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.



Источник — https://ru.wikinews.org/w/index.php?title=Google_предложил_SLSA_для_защиты_от_вредоносных_изменений_в_процессе_разработки&oldid=14907981