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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
17-Июн-2021 22:30

Цитировать

Компания 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 - наивысший уровень, дополняющий предыдущие уровни следующими требованиями:
- Обязательное рецензирование всех изменений двумя разными разработчиками.
- Все шаги сборки, код и зависимости должны быть полностью декларированы, все зависимости должны быть отдельно извлечены и проверены, а процесс сборки должен выполняться без доступа к сети.
- Применение процесса повторяемой сборки - возможность повторить процесс сборки своими силами и убедиться, что исполняемый файл собран из предоставленных исходных текстов.

===========
Источник:
OpenNet.RU
===========

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

Похожие новости