У 2024 році дослідники з Іллінойського університету виявили, що GPT-4, отримавши опис поширеної вразливості (CVE), міг автономно використати 87% курованого набору даних з 15 “нульових” вразливостей. Без опису він міг експлуатувати лише 7%. Це забезпечувало галузі “запас міцності”, оскільки, хоча ШІ міг використовувати відомі вразливості, він не міг їх виявляти.
Однак 7 квітня Anthropic оголосив, що Claude Mythos Preview ліквідував цей розрив: модель автономно виявила тисячі “нульових” (zero-day) вразливостей у великих операційних системах та браузерах. Окремо Mythos показав 83,1% на бенчмарку відтворення вразливостей CyberGym. В одній з кампаній, націлених на OpenBSD, загальна вартість обчислень за 1000 тестових запусків склала менше 20 000 доларів США.
Терміни експлуатації скорочуються. Вразливість Langflow CVE-2026-33017 (CVSS 9.8) була використана через 20 годин після оприлюднення без публічного доказу концепції. Вразливість Marimo CVE-2026-39987 (CVSS 9.3) була атакована за 9 годин 41 хвилину.
Захисна інфраструктура, на яку покладається більшість організацій, не була розроблена для цього. Звіт Rapid7 за 2026 рік про ландшафт загроз стверджує, що медіанний час від публікації CVE до внесення до списку CISAKnown Exploited Vulnerabilities (KEV) становить п’ять днів. Звіт Google M-Trends 2026 виявив, що експлуатація відбувається ще до випуску патча. Коли було опубліковано консультативний документ Langflow, перший експлойт з’явився через 20 годин. Коли було опубліковано консультативний документ Marimo, це зайняло менше 10 годин.
Припущення про безпечність вашого вікна для виправлень, оскільки експлуатація потребує часу, більше не є актуальним. Ось ваші інструменти.
Замініть пріоритезацію лише за CVSS на трирівневий фільтр
Більшість програм управління вразливостями все ще пріоритезують лише за балом CVSS. CVSS кількісно визначає “теоретичну” серйозність вразливості, не враховуючи, чи експлуатується вона в реальних умовах, і наскільки швидко її можна використати для атаки. Вразливість з CVSS 8.8, яка має історію активної експлуатації (як-от CVE-2026-34040 у Docker), отримує нижчий пріоритет, ніж вразливість з CVSS 9.8, яка може ніколи не бути використана в реальних умовах.
Нещодавнє дослідження, валідоване на 28 377 реальних вразливостях, пропонує конкретну заміну: трирівневе дерево рішень, що включає статус CISA KEV, оцінки Exploit Prediction Scoring System (EPSS) та CVSS, формуючи таким чином єдиний фільтр пріоритезації.
Трирівневий фільтр пріоритезації вразливостей
|
Рівень |
Джерело даних |
Поріг |
Дія |
SLA |
|
1. Активна експлуатація |
Каталог CISA KEV |
Перелічено |
Негайне виправлення |
Години |
|
2. Прогнозована експлуатація |
EPSS через FIRST.org |
Оцінка ≥ 0.088 |
Ескалація до конвеєра рівня 0 |
24 години |
|
3. Базова лінія серйозності |
CVSS через NVD |
Оцінка ≥ 7.0 |
Типове усунення |
Згідно з політикою |
Валідований результат: 18-кратне зростання ефективності, 85,6% охоплення експлуатованих вразливостей, ~95% скорочення навантаження з термінового усунення. Усі три джерела даних є відкритими та безкоштовними.
Описана інтеграція повністю автоматизована. Можна створити скрипт для запиту API CISA KEV, API EPSS від FIRST.org та NVD, і цей скрипт буде запускатися проти вашого інвентарю активів для кожного опублікованого CVE. Людина в цьому процесі повинна залишатися як затверджувач, але не як ініціатор.
Закрийте прогалину в авторизації агентів
Швидке створення експлойтів не тільки змінює пріоритети виправлень, але й конфігурацію контролю для всіх систем, керованих агентами, які тепер володіють привілейованими обліковими даними. Ваші політики авторизації не були оцінені щодо поведінки агентів ШІ, і це тепер є вимірним ризиком. CVE-2026-34040 показав, що архітектура плагінів авторизації Docker мовчки обходить усі плагіни, коли тіло запиту перевищує 1 МБ. Поширені плагіни AuthZ (OPA, Casbin, Prisma Cloud) не обізнані про такий тип обходу, який відбувається в проміжному програмному забезпеченні Docker перед тим, як запит досягне плагіна.
Коли Cyera продемонструвала цю вразливість, вони показали, що агент ШІ, який налагоджує інфраструктуру, може виявити шлях обходу під час виконання законного завдання, без будь-яких інструкцій щодо експлуатації чогось.
Internet Engineering Task Force (IETF) працює над моделями авторизації для агентів. Документ draft-klrc-aiagent-auth-01, опублікований у березні учасниками з AWS, Zscaler, Ping Identity та OpenAI, пропонує використання поточного Secure Production Identity Framework for Everyone (SPIFFE) та OAuth 2.0 для агентів ШІ для отримання динамічно наданих облікових даних з коротким терміном дії.
Окремо, проєкт IETF Agent Identity Protocol (draft-prakash-aip-00) повідомляє, що з приблизно 2000 опитаних серверів протоколу контексту моделі (MCP), жоден не мав автентифікації.
Але ці стандарти будуть реалізовані за місяці або роки. Наразі командам безпеки необхідно проактивно включати тестові сценарії на рівні агентів для всіх меж авторизації, таких як надмірні запити, пікова частота та багатоступінчаста ескалація привілейованих запитів.
Картографуйте радіус поширення облікових даних
У опитуванні, проведеному CSA/Zenity та опублікованому 16 квітня, 53% організацій заявили, що вже стикалися з випадками, коли агенти ШІ перевищували свої дозволені повноваження, а 47% зазнали інциденту безпеки, пов’язаного з агентом.
Коли інструменти для створення ШІ, такі як Flowise (CVE-2025-59528, CVSS 10.0), Langflow або n8n, будуть скомпрометовані, радіус поширення вийде далеко за межі хоста. Ці інструменти містять API-ключі для передових моделей, облікові дані баз даних, токени векторних сховищ та OAuth-токени до бізнес-систем. Скомпрометований хост інструменту для створення ШІ — це не просто злам однієї системи. Це викрадення облікових даних, яке відкриває автентифікований доступ до кожного підключеного сервісу.
Без карт залежності облікових даних для кожного хоста інструменту ШІ, реагування на інциденти при компрометації агента перетворюється на вгадування. Для кожного екземпляра документуйте кожні облікові дані, обсяг доступу до них та відповідний процес ротації облікових даних. Також почніть міграцію статичних API-ключів на токени з коротким терміном дії, якщо це дозволено сервісами нижнього рівня.
П’ять дій на цей квартал
1. Розгорніть трирівневий фільтр KEV-EPSS-CVSS
Замініть пріоритезацію лише за CVSS відповідно до таблиці вище. Автоматизуйте збір даних з усіх трьох API як частину запланованого скрипта для вашого інвентарю активів. Бажаний результат: 18-кратна ефективність, 85,6% охоплення експлуатованих вразливостей, 95% скорочення навантаження з термінового усунення.
2. Впровадьте патчінг, керований подіями, для сервісів рівня 0.
Визначте, які сервіси належать до категорії критичної експозиції: сервіси, безпосередньо доступні користувачам Інтернету, хости для створення ШІ та площини керування оркестрацією контейнерів. Активуйте патчінг, керований подіями, при публікації CVE, замість того, щоб чекати наступного вікна обслуговування для цього рівня.
Мета: розгорнути патч для канарейки протягом чотирьох годин після оголошення CVE критичною. Використовуйте стрічки CISA KEV та EPSS для активації патчінгу, керованого подіями. У ситуаціях, коли неможливо досягти мети чотиригодинного патчінгу через застарілі залежності, вікна заморожування змін або ризик відкату, негайно застосовуйте компенсуючі контролі, такі як усунення доступу до вразливого сервісу з Інтернету, ротація облікових даних для вразливого сервісу, вимкнення уражених функцій сервісу (якщо застосовно) та визначення відповідального за виняток для експозиції до моменту розгортання патча.
Неприпустимо допускати необмежені експозиції протягом тривалого часу в очікуванні вікна обслуговування.
3. Тестуйте межі авторизації в масштабі агентів.
Створіть тестові випадки для кожного API, з яким можуть взаємодіяти агенти ШІ, через політики AuthZ. Зокрема, включіть тестові випадки для запитів, що перевищують розмір тіла 1 МБ, 5 МБ та 10 МБ. Це включає тестові випадки для пікової частоти > 100 запитів на секунду та тестові випадки для незвичайних комбінацій параметрів (привілейовані прапорці, монтування хоста, додавання можливостей). Крім того, встановіть патч до Docker Engine 29.3.1 для виправлення CVE-2026-34040.
4. Картографування радіусу поширення облікових даних для всіх хостів інструментів ШІ.
Документуйте кожні облікові дані для кожного екземпляра Langflow, Flowise, n8n та користувацьких конвеєрів ШІ. Класифікуйте кожні облікові дані за терміном їх дії (статичний ключ проти токена з коротким терміном дії). Визначте, до чого мають доступ кожні облікові дані. Налаштуйте сповіщення про аномальний IP-адрес або ідентифікатор для будь-якого доступу до облікових даних.
5. Сканування для виявлення “тіньового” ШІ цього тижня.
Згідно з даними CSA, існує понад 50% ймовірність, що ваші агенти перевищили свої очікувані межі. Перевірте свої системи SIEM (Security Information and Event Management) та інструменти мережевого моніторингу на наявність комунікацій до стандартних портів інструментів ШІ: Langflow 7860, Flowise 3000 та n8n 5678. Будь-які неавторизовані екземпляри є неконтрольованою поверхнею атаки.
Ключовий висновок
З’являються агенти ШІ, і органи стандартизації реагують. IETF має кілька проєктів, пов’язаних з автентифікацією та авторизацією агентів. Coalition for Secure AI опублікувала свою таксономію безпеки MCP та принципи безпеки за дизайном.
Але ці стандарти розробляються зі швидкістю стандартів, а вікно експлуатації тепер вимірюється годинами. Організації, які впровадять трирівневий фільтр та патчінг, керований подіями, цього кварталу, досягнуть вимірного скорочення експозиції. Ті, хто чекатиме, будуть дотримуватися календарних циклів патчінгу проти супротивника, який діє менш ніж за 20 годин.
Нік Кейл – головний інженер, що спеціалізується на корпоративних платформах ШІ та їх безпеці
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій дозволяє технічним експертам ділитися своїми ідеями та надавати нейтральні, не зацікавлені глибокі дослідження в галузі ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє корпоративного сектору.
Читайте більше з нашої програми гостьових публікацій – і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у створенні власної статті!
Як захиститися (Порада ІТ-Блогу): Регулярно оновлюйте всі ваші системи, особливо ті, що мають доступ до Інтернету або обробляють критичні дані. Використовуйте двофакторну автентифікацію всюди, де це можливо, щоб ускладнити несанкціонований доступ, навіть якщо облікові дані будуть скомпрометовані.
За даними порталу: venturebeat.com