Управління ризиками ланцюга постачання програмного забезпечення для оборони: фреймворки SCRM, SBOM та оцінка постачальників

Злом SolarWinds у 2020 році став переломним моментом для безпеки ланцюга постачання програмного забезпечення. Зловмисники — згодом атрибутовані до державного актора — впровадили шкідливий код у процес збирання SolarWinds Orion, платформи управління мережею, якою користувалися тисячі організацій, включно з кількома федеральними агентствами США та оборонними підрядниками. Скомпрометоване оновлення програмного забезпечення поширювалось через офіційні канали, підписане легітимним сертифікатом підпису коду SolarWinds, і будь-який автоматизований засіб контролю безпеки не міг відрізнити його від звичайного оновлення. Вісімнадцять тисяч організацій встановили бекдор. Вторгнення залишалося непоміченим протягом місяців.

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

Управління кіберризиками ланцюга постачання (C-SCRM) — це дисципліна, що адресує цей клас загроз. Ця стаття охоплює фреймворк NIST SP 800-161 Rev. 1, який очікується до впровадження оборонними замовниками, технічну основу у вигляді видимості компонентів на базі SBOM, практики оцінки безпеки постачальників, ризики компонентів з відкритим кодом, договірні вимоги DFARS та архітектуру безперервного моніторингу, яка виявляє скомпрометовані залежності після розгортання.

Чому ризики ланцюга постачання ПЗ унікальні для оборони

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

Ризики COTS та відкритого коду становлять проблему з більшою поверхнею атаки. Сучасна оборонна система може включати десятки програмних компонентів COTS — інструменти управління мережею, бази даних, компоненти операційної системи, платформи контейнеризації та бібліотеки зв'язку. Кожен із цих продуктів сам побудований на тисячах компонентів з відкритим кодом із власними спільнотами супроводжувачів, ланцюгами залежностей і потенціалом для компромісу. Бекдор XZ Utils (CVE-2024-3094), виявлений у березні 2024 року, унаочнив цей ризик: зловмисний учасник витратив приблизно два роки на завоювання довіри в проекті XZ Utils, перш ніж впровадити бекдор у процес збирання. XZ Utils забезпечує стиснення даних без втрат і присутній практично в кожному дистрибутиві Linux — включно зі стеками операційних систем у багатьох оборонних розгортаннях.

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

Розробка класифікованих систем вносить додаткові ризики на рівні конвеєра розробки. Інфраструктура збирання, репозиторії вихідного коду, інфраструктура підпису коду та системи розповсюдження артефактів для класифікованих програм самі по собі є цілями. Компроміс конвеєра збирання — навіть для програмного забезпечення, розробленого повністю власними силами — може впровадити шкідливі модифікації між комітом розробника і розгорнутим артефактом. Саме тому примусове застосування SBOM в оборонних конвеєрах дедалі більше включає атестації провенансу збирання (рівні збирання SLSA), які криптографічно прив'язують бінарний артефакт до конкретного вихідного коміту та середовища збирання, яке його створило.

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

Фреймворк C-SCRM NIST SP 800-161 Rev. 1

Спеціальна публікація NIST 800-161 Revision 1 (травень 2022 р.) «Практики управління кіберризиками ланцюга постачання для систем і організацій» є основним фреймворком для C-SCRM у федеральних і оборонних контекстах США. Вона передбачає чотирирівневу модель, що інтегрує управління ризиками ланцюга постачання з ширшою ієрархією управління ризиками організації.

Рівень 1 — Організаційний: Старше керівництво встановлює політику C-SCRM, призначає відповідальність за управління (PMO з C-SCRM або уповноважений виконавець з ризиків), визначає порогові значення апетиту до ризику та розподіляє ресурси. На цьому рівні організація відповідає на стратегічні питання: які категорії ПЗ і постачальників охоплюються C-SCRM? Яка толерантність організації до ризику відомо вразливих компонентів у розгорнутих системах? Який шлях ескалації при виявленні критичного компромісу ланцюга постачання? Без політики Рівня 1 діяльність C-SCRM на нижчих рівнях позбавлена авторизації та управління.

Рівень 2 — Місія/бізнес-процес: Керівники програм та посадові особи у сфері закупівель інтегрують вимоги C-SCRM у закупівельні інструменти, шаблони контрактів та планування програм. На цьому рівні вимоги C-SCRM перетворюються на конкретні вимоги до закупівель: зобов'язання щодо надання SBOM, вимоги до рівня CMMC, стандарти атестації провенансу та часові рамки звітування про інциденти. Саме тут політика C-SCRM стає договірно виконуваною.

Рівень 3 — Рівень інформаційної системи: Власники систем та офіцери безпеки інформаційних систем (ISSO) застосовують засоби контролю C-SCRM під час проектування, розробки, інтеграції та технічного обслуговування системи (O&M). На цьому рівні діяльність C-SCRM включає інвентаризацію компонентів (аналіз SBOM), оцінку ризиків постачальників, відстеження вразливостей розгорнутих компонентів та моніторинг постачальників. План безпеки системи (SSP) повинен включати розділ C-SCRM з документацією впроваджених засобів контролю та їх поточного стану.

Рівень 4 — Рівень постачальника: Підрядники та субпостачальники нижнього рівня реалізують вимоги C-SCRM, спущені до них через контракти. Це включає власне генерування SBOM для поставленого ПЗ, зобов'язання щодо звітування про інциденти, вимоги відповідності CMMC та управління субпостачальниками нижнього рівня. Рівень 4 — це місце, де теорія стикається з практикою: якість впровадження C-SCRM на рівні постачальника безпосередньо визначає ризикову позицію замовної організації.

NIST 800-161 Rev. 1 відображає практики C-SCRM у п'ять функцій фреймворку кібербезпеки NIST (CSF) — Ідентифікація, Захист, Виявлення, Реагування, Відновлення — забезпечуючи зв'язок між C-SCRM та ширшими програмами кібербезпеки, які більшість оборонних організацій вже підтримує. Ключові практики для оборонних замовників у функції «Ідентифікація» включають ведення інвентарю постачальників, аналіз критичності придбаного ПЗ та послуг, а також оцінку ризиків ланцюга постачання. У функції «Захист»: вимоги до SBOM, вимоги до атестації провенансу та управління затвердженим списком постачальників. У функції «Виявлення»: безперервний моніторинг стану безпеки постачальників, підписки на стрічки вразливостей та моніторинг компонентів на основі SBOM.

SBOM як інструмент видимості ланцюга постачання

Перелік матеріалів програмного забезпечення (SBOM) — це машиночитаний реєстр усіх компонентів у програмному артефакті: прямих залежностей, транзитивних залежностей, інструментів часу збирання та шарів базового образу для контейнерних навантажень. У контексті C-SCRM SBOM відповідає на фундаментальне питання видимості ланцюга постачання: що саме знаходиться всередині цього програмного продукту, і чи є серед цих компонентів відомо вразливі або скомпрометовані?

Генерування SBOM за допомогою Syft і Trivy: Два інструменти з відкритим кодом домінують у генеруванні SBOM для оборонних конвеєрів. Syft (від Anchore) генерує SBOM у форматах CycloneDX і SPDX з образів контейнерів, файлових систем та вихідних репозиторіїв. Trivy (від Aqua Security) поєднує генерування SBOM зі скануванням вразливостей в одному проході інструменту. Обидва інструменти підтримують роботу в ізольованих середовищах із локально дзеркалованими базами даних вразливостей — критична вимога для класифікованих середовищ розробки.

Вибір формату SBOM має значення для оборонних контекстів. CycloneDX (наразі версія 1.6) має широку підтримку інструментів та включає поля для провенансу компонентів, статусу патчів та підтвердження вразливостей — функції, важливі для документації оборонних програм. SPDX (Software Package Data Exchange) є форматом, якому надає перевагу NIST, і на який посилаються настанови EO 14028, та має більшу поширеність у спільноті дотримання ліцензій відкритого коду. Багато оборонних програм підтримують обидва формати з одного етапу конвеєра, оскільки різні кінцеві споживачі (сканери вразливостей та інструменти юридичного/IP-аудиту) можуть надавати перевагу різним форматам.

Аналіз SBOM на відомо вразливі компоненти: Після генерування SBOM аналізується відносно баз даних вразливостей. База даних OSV (Open Source Vulnerabilities) агрегує CVE по всіх основних екосистемах мов програмування (PyPI, npm, Maven, Go, Rust, Ruby тощо) і доступна у вигляді бази даних JSON з можливістю локального дзеркалювання — важливо для ізольованих середовищ. NVD (Національна база даних вразливостей) надає авторитетний набір даних CVE з оцінками CVSS. Grype (від Anchore) та osv-scanner (від Google) є основними сканерами SBOM до бази даних вразливостей, що використовуються в оборонних конвеєрах.

Для оборонних програм інтеграція SBOM з інструментальним ланцюгом DevSecOps для оборонних конвеєрів означає, що генерування SBOM та сканування вразливостей виконуються автоматично при кожному збиранні. Результати публікуються на централізованій панелі безпеки, а шлюзи конвеєра відхиляють збирання з компонентами, що містяться у KEV або мають CVSS 9.0+, якщо тільки не існує затвердженого тікету виключення. Артефакт SBOM та результати його сканування на вразливості підписуються і зберігаються разом із артефактом збирання як частина пакету постачання.

Оцінка безпеки постачальників оборонного ПЗ

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

Проектування опитувальника безпеки відповідно до NIST SP 800-171: Основним фреймворком для оцінки безпеки постачальників оборонного ПЗ є NIST SP 800-171 «Захист контрольованої несекретної інформації в нефедеральних системах та організаціях». Опитувальник оцінки постачальника, організований навколо 14 сімейств засобів контролю NIST 800-171, забезпечує структурований і придатний для аудиту підхід до оцінки. 14 сімейств: контроль доступу, навчання та підвищення обізнаності, аудит та підзвітність, управління конфігурацією, ідентифікація та автентифікація, реагування на інциденти, технічне обслуговування, захист носіїв, безпека персоналу, фізичний захист, оцінка ризиків, оцінка безпеки, захист систем і комунікацій, цілісність систем та інформації.

Для кожного сімейства засобів контролю опитувальник має запитувати:

• Які засоби контролю впроваджено? (запитується документальне підтвердження)
• Яка поточна оцінка SPRS та яка методологія використовується для її розрахунку?
• Чи є відкриті пункти Плану дій та етапів (POA&M)? Якщо так, яка цільова дата закриття?
• Чи проходив постачальник будь-яку незалежну оцінку безпеки за останні 24 місяці? Якщо так, ким і за яким стандартом?
• Яким є процес постачальника щодо управління безпекою субпостачальників нижнього рівня?

Вимоги до рівня CMMC: Відповідно до фреймворку сертифікації зрілості кібербезпеки (CMMC), постачальники оборонного ПЗ, які обробляють контрольовану несекретну інформацію (CUI), зобов'язані досягти щонайменше CMMC Рівня 2, який вимагає виконання всіх 110 вимог NIST SP 800-171 та незалежної оцінки організацією незалежної оцінки третьої сторони CMMC (C3PAO). Замовники повинні перевіряти статус сертифікації CMMC постачальника через ринок CMMC AB перед укладенням контракту та вимагати повторної сертифікації, якщо термін дії сертифіката постачальника наближається до закінчення. Для програм, що стосуються чутливих програм закупівлі або тих, що стикаються з загрозами з боку досвідчених стійких акторів, може бути доцільним CMMC Рівень 3 (який додає вимоги NIST SP 800-172).

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

Управління ризиками компонентів з відкритим кодом

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

Дотримання ліцензій OSS — ризик «зараження» GPL: Стаття GPL (GNU General Public License) є копілефт-ліцензією, яка вимагає, щоб похідні твори розповсюджувались за тією ж ліцензією, включно з наданням вихідного коду. Для оборонного ПЗ з власними алгоритмами або класифікованими компонентами ненавмисне включення коду з ліцензією GPL може спричинити зобов'язання щодо публікації вихідного коду, який не повинен бути публічним. LGPL (Lesser GPL) спрацьовує лише при статичному зв'язуванні бібліотеки; AGPL (Affero GPL) спрацьовує навіть для ПЗ, що використовується через мережу без розповсюдження. Сканер відповідності ліцензій — FOSSA (комерційний), Black Duck (комерційний) або інструментарій REUSE з відкритим кодом — має аналізувати кожен компонент у SBOM перед кожним постачанням, з визначеною політикою для кожного типу ліцензії: дозволено, дозволено за умовами (LGPL лише з динамічним зв'язуванням) або заборонено (GPL у контексті виконуваного файлу).

Оцінка ризиків супроводжувачів — це людський вимір ризику OSS. Бекдор XZ Utils був виконаний зловмисним учасником, який витратив приблизно два роки на формування репутації та історії комітів у проекті, перш ніж впровадити бекдор. Оцінка ризиків супроводжувачів передбачає вивчення:

• Кількості активних супроводжувачів та «bus-фактора» (що станеться, якщо єдиний основний супроводжувач стане недоступним або скомпрометованим?)
• Географічного розподілу та організаційної приналежності ключових учасників — чи пов'язані значні учасники з організаціями в країнах, що становлять загрозу для ланцюга постачання?
• Практик випусків і підпису проекту — чи підписані випуски? Чи утримується ключ підпису однією особою або розподілений?
• Реакції проекту на минулі проблеми безпеки — як швидко усувались CVE? Чи реагувала спільнота?
• Оцінки OpenSSF Scorecard — автоматизованого показника «здоров'я» спільноти, що охоплює захист гілок, практики безпеки CI/CD, закріплення залежностей та інші показники

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

Договірні вимоги SCRM та положення DFARS

Вимоги C-SCRM стають юридично виконуваними через контрактні положення. Оборонні закупівлі використовують поєднання обов'язкових положень DFARS та програмно-специфічних вимог SCRM, узгоджених в умовах контракту.

DFARS 252.204-7012 (Захист покритої оборонної інформації та звітування про кіберінциденти) є основоположним положенням для кібербезпеки оборонних підрядників. Його зобов'язання включають: належний захист (впровадження NIST SP 800-171 на всіх системах, що обробляють, зберігають або передають покриту оборонну інформацію), оперативне звітування про кіберінциденти до DoD протягом 72 годин після виявлення, збереження образів скомпрометованих систем протягом 90 днів для потенційної криміналістики DoD, а також надання шкідливого ПЗ, виявленого у зв'язку з повідомленим інцидентом. Для цілей C-SCRM вимога щодо звітування протягом 72 годин є найбільш операційно вимогливою: підрядники повинні мати можливості виявлення, розслідування та звітування, здатні діяти наскрізь у межах цього вікна, включно з інцидентами ланцюга постачання (скомпрометований продукт постачальника, що використовується у середовищі розробки підрядника).

Положення про атестацію провенансу ПЗ — які дедалі частіше включаються до контрактів на оборонне ПЗ після EO 14028 — вимагають від підрядників надавати підписані атестації того, що їхнє ПЗ було вироблено відповідно до визначених практик безпечної розробки. Меморандуми OMB M-22-18 та M-23-16 визначають мінімальні вимоги атестації безпечної розробки ПЗ для федеральних закупівель ПЗ. Ці атестації посилаються на Фреймворк безпечної розробки ПЗ NIST (SSDF) та вимагають конкретних практик: захисту середовища збирання, генерування SBOM, сканування на вразливості перед постачанням та ведення доказів перегляду безпеки. Підрядники мають використовувати атестації провенансу збирання SLSA Build Level 2 або Level 3 для забезпечення криптографічних доказів, що прив'язують поставлений бінарний файл до конкретного вихідного коміту та середовища збирання.

Вимоги щодо передачі субпідрядникам: Зобов'язання підрядника з C-SCRM не закінчуються на межі його організації. Будь-який субпідрядник, який обробляє покриту оборонну інформацію або надає програмні компоненти, що включаються до поставленої системи, повинен отримати еквівалентні вимоги через передачу контрактом. Це включає DFARS 252.204-7012 (обов'язково, де застосовно), зобов'язання щодо надання SBOM, вимоги до рівня CMMC на рівні, еквівалентному необхідному рівню основного підрядника, та зобов'язання щодо повідомлення основного підрядника у визначений строк (зазвичай 24–48 годин) при порушенні безпеки субпідрядника. Основні підрядники несуть договірну відповідальність за перевірку відповідності субпідрядників — «мій субпідрядник був скомпрометований, і я не знав про це» не є прийнятним поясненням для державного замовника.

Обмеження щодо країни походження додають ще один рівень: Розділ 889 NDAA забороняє використання певного телекомунікаційного та відеоспостережного обладнання від визначених виробників у програмах уряду США, а подальші положення NDAA поширили обмеження на програмні компоненти. Шаблони контрактів мають включати явні заборони щодо країни походження відповідно до поточного переліку обмежень NDAA, а аналіз SBOM має позначати компоненти, відоме походження яких або приналежність супроводжувача може викликати занепокоєння.

Безперервний моніторинг SCRM

Статична оцінка SCRM — проведення оцінки постачальника та сканування SBOM при укладенні контракту, а потім зберігання результатів у файлі — надає одноразову картину ризику, яка застаріває вже наступного дня після оцінки. Безперервний моніторинг SCRM підтримує постійну картину ризику, підписуючись на стрічки розвідки вразливостей та автоматично зіставляючи нову розвідку з інвентарем розгорнутих компонентів.

Стрічки попереджень про вразливості: Двома основними стрічками для безперервного моніторингу є CISA KEV та NVD. Каталог відомих експлуатованих вразливостей (KEV) CISA постійно оновлюється і містить CVE, підтверджено активно експлуатовані — вони є цілями виправлення найвищого пріоритету незалежно від оцінки CVSS, оскільки є не теоретичними ризиками, а підтвердженими техніками атак. NVD надає вичерпний набір даних CVE з оцінками CVSS v3.1 та v4.0. Обидві доступні у вигляді машиночитаних JSON-стрічок, придатних для автоматизованого завантаження.

Для контейнерних навантажень практики безпеки образів контейнерів для оборони включають повторне сканування на рівні реєстру: коли публікується нова вразливість, що зачіпає версію пакета ОС, присутню у збережених образах, реєстр (наприклад, Harbor) автоматично повторно сканує уражені образи та позначає їх як такі, що не відповідають політиці вразливостей. Це ініціює сповіщення відповідальній команді без будь-яких ручних дій.

Автоматизоване повторне сканування компонентів при нових CVE: Архітектура автоматизації для безперервного моніторингу SCRM інтегрує три потоки даних: (1) інвентар SBOM (всі компоненти у всіх розгорнутих системах), (2) вхідна розвідка CVE/KEV і (3) система управління тікетами виправлень. Коли публікується новий CVE, автоматизований процес запитує інвентар SBOM на предмет будь-якого розгорнутого компонента, що відповідає ураженому пакету та діапазону версій. Якщо збіг знайдено, автоматично створюється тікет виправлення з пріоритетом, визначеним зі стрічки розвідки (збіг з KEV = P0 негайно, CVSS 9.0+ = P1 наступного робочого дня, CVSS 7.0–8.9 = P2 тікет у спринт). Це усуває ручний крок сортування, який зазвичай затримує виправлення вразливостей в організаціях, що покладаються на циклічне сканування.

Реагування на інциденти при скомпрометованих залежностях: Коли залежність виявляється скомпрометованою — не просто вразливою, а активно бекдорованою, як у випадку XZ Utils — процес реагування відрізняється від виправлення CVE. Ключові кроки:

• Негайне визначення масштабу: Запит інвентарю SBOM для перерахування кожного розгортання, що містить уражену версію компонента. Це має займати хвилини, а не дні — повільне визначення масштабу є відмовою програми C-SCRM.
• Оцінка можливості експлуатації: Визначення, чи був шкідливий код фактично виконаний у контексті розгортання. XZ Utils, наприклад, експлуатувався лише при завантаженні конкретною версією systemd — системи без такої конфігурації не зазнавали впливу, навіть якщо мали встановлений шкідливий пакет.
• Повідомлення протягом 72 годин: DFARS 252.204-7012 вимагає звітування до DoD протягом 72 годин. Повідомлення клієнтів має відбуватися одночасно — а не після завершення внутрішнього розслідування.
• Виправлення та верифікація: Оновлення до чистої версії або активація стратегії форку. Проведення верифікації цілісності системних артефактів, які могли бути вироблені з використанням скомпрометованого компонента.
• Аналіз після інциденту: Визначення, який засіб контролю C-SCRM мав виявити компроміс раніше — недостатнє охоплення SBOM, відсутня оцінка ризиків супроводжувачів, відсутність стратегії форку для критичного компонента — та відповідне оновлення програми.

Організаційний вимір безперервного моніторингу SCRM настільки ж важливий, як і технічний. Хтось має бути власником процесу моніторингу, перебувати на чергуванні для сповіщень P0 та мати повноваження вивести систему з мережі або ініціювати аварійний цикл виправлення при виявленні збігу з KEV або скомпрометованої залежності. Відповідальність за C-SCRM, розподілена між кількома командами без єдиного підзвітного власника, незмінно призводить до затримок реагування — саме того режиму відмови, на який покладаються противники.