Процессы разработки становятся всё более сложными и зависящими от сторонних инструментариев, что создаёт благоприятные условия для продвижения атак, связанных не с выявлением и эксплуатацией уязвимостей в конечном продукте, а с компрометацией самого процесса разработки (атаки "supply chain", как правило нацеленные на внедрение вредоносных изменений в процессе написания кода, подмену распространяемых компонентов и зависимостей).
Фреймворк учитывает 8 видов атак, связанных с угрозами внесения вредоносных изменений на этапе разработки кода, сборки, тестирования и распространения продукта.
- A. Включение в исходный код изменений, содержащих бэкдоры или скрытые ошибки, приводящие к уязвимостям.
Пример атаки: "Hypocrite Commits" - попытка продвижения в ядро Linux патчей с уязвимостями.
Предлагаемый метод защиты: независимое рецензирование каждого изменения двумя разработчиками. - B. Компрометация платформы управления исходным кодом.
Пример атаки: внедрение вредоносных коммитов с бэкдором в Git-репозиторий проекта PHP после утечки паролей разработчиков.
Предлагаемый метод защиты: Повышение защиты платформы управления кодом (в случае PHP атака была совершена через мало кем используемый HTTPS-интерфейс, допускавший отправку изменений при входе по паролю без проверки SSH-ключа, при том, что для хэширования паролей применялся ненадёжный MD5). - C. Внесение изменений на этапе передачи кода в систему сборки или непрерывной интеграции (собирается код, не соответствующий коду из репозитория).
Пример атаки: внедрение бэкдора в Webmin путем внесения изменений в сборочную инфраструктуру, приведших к использованию файлов с кодом, отличающихся от файлов в репозитории.
Предлагаемый метод защиты: Проверка целостности и идентификация источника поступления кода на сборочном сервере. - D. Компрометация сборочной платформы.
Пример атаки: атака SolarWinds, в ходе которой на этапе сборки было обеспечено внедрение бэкдора в продукт SolarWinds Orion.
Предлагаемый метод защиты: внедрение расширенных мер обеспечения безопасности сборочной платформы. - E. Продвижение вредоносного кода через некачественные зависимости.
Пример атаки: внедрение бэкдора в популярную библиотеку event-stream, через добавление безобидной зависимости с последующим включением в одном из обновлений этой зависимости вредоносного кода (вредоносное изменение не было отражено в git-репозитории, а присутствовало только в готовом NPM-пакете).
Предлагаемый метод защиты: рекурсивное применение требований 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 - наивысший уровень, дополняющий предыдущие уровни следующими требованиями:
- Обязательное рецензирование всех изменений двумя разными разработчиками.
- Все шаги сборки, код и зависимости должны быть полностью декларированы, все зависимости должны быть отдельно извлечены и проверены, а процесс сборки должен выполняться без доступа к сети.
- Применение процесса повторяемой сборки - возможность повторить процесс сборки своими силами и убедиться, что исполняемый файл собран из предоставленных исходных текстов.
Источник: https://www.opennet.ru/opennews/art.shtml?num=55345
(opennet.ru, основная лента)