Компанія 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 могло бути виявлено, що скрипт Bash Uploader, що віддається з сайту codecov.io, не відповідає коду з репозиторію проекту).
- 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