Безпека ланцюга постачання ПЗ для оборони: SLSA, провенанс, підпис

Розгорнутий оборонний бінарний файл — це кінець довгого ланцюга довіри. Він почався як вихідний код, написаний розробником, пройшов через десятки open source залежностей, був скомпільований на сервері збірки, упакований, підписаний та просунутий до релізного реєстру ще до того, як потрапив до операційної мережі. Кожна ланка цього ланцюга є мішенню. Державні супротивники неодноразово демонстрували, що найдешевший шлях до зміцненої оборонної мережі — це не парадні двері, а система збірки чи довірена залежність, скомпрометована вище за течією так, що шкідливий код доставляється, підписаний і благословлений власним конвеєром жертви. Безпека ланцюга постачання ПЗ — це дисципліна, яка робить кожну ланку цього ланцюга верифіковною, щоб розгорнутий артефакт можна було криптографічно простежити назад до перевіреного вихідного коду через стійку до підробки збірку.

Модель загроз оборонного ланцюга постачання

Комерційна безпека ланцюга постачання та оборонна безпека ланцюга постачання використовують однаковий словник, але різного супротивника. Комерційна команда переймається вразливою залежністю або випадковим витоком секрету. Оборонна команда мусить припускати добре забезпеченого ресурсами суб'єкта, який витратить місяці на попереднє розміщення імпланту: отруюючи популярний open source пакет, компрометуючи раннер збірки або підмінюючи підроблений компілятор. Вторгнення SolarWinds — де імплант системи збірки вставив бекдор у легально підписане оновлення продукту — є канонічним прикладом, і воно переформувало те, як оборонні закупівлі ставляться до походження ПЗ.

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

Що робить це складнішим для оборони, ніж для комерційного ПЗ, — це модель наслідків. Скомпрометоване комерційне SaaS-оновлення можна відкотити; скомпрометоване завантаження прошивки на розгорнутій радіостанції або корисному навантаженні радіоелектронної боротьби може бути недосяжним, стійким та операційно катастрофічним. Вартість одного підробленого артефакту є асиметричною, тому структура має бути превентивною, а не реактивною — мета полягає в тому, щоб зробити шкідливий артефакт нездатним пройти конвеєр взагалі, а не виявити його після розгортання. Засоби контролю нижче впорядковані від джерела до розгортання саме так, щоб кожна зона закривалася перш ніж наступна успадкує її вихідні дані.

SLSA: модель зрілості для цілісності збірки

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

Рівень 1 вимагає лише, щоб процес збірки створював провенанс: опис того, як було виготовлено артефакт. Це само по собі вловлює помилки та забезпечує базу для аналізу, але провенанс ще не захищений від підробки.

Рівень 2 вимагає хостованої служби збірки, що генерує та підписує провенанс. Оскільки засвідчення створює служба, а не робоча станція розробника, підробка скомпрометованою окремою машиною стає виявлюваною.

Рівень 3 зміцнює саму платформу збірки: провенанс стає непідробним, а збірки виконуються в ізольованих, ефемерних середовищах, що не несуть стану між запусками. Це рівень, на якому скомпрометована залежність чи шкідливий скрипт збірки вже не можуть мовчки переписати те, що повідомляє провенанс. Для місійного ПЗ SLSA Рівень 3 слід трактувати як базовий, а не як прагнення.

Позиція найвищого рівня гарантій — історично описана як Рівень 4 і нині виражена через додаткові вимоги треку — додає перевірку двома особами кожної зміни та герметичні, відтворювані збірки. Відтворювана збірка дозволяє незалежній стороні перезібрати той самий вихідний код і підтвердити, біт за бітом, що вона отримує той самий артефакт. Для прилеглих до озброєння чи криптографічних компонентів відтворюваність є найсильнішим доступним захистом проти підробленого інструментарію.

Провенанс збірки: як було виготовлено артефакт

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

Провенанс закриває цей розрив. Засвідчення провенансу — це підписаний, машиночитаний запис, що описує вихідний коміт, ідентичність збирача, параметри збірки та криптографічні дайджести кожного входу та виходу. Широко використовуваним форматом є in-toto засвідчення, яке фіксує це як структуроване твердження, що підписує платформа збірки — а не розробник. Коли верифікатор пізніше перевіряє артефакт, він підтверджує не лише підпис, а й те, що провенанс називає очікуваний вихідний репозиторій, очікуваного збирача та коміт, що пройшов перевірку.

Що перевіряє верифікатор

Перевірка провенансу під час розгортання відповідає на точне питання: чи був цей самий артефакт зібраний з того вихідного коду та процесу, який ми очікуємо? Верифікатор порівнює дайджест артефакту з дайджестом, записаним у провенансі, підтверджує, що провенанс був підписаний ключем довіреної платформи збірки, і стверджує, що ідентичність збирача та URI джерела відповідають списку дозволених. Невідповідність — артефакт, чий провенанс називає невідомого збирача, або чий дайджест не збігається — відхиляється перш ніж він досягне операційного середовища. Це той засіб контролю, який позначив би підміну в стилі SolarWinds.

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

Підпис артефактів в оборонних конвеєрах

Підпис залишається необхідним; він просто недостатній сам по собі. Сучасна практика — це безключовий підпис, підкріплений журналом прозорості: ефемерний ключ видається проти верифікованої ідентичності робочого навантаження, використовується для підпису артефакту та його засвідчень, а подія підпису записується до журналу прозорості, що дозволяє лише додавання — публічного чи приватного. Це усуває операційний тягар і ризик довговічних ключів підпису, що живуть на серверах збірки.

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

Верифікація залежностей та SBOM

Більшість коду в будь-якому сучасному оборонному застосунку не написана програмою — він втягується як open source залежності. Тому верифікація цих залежностей є засобом контролю з найбільшим важелем у всьому ланцюзі. Тут поєднуються кілька практик.

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

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

Сканування вразливостей. Кожна залежність сканується за даними про вразливості, такими як OSV advisory database, і результати контролюють просування. Результатом перелічення кожного транзитивного компонента є програмна специфікація матеріалів (software bill of materials). Щодо обумовлених закупівлями вимог, які тепер прикріплені до цього артефакту, дивіться наш аналіз програмної специфікації матеріалів (SBOM) для оборони. SBOM генерується у стандартному форматі — CycloneDX або SPDX — та прикріплюється до артефакту як підписане засвідчення, тож він подорожує разом із бінарним файлом.

Застосування політики: шлюз допуску

Жоден із цих засобів контролю не має значення, якщо вони не блокують невідповідний артефакт від розгортання. Точка застосування — це шлюз допуску, момент безпосередньо перед тим, як артефакт буде просунуто до релізного реєстру або розгорнуто в операційному середовищі. На цьому шлюзі механізм політик виконує набір обов'язкових перевірок: він верифікує підпис артефакту, валідує провенанс відносно очікуваних ідентичностей джерела та збирача, перевіряє SBOM за даними про вразливості та списком заборонених компонентів і підтверджує, що зміна пройшла потрібну перевірку двома особами.

Критичне правило проєктування полягає в тому, що політика мусить блокувати, а не просто позначати. Поширена невдача — запускати сканери раніше в конвеєрі, які видають попередження, тоді як крок просування не має жорсткого шлюзу — тож позначений артефакт усе одно відвантажується, коли інженер переважає рішення під тиском дедлайну. Шлюз допуску мусить безпечно відмовляти: якщо провенанс не можна верифікувати, артефакт не розгортається. Вбудовування цих шлюзів як коду, перевіреного та з контролем версій, як і будь-який інший етап конвеєра, є природним розширенням практики DevSecOps для оборони, де засоби контролю безпеки є частиною кожного спринту, а не передрелізним аудитом.

Експлуатація ланцюга в засекречених середовищах

У ізольованому (air-gapped) чи засекреченому анклаві весь ланцюг мусить працювати без доступу до інтернету. Внутрішні дзеркала тримають перевірені залежності, служба збірки та журнал прозорості працюють всередині анклаву, а ключі верифікації розповсюджуються через схвалені канали. Оновлення дзеркала залежностей надходять через контрольовані міждоменні передачі, кожна з яких несе власний провенанс, тож анклав може повторно верифікувати походження перед допуском пакета. Проєктування ланцюга постачання для офлайн-роботи з першого спринту — а не його дооснащення — це те, що робить різницю між структурою контролю, яка переживає акредитацію, і тією, що руйнується при зіткненні зі справжнім засекреченим розгортанням.