Ризик, який є новим, а не просто швидшим
Підключення не того пакета з відкритим кодом — не нова проблема: безпека ланцюга поставок роками бореться зі шкідливими та вразливими залежностями. Нове тут — швидкість і відсутність контрольної точки: AI-агент може запропонувати, а розробник — прийняти нову залежність за той час, який раніше йшов на написання однієї функції вручну, — часто без паузи, коли хтось раніше запитував: «а чи справді ми довіряємо цьому пакету?»
Чому статичні SBOM більше не достатні
SBOM (специфікація складу ПЗ), згенерований одноразово під час збірки, і раніше був знімком стану, який застарівав одразу після додавання нової залежності. Коли нові залежності може вносити агент прямо посеред сесії — з тією швидкістю, з якою розробник приймає його пропозиції, — SBOM, зафіксований на певний момент часу, описує систему, яка вже змінилася. Тенденція, що формується, — це перехід до живих, безперервно оновлюваних SBOM, інтегрованих з аналітикою вразливостей у реальному часі, а не до документа для звітності, який складають для аудиту й забувають.
Процес зі статичним SBOM — це як друкувати карту міста, де дороги змінюються щодня. Вона точна в момент створення і дедалі більше застаріває потім — а це набагато серйозніша проблема, коли темп змін зріс через те, що нові маршрути пропонує агент, а не людина.
Ставлення до агентів як до повноцінних, підзвітних учасників
- Нелюдська ідентичність. Практика, що формується, — її іноді називають MLSecOps, тобто застосування дисципліни DevSecOps до розробки за участі AI, — полягає в тому, щоб надавати кожному AI-агенту власну відстежувану ідентичність, так само як її отримує сервісний обліковий запис, замість того щоб його дії анонімно розчинялися в журналі активності розробника-людини.
- Аудит того, що він підключає. Кожен пакет чи залежність, яку вносить агент, фіксується в журналі та перевіряється на відповідність політиці — ліцензія, відомі вразливості, стан підтримки — через той самий контроль, що й додавання залежності людиною, а не через полегшену версію.
- Походження моделі та вагових коефіцієнтів. Якщо самі AI-моделі є частиною вашого продукту, вони теж потребують документації — походження навчальних даних, архітектурні рішення, тести безпеки — і їх слід відстежувати як будь-яку іншу залежність, адже модель нею і є.
- Скорочення часу від виявлення до виправлення. Мета — не сповільнювати агентів ручними перевірками на кожному кроці, а впровадити автоматизовані перевірки політик, які виявляють проблему за хвилини замість того, щоб ручний аудит виявляв її через тижні, — при цьому людина затверджує виправлення, а не просто формально підписує перевірку.
Як це виглядає на практиці
| Стара модель | Модель, що формується |
|---|---|
| SBOM, згенерований на момент релізу, що використовується як документ для звітності | Безперервно оновлюваний інвентар, інтегрований з живими потоками даних про вразливості |
| Додавання залежностей перевіряються, коли людина згадує це зробити | Кожне додавання — від людини чи запропоноване агентом — автоматично перевіряється на відповідність політиці |
| Активність AI-агента розчинена в загальних журналах розробників | AI-агентам надаються відстежувані, підзвітні нелюдські ідентичності |
| Відповідь на питання «що входить до складу нашого ПЗ» шукають у старих документах | На нього за запитом відповідає незмінна система доказів із можливістю пошуку |
Чому це важливо навіть для команд, які не продають софт для безпеки
Це не проблема, що стосується лише оборонних підрядників чи регульованих галузей. Будь-яка команда, що використовує AI-асистентів для написання коду — а до 2026 року це більшість команд, — уже змінила спосіб, у який залежності потрапляють у їхню кодову базу, незалежно від того, чи встигли за цим практики захисту ланцюга поставок. Розрив між «ми використовуємо AI-інструменти для коду» і «ми відстежуємо, що вони підключають» — це саме той розрив, який закриває ця тенденція, і закрити його проактивно дешевше, ніж після інциденту, який змусить це зробити.
Знайте, що насправді входить до складу вашого ПЗ
Ми впроваджуємо практики живого SBOM та управління залежностями, що враховують розробку за участі AI, а не лише коміти людей.
Поширені запитання
Чи потрібен нам SBOM, якщо ми не продаємо продукт державі?
Дедалі частіше — так, на практиці: клієнти, страховики та партнери починають вимагати його як стандартну частину due diligence, а точний SBOM корисний і для вашого власного реагування на інциденти, незалежно від того, хто його запитує.
Чи можемо ми просто вручну перевіряти кожну залежність, запропоновану AI?
При невеликому обсязі — так, цілком можливо. Але більшість команд, що використовують AI-інструменти для коду, швидко перевищують обсяг, який ручна перевірка реально здатна витримати, — і саме тому автоматизовані перевірки політик стають необхідними: вони не усувають людину, а лише перестають робити її єдиною контрольною точкою.
Що таке SLSA і як це пов'язано з темою?
SLSA (Supply-chain Levels for Software Artifacts) — це фреймворк для перевірки цілісності самого процесу збірки: звідки взявся артефакт і як саме його зібрали. Він доповнює SBOM, який документує, що входить до складу артефакту, а не те, як він був зібраний.
Це стосується лише пакетів з відкритим кодом?
Ні — той самий підхід до відстежуваного походження поширюється на AI-моделі та їхні ваги, якщо вони є частиною вашого продукту, а також на будь-які сторонні API чи сервіси, від яких залежить ваша система. Спільна ідея — ставитися до кожної залежності як до чогось, про що ви можете відповісти на запитання, а не просто як до того, що працює.