Akrites: Новий щит для Open Source чи спроба загасити пожежу бензином?

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Штучний інтелект змінив правила гри у DevSecOps. Передові LLM-моделі знаходять та експлуатують zero-day вразливості за хвилини — робота, на яку раніше хакери й аудитори витрачали тижні. Баланс сил змістився на користь атакуючої сторони.

Для протидії цьому Linux Foundation разом із лідерами індустрії (OpenAI, Anthropic, Microsoft, Google, AWS, NVIDIA, Red Hat, JPMorganChase) запустила ініціативу Akrites — скоординовану систему захисту open-source від ШІ-кібератак.

Тут криється парадокс корпоративного цинізму: розробники ШІ (OpenAI, Anthropic, Microsoft) фінансують захист від власних же моделей. Вони випустили алгоритми, що моментально сканують код на вразливості, а тепер пропонують волонтерам «подушку безпеки». Це лікування симптомів, а не хвороби.

Чому класичний AppSec більше не працює?

Слабке місце сучасної розробки — Upstream (базові open-source проєкти, на яких тримається комерційний софт). Традиційні підходи тут безсилі через три фактори:

> Ерозія вікна вразливості (Vulnerability Window)
Завдяки ШІ час від виявлення багу до його експлуатації став фактично від’ємним. Зловмисники атакують швидше, ніж розробники встигають випустити патч.
> ШІ-шум і вигорання мейнтейнерів
Автори репозиторіїв тонуть у лавині низькоякісних автоматичних звітів від ШІ-асистентів. Через цей інформаційний шум критичні загрози часто просто ігноруються.
> Хаотичне розкриття (Race to Disclosure)
Компанії конкурують за публікацію CVE, розкриваючи інформацію про баги в мережу ще до появи офіційних виправлень.

Архітектура Akrites: розбір інженерних принципів

Консолідація через SIRT та CVD

Проєкт створює єдину команду реагування (SIRT) та процес координованого розкриття вразливостей (CVD).

Це вирішує проблему дублювання звітів. Замість 10 різних репортів мейнтейнер отримує від Akrites одне верифіковане ТЗ на фікс. Адміністративне навантаження з волонтерів знято, але це залишає їх у позиції пасивних виконавців інструкцій.

Принцип Upstream та «мейнтейнер останньої надії»

Фікси вносяться лише в оригінальний код без створення закритих форків. Якщо критична бібліотека в npm чи pip закинута автором, Akrites бере її підтримку на себе.

Концепція запобігає катастрофам масштабу Log4j. Проте постає питання: де межа між порятунком екосистеми та прихованим корпоративним поглинанням open-source проєктів гігантами типу Google чи Microsoft?

Автоматизація за стандартами VEX

Взаємодія базується на стандартах CVE, EPSS та протоколах VEX (Vulnerability Exploitability eXchange).

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

Спільний фронт корпорацій

Фінансування виділив фонд Alpha-Omega. Проєкт підтримали понад 20 гігантів, включно з OpenAI та Anthropic, які фактично спонсорують захист від власних розробок.

Генеральний директор Chainguard:

«Раніше на пошук серйозної вразливості в експерта йшли тижні. Тепер машині потрібні хвилини. Коли мейнтейнери програють цю гонку, програють абсолютно всі. Жодна компанія чи уряд не спроможні закрити цю прірву самотужки».

Cyber Lead в OpenAI:

«Ми пишаємося можливістю підтримати ініціативу Akrites. Вона допомагає зміцнити open-source екосистему зсередини, дозволяючи компаніям знижувати ризики безпеки без необхідності вносити непотрібні зміни до коду, роблячи спільний софт безпечнішим для кожного».

Чи вистоїть новий щит?

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А темка-то цікава. Опенсорс пишуть в першу чергу заради самореалізації. Потім плодами опенсорс користуються всі зацікавлені особи та установи. Бо на шару. Бо працює. І тут — опа! А воно діряве! А хто винен? Ну, точно вже не той, хто створив. А той, хто вирішив, що йому хтось щось винен. На шару. Яке рішення? А хрін його знає! До прикладу — якийсь консорціум, який візьме на себе відповідальність за аудит опенсорс-рішень, від яких залежить інфраструктура.

Створив хворобу, продає ліки

Цинізм корпорацій досяг піку

Підписатись на коментарі