Питання про те, чи є програмне забезпечення з відкритим вихідним кодом (OSS) прийнятним в оборонних системах, було в основному вирішено у 2000-х та 2010-х роках: відповідь — так, за умови відповідного управління. Меморандум Міністерства оборони США 2009 року щодо програмного забезпечення з відкритим вихідним кодом був одним із перших формальних заяв про те, що OSS повинне оцінюватися за тими самими критеріями, що і пропрієтарне програмне забезпечення. Ця дозвільна, але контрольована позиція тепер є фактично універсальною серед оборонних закупівельних рамок у демократичних країнах.

Поточний виклик полягає не в тому, чи використовувати OSS, а в тому, як ним суворо управляти. Інцидент із бекдором XZ Utils 2024 року, в якому зловмисник протягом двох років вибудовував репутацію у проекті з відкритим вихідним кодом перед введенням складного бекдору, продемонстрував, що ризики ланцюга поставок OSS не є теоретичними.

Поточна дозвільно-керована позиція щодо OSS

Поточна позиція Міністерства оборони США щодо OSS зафіксована в кількох документах: меморандум CIO 2009 року, рекомендації Ради оборонних інновацій 2016 року та Стратегія модернізації програмного забезпечення DoD 2022 року. Незмінний лейтмотив: OSS не є за своєю суттю більш чи менш безпечним, ніж пропрієтарне програмне забезпечення — безпека залежить від конкретного компонента, практик розробки його спільноти та управління, що застосовується організацією-споживачем.

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

Ризики ланцюга поставок: тайпосквотинг, шкідливі оновлення та занедбані бібліотеки

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

Шкідливі оновлення. Легітимний, широко використовуваний пакет може стати інструментом зловмисного програмного забезпечення, якщо його супровідники будуть скомпрометовані або замінені ворожими акторами. Інцидент із XZ Utils є найбільш складним прикладом. Пом'якшення вимагає закріплення конкретних версій замість автоматичного прийняття оновлень до останньої версії та моніторингу аномальних змін у поведінці пакетів між версіями.

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

Дотримання ліцензій. Ліцензії з відкритим вихідним кодом накладають зобов'язання на споживачів. Ліцензії з авторським лівом (GPL, AGPL) можуть вимагати розкриття похідного вихідного коду — створюючи правові та безпекові ризики для оборонних програм, які не можуть розкрити вихідний код через класифікацію або конкурентні міркування.

Процес схвалення OSS: перевірка ліцензій, сканування вразливостей та походження

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

Сканування вразливостей оцінює конкретну версію компонента, що розглядається для включення, на відповідність відомим базам даних вразливостей (NVD, OSV.dev, GitHub Advisory Database). Оцінка повинна охоплювати не лише сам компонент, але й його транзитивні залежності. Сканування вразливостей у момент включення необхідне, але недостатнє; воно повинне повторюватися безперервно в міру розкриття нових вразливостей.

Оцінка походження оцінює надійність розробки та дистрибуції компонента: особистість та послужний список супровідників; чи має проект процес розкриття вразливостей безпеки; чи підписані випуски; чи практики розробки проекту забезпечують розумну впевненість у навмисній якості.

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

SBOM як інструмент управління залежностями OSS

Software Bill of Materials (SBOM) — це формальний, машинозчитуваний реєстр усіх програмних компонентів у системі — включаючи бібліотеки з відкритим вихідним кодом, комерційні готові компоненти та внутрішньо розроблені модулі — з їхніми версіями, ліцензіями та відносинами залежностей. SBOM дедалі частіше вимагається для оборонного програмного забезпечення.

Для управління OSS зокрема SBOM надає дві можливості, які інакше важко досягти в масштабі. По-перше, він забезпечує автоматичну кореляцію вразливостей: коли розкривається нова вразливість (наприклад, публікується CVE для конкретної версії OpenSSL), вона може бути автоматично зіставлена з SBOM для ідентифікації всіх програм, що включають уражену версію. По-друге, SBOM забезпечує моніторинг дотримання ліцензій у всьому дереві залежностей, включаючи транзитивні залежності.

Ефективні програми SBOM інтегрують генерацію SBOM у конвеєр CI/CD, щоб SBOM завжди відповідав фактично розгорнутому коду, а не був точковим документом, що відривається від реальності в міру оновлення компонентів. Стандарти форматів SBOM (CycloneDX, SPDX) є зрілими та широко підтримуються інструментами.