Миналата седмица OpenAI повдигна завесата над Aardvark, вътрешен ИИ агент за сигурност, който прави това, което повечето скенери само обещават: поправя дефекти и улавя експлойти, преди да станат истински проблем. Представете си едно Кайджу (свръх-чудовище), което буквално обхожда кода, надушва бъговете и ги екстерминира напълно.
За европейски компании с остарял код Aardvark е реалната промяна (AppSec не е само „shift-left“). Визията е за Кайджу-ИИ, който чете, разсъждава и отстранява дефекти и експлойти по-бързо от атакуващ. Икономиката е ясна: спрете да сканирате проблеми, внедрете агенти, които ги решават.
Последният шумен релийз на OpenAI бе Sora 2, видео модел, който генерира милион клипове със Сам Алтман. Защо тогава Aardvark излиза в затворена бета? Според Айтел причината е необходимост в жизнения цикъл на разработката (SDLC), продиктувана от икономика и риск. Когато всеки предобучителен рън струва милиони, един дефект може да изхарчи същото за нищо. SDLC от следващо поколение без ИИ инструмент за качество на кода буди въпроси. Инвестицията в Aardvark показва, че „роденият в ИИ“ AppSec се счита за основна инфраструктура. Инструменти като Aardvark вече са отделен ред в SDLC.
Aardvark работи постоянно върху репозитории, приоритизира уязвимости по експлоатируемост и насочва инженерното усилие там, където рискът е реален. Генерира минимални дифове с тестове за регресия и изпраща фиксовете за човешко одобрение. Двигателят е силен при логически грешки и криптографски пропуски, които често се изплъзват на ревюта. План за интеграция:
Обратна връзка от затворената бета: ранните вътрешни изпълнения върху специализиран код показаха висока точност, модулите с висока стойност трябва да минават през Aardvark преди пускане.
Затворен цикъл, който започва в IDE и завършва с доказателства, готови за одит. Всяка стъпка произвежда артефакти, на които инженерите могат да се доверят, фактор, който ограничава рисковете за европейските застрахователи.
Моделиране на заплахи в реално време: добавяне на вероятни вектори и нужни контроли по време на писане.
Сигурни шаблони: подравняване към CWE и OWASP от първия commit.
Политики в контекст: прилагане на GDPR, ISO 27001 и DORA в кода.
Динамично сондиране: обхождане на услуги, целенасочен fuzz, корелация на аномалии.
Агенти с цели: преследване на ескалация на привилегии или RCE с правилните инструменти.
Сигнали от продукция: учене на нормален трафик и сигнализиране за злоупотреби.
Стегнати кръпки: проследяване на зависимости и предложения за устойчиви дифове.
Тестове включени: генериране на регресионно покритие с всеки фикс.
Премахване по клас проблеми: кампании, които „пенсионират“ цели семейства дефекти.
Проверки за безопасност: потвърждаване на коректност и ефект върху производителността.
Пакети с доказателства: обединяване на находки и фиксове за бъдещи одити.
С прехода от концепция към внедряване, тези инструменти стават част от ежедневната доставка: анализ на кода и валидиране на резултати. Автоматизираното отстраняване в SDLC повишава качеството и устойчивостта, от откриване на уязвимости до автоматизация в QA.
Интегрираме агенти от клас Aardvark с QA и AppSec така, че да съответстват на нашата ISO 27001 сертификация, GDPR, SOC 2 и DORA, с ясна проследимост на промените.
Този оперативен модел държи одиторите спокойни, бюджетите предвидими и релийз влаковете навреме. Ключово за ИИ инструментите е контролът на разходите: задаване на тавани на цена за агент в токени, по възможност на репозиториум.
Дейв Айтел, член на техническия екип на OpenAI, представя по-долу новия продукт за сигурност Aardvark:
Препоръките на Дейв Айтел за интегриране на ИИ в SDLC с фокус върху практическите ефекти за разработката и киберсигурността. Според него инструментите като Aardvark преминават от предимство към необходимост, продиктувана от икономическата реалност.
Целта не е количество дребни дефекти, а интелигентност, приложена към критичните проблеми. Остава открит въпросът: може ли ИИ да открива и смекчава zero-day уязвимости?
libasan.Инструмент като Aardvark трябва да опростява потока и да подпомага отношенията с екипите за разработка.
Изводите от Solidity подсказват, че специализираният, високорисков код трябва рано да влиза в ИИ-pipeline.
Висок риск, висока възвръщаемост: при smart contracts и сложен, високостойностен код е критично да се пусне ИИ анализ преди деплой.
| Област | Препоръка | Аргумент/полза |
| Стратегия | Направете ИИ качеството на кода основно изискване. | Намалява нестабилността и риска за сигурността. |
| Икономика | Планирайте бюджет за токени/изчисление. | По-евтино от недетектирани дефекти и престои. |
| Имплементация | Непрекъснат мониторинг с автоматичен валидатор. | Контрира „ентропията“ и пази високото съотношение сигнал/шум. |
| Фокус върху уязвимости | Приоритизирайте логика и криптография. | Зони, където ИИ превъзхожда човешката ревизия и класиката. |
| Контрол на процеса | Запазете човешкия контрол при деплой. | Човек валидира всички фиксове преди merge. |
| Култура | Поверителност и помощ. | ИИ е подкрепа за девелопърите, не инструмент за засрамване. |
Бъдещето не е без уязвимости, а с два интернетa, както предвижда Брус Шнайер. Първият, „новият“, ще е от код, „роден сигурен“, валидиран непрекъснато от ИИ агенти от първия commit.
Вторият, „legacy“, ще е от милиарди редове съществуващ код, който не се сканира и кръпва лесно от новите агенти. Този слой става основна, незащитена повърхност за офанзивен ИИ, създавайки системен риск за следващото десетилетие. Целта на TINQIN е да приложи инструменти и практики, с които организациите да инвентаризират, защитят и изолират това уязвимо наследство.