Open source давно став фундаментом корпоративних ІТ — понад 90% компаній зі списку Fortune 500 покладаються на нього в критичних системах. Але той самий фундамент дедалі частіше стає точкою входу для атак. На цьому тлі IBM та Red Hat оголосили про Project Lightwell — п’ятирічну ініціативу вартістю 5 млрд доларів, покликану радикально підвищити безпеку відкритого ПЗ. Проєкт обговорювали в подкасті Security Intelligence від IBM Technology за участі експертів IBM та Red Hat, і з нього вимальовується одна з найамбітніших спроб системно захистити open source в епоху AI.
Від 15 тисяч до 1,5 мільйона: як Red Hat масштабує свою модель
Red Hat уже багато років будує бізнес на тому, щоб перетворювати «дикий» open source на передбачуваний, підтримуваний продукт. Компанія бере код з upstream-проєктів, пропускає його через власний процес продуктізації — з перевірками, тестуванням, виправленням вразливостей, довгостроковою підтримкою — і постачає клієнтам як стабільні бінарні пакети.
Сьогодні Red Hat таким чином «упаковує» приблизно 15 тисяч пакетів. Це ядро трьох ключових платформ: Red Hat Enterprise Linux, OpenShift та Ansible Automation Platform. Для корпоративних замовників це означає, що базова інфраструктура — операційна система, контейнерна платформа, засоби автоматизації — проходить через добре відпрацьований конвеєр безпеки.
Project Lightwell пропонує зробити з цією моделлю те, що свого часу зробили хмарні провайдери з дата-центрами: масштабувати на порядок. Мета — поширити підхід Red Hat не на десятки тисяч, а на близько 1,5 мільйона пакетів мовних бібліотек. Йдеться про екосистеми Java, Python, Node.js, Go та інших мов, де основний ризик давно перемістився з «великих» компонентів на дрібні залежності.
Це не просто збільшення обсягу роботи у сто разів. Це спроба перенести дисципліну корпоративного дистрибутива в хаотичний світ мовних репозиторіїв — Maven Central, PyPI, npm, Go modules — де бібліотеки з’являються, змінюються і зникають у темпі, до якого традиційні процеси безпеки не встигають.
Мовні бібліотеки як новий фронт: коли у банку мільйон залежностей
Якщо ще десять років тому основні ризики асоціювалися з ядром ОС, веб-серверами чи базами даних, то сьогодні найбільш вразливою ланкою часто стають саме мовні бібліотеки. Класичний приклад — log4j: невелика, але надзвичайно популярна Java-бібліотека логування, вразливість у якій перетворилася на глобальну кризу безпеки.
Для великих організацій масштаб проблеми вимірюється не десятками й не сотнями, а сотнями тисяч компонентів. За оцінками Red Hat, у деяких великих фінансових установах загальна кількість бібліотек і їхніх версій у продакшн-середовищах коливається від приблизно 600 тисяч до понад 1 мільйона. Кожна з цих залежностей потенційно може містити вразливість, бути покинутою мейнтейнерами або виявитися ланкою в ланцюгу складнішої атаки.
Традиційна відповідь індустрії — внутрішні артефакторії та сканери вразливостей. Компанії забирають пакети з публічних репозиторіїв, кладуть їх у власні репозиторії (on-prem або керовані сервіси), а потім пропускають через інструменти аналізу, які звіряють версії з базами CVE. Розробники споживають уже «перевірені» артефакти.
Проблема в тому, що цей підхід дедалі гірше працює в умовах сучасних атак. По-перше, сканери бачать лише те, що вже формалізовано як відома вразливість. По-друге, вони зазвичай оцінюють компоненти ізольовано, тоді як реальні атаки все частіше будуються на взаємодії кількох, на перший погляд, малонебезпечних дефектів.
Саме тут Project Lightwell намагається зробити крок далі: не просто фіксувати відомі CVE, а системно захищати ланцюжок постачання мовних бібліотек — від моменту, коли пакет з’являється в екосистемі, до його використання в конкретному застосунку.
AI проти AI: чому безпека open source змінюється саме зараз
Час запуску Project Lightwell не випадковий. На горизонті з’явилося нове покоління AI-моделей, здатних працювати з кодом і вразливостями на рівні, який виходить за межі людських можливостей. У подкасті як приклад наводиться модель Mythos — систему, що вміє «нанизувати» кілька низькосерйозних вразливостей у складні експлойти.
Порівняння з шахами тут виглядає показовим. Людина-початківець бачить один хід наперед, гросмейстер — 15–20. Mythos, за оцінками учасників дискусії, умовно «мислить» на 50–60 ходів уперед у термінах безпеки. Це означає, що модель може аналізувати велику кількість компонентів, конфігурацій і залежностей, шукаючи нетривіальні комбінації, які в сукупності дають змогу отримати віддалений доступ або витік даних.
Додатковий виклик у тому, що публічно доступні моделі, за оцінками експертів, відстають від таких систем, як Mythos чи умовний GPT‑5.5, приблизно на 9–12 місяців. Іншими словами, атакувальники, які мають доступ до більш просунутих інструментів, можуть експлуатувати класи вразливостей, до яких захисники масово ще не готові.
У такій ситуації спроби «закрити» кожну окрему діру в коді перетворюються на нескінченну гонку. Безпека перестає бути набором точкових патчів і дедалі більше нагадує роботу з динамічною системою, де важливо розуміти, як компоненти взаємодіють між собою. Саме це підштовхує IBM і Red Hat до створення більш централізованої, системної відповіді — і пояснює, чому Project Lightwell запускається саме зараз.
Clearinghouse довіри: що означає «центральний пункт безпеки» для open source
Ключовий елемент Project Lightwell — створення так званого trusted enterprise clearinghouse для безпеки open source. У корпоративному контексті clearinghouse — це не просто база даних, а інституція, якій делегують частину відповідальності за перевірку, стандартизацію та координацію.
У випадку Lightwell clearinghouse має виконувати кілька ролей одночасно. По-перше, бути центральною точкою, де підприємства можуть отримати перевірені, валідовані компоненти open source — не лише у вигляді «великих» пакетів Red Hat, а й мовних бібліотек, які зазвичай живуть у менш контрольованому середовищі. По-друге, виступати координатором процесів виявлення, звітування та виправлення вразливостей.
Серед заявлених завдань — спрощення всього циклу роботи з вразливостями: від первинного репорту до розгортання перевіреного патча і координації розкриття інформації upstream-проєктам. Ідея полягає в тому, щоб зменшити фрагментацію, коли кожен учасник екосистеми — від мейнтейнера бібліотеки до великого банку — діє у власному інформаційному вакуумі.
У реальному світі це може означати, що:
компанія отримує не просто сповіщення про нову CVE в певній бібліотеці, а й чіткі рекомендації щодо безпечної версії, часові рамки, матрицю впливу на суміжні компоненти;
патч, який надходить із upstream, проходить додаткову валідацію в рамках Lightwell, перш ніж потрапити в корпоративні репозиторії;
розкриття вразливостей координується так, щоб одночасно захистити користувачів і не нашкодити відкритим проєктам, які залежать від добровільної праці мейнтейнерів.
Фактично йдеться про спробу створити «службу повітряного руху» для open source-безпеки, яка допомагає уникати зіткнень у небі, де кількість «літаків» — бібліотек, версій, залежностей — давно вийшла за межі того, що людина здатна відстежити вручну.
20 тисяч інженерів з AI-підсиленням: людський фактор у масштабі
Ще одна амбітна складова Project Lightwell — команда з 20 тисяч інженерів, які працюватимуть над безпекою open source із використанням AI-інструментів. Це не просто велика цифра для пресрелізу. На тлі хронічного дефіциту фахівців з безпеки та вигорання мейнтейнерів open source такий масштаб виглядає спробою системно закрити кадровий розрив.
У світі відкритого ПЗ багато критично важливих бібліотек підтримуються одним-двома людьми у вільний від основної роботи час. Обіцянка open source — «багато очей бачать більше» — на практиці часто не справджується: очей мало, а обсяг коду й темп змін величезні. Водночас корпоративні користувачі очікують від цих компонентів надійності рівня комерційних продуктів.
Команда Lightwell має виконувати рутинну, але критично важливу роботу: рев’ю коду, тріаж вразливостей, валідацію патчів, аналіз ланцюжків залежностей. AI у цій схемі виступає не заміною, а мультиплікатором людських зусиль. Моделі можуть автоматично проганяти код через статичний і динамічний аналіз, шукати нетривіальні взаємодії між компонентами, пропонувати варіанти виправлень. Інженери, своєю чергою, беруть на себе прийняття рішень, пріоритизацію, взаємодію з upstream-спільнотами.
Учасники подкасту описують майбутнє розробки як гібридну модель: AI пише значну частину коду, людина переглядає й редагує, а над усім цим працюють агентні системи на кшталт Lightwell, які стежать за цілісністю ланцюга постачання. У такій конфігурації 20 тисяч інженерів — це не просто армія рев’юерів, а ядро нової інфраструктури безпеки, де людський досвід і машинний аналіз взаємодіють постійно, а не епізодично.
Від реагування до стійкості: чи може Lightwell змінити баланс сил
Project Lightwell з’являється на тлі кількох паралельних трендів, які роблять open source одночасно незамінним і небезпечним. З одного боку, без відкритих бібліотек сучасна розробка просто зупиниться: ніхто не писатиме з нуля логування, парсери, криптографію чи клієнти до хмарних сервісів. З іншого — саме через ці бібліотеки проходить дедалі більше атак, від supply chain-компрометацій до складних експлойтів, побудованих на ланцюжках дрібних вразливостей.
Ініціатива IBM та Red Hat намагається змістити фокус із реактивного латання дірок до побудови стійкої екосистеми. Масштабування моделі продуктізації Red Hat на мовні бібліотеки, створення централізованого clearinghouse, залучення 20 тисяч AI-посилених інженерів — усе це виглядає як спроба зробити для open source-безпеки те, що колись зробили дистрибутиви Linux для серверної інфраструктури: перетворити хаос на керований, хоч і все ще відкритий, простір.
Важливо, що за проєктом стоїть не лише технологічний, а й фінансовий сигнал. П’ять мільярдів доларів — це рівень інвестицій, який зазвичай асоціюється з хмарними дата-центрами чи великими AI-платформами. Тепер такий самий масштаб спрямовується на безпеку open source, причому саме там, де ризики найбільш розмиті й розподілені — у мовних бібліотеках, які живуть між GitHub, публічними репозиторіями та корпоративними артефакторіями.
Чи змінить це баланс сил між атакувальниками й захисниками? Відповідь залежатиме від того, наскільки глибоко Lightwell зможе інтегруватися в реальні процеси розробки, наскільки охоче підприємства делегуватимуть йому частину довіри, і чи вдасться поєднати інтереси корпоративних користувачів із культурою open source-спільнот. Але вже зараз зрозуміло, що це одна з перших спроб відповісти на виклики епохи AI не точковими патчами, а перебудовою самої інфраструктури безпеки.
Висновок: open source входить у епоху інституційної безпеки
Open source довго жив за принципом «код відкритий — отже, його хтось перевірить». У світі, де кількість бібліотек обчислюється мільйонами, а AI-моделі вміють будувати багатокрокові атаки на основі малопомітних дефектів, цього вже недостатньо. Project Lightwell демонструє, що великі гравці готові вкладати серйозні ресурси в те, щоб зробити безпеку відкритого ПЗ не побічним ефектом ентузіазму спільноти, а окремою, інституційно підтримуваною функцією.
Розширення моделі Red Hat з 15 тисяч до 1,5 мільйона пакетів, фокус на мовних бібліотеках, які лежать в основі сучасних застосунків, створення trusted clearinghouse та залучення 20 тисяч AI-посилених інженерів — усе це ознаки того, що open source входить у нову фазу. Фазу, де свобода використання й модифікації коду поєднується з очікуванням промислового рівня безпеки.
Наскільки успішним буде цей експеримент, покаже час. Але сам факт, що безпека open source стає предметом багатомільярдних інвестицій, свідчить: епоха, коли мовні бібліотеки сприймалися як «дрібниці», які можна просто додати в проєкт із публічного репозиторію, добігає кінця.
Джерело
Project Lightwell brings open source security into the AI era — IBM Technology