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

Компания Google представи рамка SLSA (Supply-chain Levels for Software Artifacts), която обобщава съществуващия опит в защитата на инфраструктурата за разработка от атаки, осъществявани по време на написването на кода, тестването, изграждането и разпространението на продукта.

Процесите по разработка стават все по-сложни и зависими от външни инструменти, което създава благоприятни условия за атаки, свързани не с откритие и експлозия на уязвимости в крайния продукт, а с компрометиране на самия процес на разработка (атаки „supply chain“, като правило, нацелени на внедряване на злонамерени изменения по време на написването на кода, подмяна на разпространявани компоненти и зависимости).

Рамката отчита 8 вида атаки, свързани с рискове от внезапни изменения на етапа на разработване на кода, изграждане, тестване и разпространение на продукта.

• A. Включване в изходния код на изменения, съдържащи backdoors или скрити грешки, водещи до уязвимости.

  Пример за атака: „Hypocrite Commits“ — опит за внедряване на пачове с уязвимости в ядрото на Linux.

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

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

  Пример за атака: внедряване на злонамерени комити с backdoor в Git репозитория на проекта PHP след изтичане на пароли на разработчиците.

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

• C. Внесение на изменения на етапа на предаване на кода в системата за изграждане или непрекъсната интеграция (събира се код, който не съответства на кода от репозитория).

  Пример за атака: внедряване на backdoor в Webmin чрез промени в изграждащата инфраструктура, довело до използване на файлове с код, различаващи се от файловете в репозитория.

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

• D. Компрометиране на изграждащата платформа.

  Пример за атака: атака на SolarWinds, при която по време на изграждането е осигурено внедряването на backdoor в продукта SolarWinds Orion.

  Предложен метод за защита: внедряване на разширени мерки за сигурност на изграждащата платформа.

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

  Пример за атака: внедряване на backdoor в популярна библиотека 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