Google представил фреймворк Supply-chain Levels for Software Artifacts для защиты от вредоносных изменений в процессе разработки
Google представил фреймворк Supply-chain Levels for Software Artifacts для защиты от вредоносных изменений в процессе разработки
Google представил фреймворк 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 - наивысший уровень, дополняющий предыдущие уровни следующими требованиями:
- Обязательное рецензирование всех изменений двумя разными разработчиками.
- Все шаги сборки, код и зависимости должны быть полностью декларированы, все зависимости должны быть отдельно извлечены и проверены, а процесс сборки должен выполняться без доступа к сети.
- Применение процесса повторяемой сборки - возможность повторить процесс сборки своими силами и убедиться, что исполняемый файл собран из предоставленных исходных текстов.
Supply chain integrity attacks—unauthorized modifications to software packages—have been on the rise in the past two years, and are proving to be common and reliable attack vectors that affect all consumers of software. The software development and deployment supply chain is quite complicated, with numerous threats along the source ➞ build ➞ publish workflow. While point solutions do exist for some specific vulnerabilities, there is no comprehensive end-to-end framework that both defines how to mitigate threats across the software supply chain, and provides reasonable security guarantees. There is an urgent need for a solution in the face of the eye-opening, multi-billion dollar attacks in recent months (e.g. SolarWinds, Codecov), some of which could have been prevented or made more difficult had such a framework been adopted by software developers and consumers.
SLSA helps to protect against common supply chain attacks. The following image illustrates a typical software supply chain and includes examples of attacks that can occur at every link in the chain. Each type of attack has occured over the past several years and, unfortunately, is increasing as time goes on.
|
Threat |
Known example |
How SLSA could have helped |
|
|
A |
Submit bad code to the source repository |
Linux hypocrite commits: Researcher attempted to intentionally introduce vulnerabilities into the Linux kernel via patches on the mailing list. |
Two-person review caught most, but not all, of the vulnerabilities. |
|
B |
Compromise source control platform |
PHP: Attacker compromised PHP’s self-hosted git server and injected two malicious commits. |
A better-protected source code platform would have been a much harder target for the attackers. |
|
C |
Build with official process but from code not matching source control |
Webmin: Attacker modified the build infrastructure to use source files not matching source control. |
A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering. |
|
D |
Compromise build platform |
SolarWinds: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build. |
Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence. |
|
E |
Use bad dependency (i.e. A-H, recursively) |
event-stream: Attacker added an innocuous dependency and then updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (i.e. attack F). |
Applying SLSA recursively to all dependencies would have prevented this particular vector, because the provenance would have indicated that it either wasn’t built from a proper builder or that the source did not come from GitHub. |
|
F |
Upload an artifact that was not built by the CI/CD system |
CodeCov: Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly. |
Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo. |
|
G |
Compromise package repository |
Attacks on Package Mirrors: Researcher ran mirrors for several popular package repositories, which could have been used to serve malicious packages. |
Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo. |
|
H |
Trick consumer into using bad package |
Browserify typosquatting: Attacker uploaded a malicious package with a similar name as the original. |
SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions. |
What is SLSA
In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus. In its final form, SLSA will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give "SLSA certification" to a particular package or build platform. SLSA is designed to be incremental and actionable, and to provide security benefits at every step. Once an artifact qualifies at the highest level, consumers can have confidence that it has not been tampered with and can be securely traced back to source—something that is difficult, if not impossible, to do with most software today.
SLSA consists of four levels, with SLSA 4 representing the ideal end state. The lower levels represent incremental milestones with corresponding incremental integrity guarantees.
