Google представив фреймворк «Рівні ланцюга поставок для артефактів програмного забезпечення» для захисту від шкідливих змін під час процесу розробки

Компанія Google представила  фреймворк Supply-chain Levels for Software Artifacts для захисту від шкідливих змін в процесі розробки, який узагальнює існуючий досвід захисту інфраструктури розробки від атак, здійснюваних на етапі написання коду, тестування, побудови і поширення продукту.

Процеси розробки стають все більш складними і залежними від сторонніх інструментів, що створює сприятливі умови для просування атак, пов'язаних не з виявленням і експлуатацією вразливостей в кінцевому продукті, а з компрометацією самого процесу розробки (атаки ланцюга поставок, зазвичай спрямовані на впровадження шкідливих змін в процес написання коду, заміну розподілених компонентів і залежностей).

Фреймворк враховує 8 видів атак, пов'язаних з загрозами внесення шкідливих змін на етапі розробки коду, побудови, тестування і поширення продукту.

• А. Включення в вихідний код змін, що містять бекдори або приховані помилки, які призводять до вразливостей.

  Приклад атаки: "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 - вимагає, щоб процес побудови був повністю автоматизований і генерував метадані ( "провенанс") про те, як збираються артефакти, включаючи інформацію про вихідний код, залежності і процесі побудови (для GitHub Actions передбачений приклад генератора метаданих для аудиту). SLSA 1 не включає елементи захисту від зловмисного програмного забезпечення, а лише ідентифікує код найпростішим способом і надає метадані для управління вразливостями та аналізу ризиків.
• SLSA 2 - розширює перший шар, вимагаючи використання системи контролю версій і побудови сервісів, що генерують аутентифіковані метадані. Використання SLSA 2 дозволяє відстежувати походження коду і запобігає несанкціоновані зміни коду, в разі довірених сервісів збірки.
• SLSA 3 - підтверджує, що вихідний код і платформа збірки відповідають вимогам стандартів, які гарантують можливість аудиту коду і забезпечують цілісність наданих метаданих. Очікується, що аудитори сертифікуватимуть платформи на відповідність вимогам стандартів.
• SLSA 4 - вищий рівень, доповнюючи попередні рівні наступними вимогами:
  • Обов'язковий розгляд всіх змін двома різними розробниками.
  • Всі кроки збірки, код і залежності повинні бути повністю оголошені, всі залежності повинні бути окремо витягнуті і перевірені, а процес збірки повинен працювати без доступу до мережі.
  • Застосування повторюваного процесу збірки - це можливість повторити процес збірки самостійно і переконатися, що виконуваний файл побудований з наданого вихідного коду.

Атаки на цілісність ланцюга поставок - несанкціоновані модифікації пакетів програмного забезпечення - зростають протягом останніх двох років і виявляються загальними та надійними векторами атак, які впливають на всіх споживачів програмного забезпечення. Ланцюжок поставок розробки та розгортання програмного забезпечення досить складний, з численними загрозами вздовж джерела ➞ побудувати ➞ опублікувати робочий процес. Хоча точкові рішення дійсно існують для деяких конкретних вразливостей, не існує комплексної наскрізної структури, яка визначає, як пом'якшити загрози по всьому ланцюжку поставок програмного забезпечення, так і забезпечує розумні гарантії безпеки. Існує нагальна потреба у вирішенні проблеми, що відкривають очі, багатомільярдних атак в останні місяці (наприклад , SolarWinds, Codecov), деякі з яких можна було б запобігти або ускладнити, якби така структура була прийнята розробниками та споживачами програмного забезпечення.

SLSA допомагає захиститися від поширених атак ланцюга поставок. Наступне зображення ілюструє типовий ланцюжок поставок програмного забезпечення та включає приклади атак, які можуть відбуватися на кожній ланці ланцюга. Кожен вид атаки відбувався протягом останніх кількох років і, на жаль, збільшується з плином часу.

Що таке SLSA

У своєму нинішньому стані SLSA - це набір поступово прийнятих керівних принципів безпеки, які встановлюються галузевим консенсусом. У своїй остаточній формі SLSA буде відрізнятися від списку найкращих практик своєю застосовністю: вона підтримуватиме автоматичне створення метаданих, які можна перевірити, які можна подавати в програмні двигуни, щоб надати «сертифікацію SLSA» певному пакету або платформі для створення. SLSA розроблена таким чином, щоб бути інкрементальною та дієвою, а також забезпечувати переваги безпеки на кожному кроці. Як тільки артефакт кваліфікується на найвищому рівні, споживачі можуть бути впевнені, що він не був підроблений і може бути надійно простежений до джерела - те, що сьогодні важко, якщо не неможливо, зробити з більшістю програмного забезпечення.

SLSA складається з чотирьох рівнів, при цьому SLSA 4 представляє ідеальний кінцевий стан. Нижні рівні являють собою інкрементні віхи з відповідними інкрементними гарантіями цілісності.