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

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

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

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

0_1623931488.png

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

    0_1623936885.png



    Источник: http://www.opennet.ru/opennews/art.shtml? num=55345

©  OpenNet