Bright Security представя STAR Fuzzer – фазинг с изкуствен интелект, който сам създава тестови обвивки и доказва всяка открита уязвимост

Превод и анализ на NodePoint News по материал на Cyber Security News „Bright Security Introduces STAR Fuzzer, Agentic Fuzzing That Writes Its Own Harnesses and Proves Every Finding“

Сан Рафаел, САЩ, 19 октомври 2026 г., CyberNewswire

Базиран на еволюционен двигател, пуснат за първи път през 2018 г., STAR Fuzzer от Bright Security открива сривове, изчерпване на паметта и дефекти в сигурността на паметта в критичен за сигурността код, без необходимост от работещо приложение.

При първото си изследователско пускане с отворен код той откри проблеми с висока или критична степен на опасност (High или Critical) в 45% от тестваните проекти, а през първия месец от своето пускане осигури десет публикувани констатации в осем проекта, сред които стандартната библиотека на Crystal, htop и RIOT OS.

Bright Security, компанията за агентна офанзивна сигурност на приложенията (Agentic Offensive Application Security), обяви днес официалното пускане на STAR Fuzzer — агентен фазър за приложения, който автоматично идентифицира критични за сигурността функции, генерира фазинг тестова рамка (harness) за всяка от тях, търси дефекти чрез еволюционен алгоритъм и предоставя всяка потвърдена констатация с точен до байт зловреден код, който я възпроизвежда.

STAR Fuzzer е самостоятелен режим на платформата Bright STAR и е достъпен на адрес brightsec.com/fuzzer.

Агентният фазинг (agentic fuzzing) прилага ИИ агенти за онези части от фазинга, които традиционно изискват специалист: избор какво да се тества, написване на тестовата рамка (harness) и преценка кои сривове са съществени.

STAR Fuzzer използва ИИ за тези стъпки и еволюционен механизъм за търсене за самия фазинг, така че изискващите експертна преценка елементи са автоматизирани, а търсенето остава бързо, възпроизводимо и базирано на доказателства.

Защо фазингът се нуждаеше от нов подход

Фазърите, водени от покритието (coverage-guided fuzzers), като AFL++ и libFuzzer, са доказани и широко използвани, а програми като OSS-Fuzz на Google показаха колко много могат да открият.

Те обаче зависят от хора, които да пишат и поддържат тестова рамка за всяка цел и да приоритизират и анализират върнатите сривове. Този разход поддържаше фазинга концентриран само в специализирани екипи и в ограничена част от критичните проекти.

Другите подходи за тестване не запълват тази празнина. Динамичното тестване за сигурност на приложенията (DAST) проверява това, до което атакуващ може да достигне по HTTP, така че рядко упражнява кода за синтактичен анализ и обработка зад валидацията на входните данни.

Пентестването, базирано на LLM, е ефективно при известни модели на уязвимости, но обикновено търси там, където моделът очаква да има дефекти.

Резултатът е цял клас от дефекти, водещи до спиране на работата (outage-level) и проблеми със сигурността на паметта, често задействани от миниатюрни неправилно форматирани входни данни, които повечето AppSec програми никога не тестват.

Как STAR Fuzzer се съпоставя с традиционните фазъри, водени от покритието (като AFL++ и libFuzzer), и DAST:

Какво тества: Традиционните фазъри тестват функции, достъпни чрез ръчно написана тестова рамка (harness). DAST тества работещи приложения по HTTP. STAR Fuzzer тества критични за сигурността функции по пътищата на ненадеждни входни данни, избрани автоматично.
Тестова рамка (Harness): Традиционните фазъри изискват тестови рамки, написани и поддържани от инженери. DAST не използва такава. STAR Fuzzer генерира тестова рамка за всяка функция с помощта на ИИ, след което проверява дали тя достига целта си.
Търсене: Традиционните фазъри използват мутация, водена от покритието. DAST изпраща атаки със зловреден код на ниво заявка. STAR Fuzzer използва структурен еволюционен метод на търсене, воден от покритието и множество фитнес сигнали.
Необходимост от работещо приложение: Традиционни фазъри — не. DAST — да. STAR Fuzzer — не.
Трижиране и анализ: Ръчно при традиционните фазъри и вградено в скенера при DAST. STAR Fuzzer трижира автоматично за достижимост и въздействие.
Резултат: Традиционните фазъри връщат входни данни за срив и логове. DAST връща доклад за уязвимости. STAR Fuzzer предоставя файла, функцията и точния до байт зловреден код в pull request.
Потвърждение на отстраняването: Традиционните фазъри изискват ръчно повторно изпълнение, а DAST изисква повторно сканиране. Със STAR Fuzzer екипите просто възпроизвеждат отново подадения зловреден код.

Откриване на дефектите, които LLM пропускат

Поискайте от LLM да направи одит на парсер и той ще намери класовете дефекти, които вече познава от обучението си. Уязвимостите от тип нулев ден, които оцеляват с години в зрял, широко внедрен код, са точно тези, които не отговарят на нито един познат модел.

STAR Fuzzer използва ИИ, за да избира цели и да изгражда тестови рамки, но търсенето, което намира дефектите, не е LLM. То не чете кода и не гадае къде може да се намира даден дефект.

То изпълнява програмата милиони пъти, наблюдава какво всъщност се случва и запазва всичко, което тласка целта към код, който все още не е бил достигнат.

В „Back to the Fuzzer II: Finding the Bugs LLMs Miss“ техническият директор на Bright Security Бар Хофеш посочва четири причини, поради които прегледът на код с LLM не заменя фазинга при откриването на уязвимости от тип нулев ден:

Мащаб: Една-единствена фазинг кампания изпълнява от 1 милион до 10 милиона конкретни входни пакета срещу компилираната цел. При приблизително 2000 токена на аргументиран тестов казус, възпроизвеждането на един милион изпълнения с LLM би отнело около два милиарда токена за една цел, като всеки от тези тестови казуси все пак би бил само предположение.
Скорост и реални факти: Постоянната тестова рамка изпълнява от стотици до няколко хиляди входни пакета в секунда на работен процес (worker), разпределени между няколко паралелни процеса, така че един милион изпълнения отнемат от минути до няколко десетки минути. Един логически цикъл на LLM върху една хипотеза отнема няколко секунди, така че един милион биха отнели месеци. Освен това фазърът наблюдава реално поведение — например санитайзер, отчитащ четене от хийпа с един байт извън границите. LLM трябва да прогнозира как се държи компилираният код, включително разположението на структурите, размерите на целите числа, поведението на разпределителя на памет и флаговете за компилация, които не се виждат в изходния код.
Покритие: Тестовата рамка на STAR Fuzzer за libxml2 достига около 13 600 региона от код при изпълнение от 5 милиона цикъла. Обратната връзка за покритието показва кои региони е достигнал всеки входен пакет, а входните данни, които достигат нов код, стават начални точки за по-дълбоко търсене. Прегледът на код няма еквивалентен сигнал за това каква част от голям парсер реално е покрил.
Неочакваното: LLM моделите, проверяващите кода специалисти и статичните анализатори търсят едни и същи познати модели, така че в зрелия код повечето от тези дефекти вече са отстранени. Фазърът няма очаквания за това къде трябва да се намира даден дефект. Собственото поведение на целта решава какво представлява интерес.

Възпроизводимостта е другата разлика. Много от изглеждащите достоверно констатации на LLM не се възпроизвеждат, а поддържащите проекта лица се нуждаят от възпроизводим тест, преди да могат да предприемат действия.

Констатацията от фазър е възпроизводима по самата си конструкция, а Bright Security възпроизвежда всяка една в чист контейнер, преди да я подаде като доклад.

Как работи STAR Fuzzer

Механизмът за търсене на STAR Fuzzer управлява всяка цел чрез малка тестова рамка през IPC, така че тестваният код може да бъде написан на C, C++, Rust, Go, Java, Kotlin, Crystal, Node или всеки език, който може да чете входни данни и да връща резултат.

Синтактичен анализ с отчитане на структурата (structure-aware) без индивидуална граматика за всяка цел: Всеки първоначален входен образец (seed) се анализира до типизирано дърво от полета чрез слой за анализ, независим от формата, а дървото се сериализира обратно с пълна точност до първоначалните байтове. Не се създават индивидуални файлове с граматика или речници за всяка отделна цел, а всеки формат, добавен към слоя за анализ, подобрява резултатите за всяка цел, която го използва.
Мутации, които преодоляват първоначалната проверка: Мутацията на ниво байтове най-често генерира входни данни, които модулът за синтактичен анализ отхвърля още при първата проверка за коректност. Мутирането на полетата на валиден структуриран вход запазва повечето изпълнения отвъд рамкирането и валидацията, така че ресурсите за тестване се изразходват за по-дълбоката логика зад тях.
Еволюция с точно пресъздаване: Всеки организъм в популацията носи геном — подреден списък от мутации. Във всяка епоха организмите мутират, изпълняват се и получават оценка. Подобренията се запазват, непродуктивните промени се отменят, а организмите се размножават. Повторното изпълнение на даден геном възпроизвежда неговия тестов образец (payload) с пълна точност, така че всеки резултат може да бъде повторно генериран от регистрирания начален код за рандомизация (random seed).

Резултати от тестване с отворен код

Преди официалното пускане Bright Security изпълни STAR Fuzzer в продължение на два дни в автоматизиран конвейер (pipeline) срещу множество проекти с отворен код — от библиотеки и приложения до нискоразредни двоични анализатори (parsers).

45% от тестваните проекти съдържаха проблеми с високо (High) или критично (Critical) ниво, а 37% от уязвимите проекти са част от програмата OSS-Fuzz на Google.

През първия месец от своята наличност STAR Fuzzer генерира десет публикувани открития в осем проекта, написани на C, Go, езици за JVM и Crystal. Всяко от тях беше пресъздадено в нов контейнер преди подаването на сигнала:

TwelveMonkeys: В четеца на DDS полето в заглавната част mipMapCount определя размера на масив без зададен лимит, поради което файл от 38 байта предизвиква заделяне на памет от няколко гигабайта (CWE-789). GHSA-fwp7-38wp-mmxw, отстранена уязвимост във версия 3.15.0.
Fider: Валидацията при качване проверява компресирания размер на изображението, след което го декодира изцяло, така че PNG файл с размер 436 KB се разгръща до около 562 MB. Всеки удостоверен потребител може да го задейства (CWE-409). STAR Fuzzer откри уязвимостта за около 12 минути във версия, която вече е преминала бенчмаркове от множество доставчици на AI тестване за проникване (pentesting). GHSA-7cw3-7xh9-529r, отстранена уязвимост във версия 0.38.0.
Стандартна библиотека на Crystal (XML): Объркване на типовете (type confusion) в XML::Node#namespace. ENTITY_DECL липсва от списъка с разрешени елементи (allowlist), поради което поле от структурата xmlEntity на libxml2 се чете като xmlNs* (CWE-843). GHSA-c267-9cqj-hv9f, отстранена уязвимост в Crystal 1.21.1.
Стандартна библиотека на Crystal (YAML): YAML::Any#hash препълва стека при цикъл от саморефериращи се котви и псевдоними. Входни данни от 88 байта предизвикват неуловим SIGSEGV (CWE-674). GHSA-fj8w-2r88-5v7w, отстранена уязвимост в Crystal 1.21.1.
libsolv: Две уязвимости — CVE-2026-104621 и CVE-2026-104622. Детайлите са под ембарго.
htop: Четене извън границите на буфера (out-of-bounds read) в анализатора /proc/PID/stat, причинено от липсваща проверка на границите за поле 22 (CWE-125). Отстранена (#2101).
universal-ctags: Достъп до член чрез нулев указател (null-pointer member access) във foreachEntriesInScope (CWE-476). Отстранена уязвимост в commit 780bd7a (#4497).
scrimage: Неограничен брой пиксели (ширина по височина) позволява на GIF файл с размер 35 байта да предизвика опити за заделяне на около 2 GB памет, а във втори вариант — над 8 GB (CWE-789). Отстранена уязвимост във версия 4.6.8 (#893).
RIOT OS: Грешка с отклонение от единица (off-by-one) в _dirlist_cb (link_format.c). Проверката на границите се изпълнява след записа, поради което NUL байт попада с една позиция след буфера (CWE-193). Изпратена корекция за сигурност в PR #22879.

Няколко от тези грешки се намират в код, който изглежда коректен при преглед. Качването във Fider има лимит за размер, но той измерва компресирания размер. Полето в TwelveMonkeys се интерпретира като метаданни за изображение, а не като дължина.

Списъкът с разрешени елементи в Crystal изглежда завършен. Хеш функцията за YAML работи правилно за дървовидни структури, а самата грешка представлява цикъл във входните данни.

Пълната методология и резултатите са публикувани в две части: Част I на brightsec.com и „Back to the Fuzzer II: Finding the Bugs LLMs Miss“ от Bar Hofesh.

Къде STAR Fuzzer е най-подходящ

STAR Fuzzer на Bright Security е създаден за екипи, чийто код обработва ненадеждни входни данни под слоя HTTP, включително:

Приложения, които обработват качени файлове, изображения, документи или архиви
Модули за синтактичен анализ, код за сериализация и необработени двоични протоколи
Софтуер извън уеб пространството, като фърмуер за вградени системи и IoT, десктоп приложения и бекенд услуги
Кодови бази с нарастващ дял на генериран от изкуствен интелект код, който изисква тестване отвъд простото разпознаване на шаблони
Екипи по сигурност, които искат да потвърдят констатации от статичен анализ (SAST) чрез реално тестване на отбелязаните функции в реално време

Инструментът поддържа C/C++, Rust, Go, Java/Kotlin, .NET, Node, Python и Crystal и се изпълнява в рамките на средата на клиента, без да изисква работещо приложение, облачен скенер или удостоверяване.

В постоянен режим (persistent mode) изпълнението на тестов код (harness) е около 51 пъти по-бързо в сравнение със стартирането на нов процес за всяка входяща стойност.

Гледната точка на ръководството

„Фъзването винаги е откривало грешките, които имат най-голямо значение — онези, които сриват дадена услуга или повреждат паметта, но за повечето екипи беше твърде скъпо да го прилагат“, сподели Bar Hofesh, съосновател и главен технически директор на Bright Security.

„Търсенето никога не е било тясното място. Такова бяха тестващите обвивки (harnesses) и триажът на резултатите. STAR Fuzzer автоматизира и двете, така че еволюционният механизъм, който изградихме през 2018 г., най-накрая може да работи върху цялостна кодова база.“

„Когато Невада откри обходния път на Боулдър Сити през 2018 г., на навигационните приложения бяха нужни месеци, за да започнат да насочват шофьорите по него“, добави Hofesh. „Големите езикови модели (LLM), които одитират код, действат по същия начин.

Те откриват грешките, които вече са виждали. Уязвимостите от тип нулев ден (zero-day), които са съществували с години в зрял код, са онези, които никой не е виждал досега, и именно там фазърът блести.“

„От екипите по сигурност се изисква да бъдат в крак с код, който се пише по-бързо от всякога — в голямата си част от изкуствен интелект“, заяви Gadi Bashvitz, съосновател и главен изпълнителен директор на Bright Security.

„Тестването, което търси само там, където се очакват грешки, няма да издържи на темпото. STAR Fuzzer търси навсякъде другаде и предоставя на разработчиците доказателствата, от които се нуждаят, за да отстранят откритите проблеми.“

„Екипите по сигурност на приложенията (AppSec) продължават да ни задават един и същ въпрос: ако изкуственият интелект пише все по-голяма част от кода ни, какво тества частите, които той не може да види?“, каза Eyal Dror, главен маркетинг директор на Bright Security.

„STAR Fuzzer е нашият отговор. През първия си месец той откри десет реални грешки в зрели проекти с отворен код, като всяка една беше придружена от точните входни данни, които я задействат. Това е доказателство, по което разработчикът може да предприеме действия още в същия ден, а не поредното предупреждение, за което да се спори.“

Наличност

STAR Fuzzer е наличен в момента като режим в рамките на Bright STAR. Научете повече и заявете демо на brightsec.com/fuzzer.

Често задавани въпроси:

Какво представлява агентното фазване (Agentic Fuzzing)? Агентното фазване използва AI агенти за автоматизиране на стъпките при фазване, които изискват преценка: избиране кои функции да се тестват, създаване и верифициране на тестващи обвивки (harnesses) и триаж на резултатите. Самото фазване се извършва от система за търсене, която мутира входящите данни, за да предизвика грешки.

По какво STAR Fuzzer се различава от AFL++ или libFuzzer? AFL++ и libFuzzer са фазинг платформи, които изискват от инженерите да пишат тестваща обвивка (harness) за всяка отделна цел и ръчно да класифицират сривовете. STAR Fuzzer от Bright Security сам подбира целите, генерира и верифицира тестващите обвивки, триажира грешките спрямо тяхната достижимост и въздействие и предоставя откритите проблеми директно в pull request с възпроизвеждащ зловреден код.

Могат ли големите езикови модели (LLM) да откриват уязвимости от тип нулев ден в синтактични анализатори (parsers)? Големите езикови модели са ефективни при познати класове програмни грешки, като например непроверена дължина при memcpy или конструиран чрез низове SQL, но те търсят там, където обучението им показва, че би трябвало да има грешки. В зрелия софтуерен код грешките, които остават неоткрити, са тези, които не отговарят на нито един познат модел – именно там еволюционното фазване, ръководено от покритие на кода (coverage-guided fuzzing), е най-силно.

Защо да се използва fuzzer вместо LLM преглед на кода? Една кампания по фазване извършва милиони реални изпълнения върху компилиран код и наблюдава какво точно се случва, докато един LLM прогнозира поведението на базата на изходния код. Изравняването на един милион изпълнения чрез разсъждения на LLM би изисквало около два милиарда токена за всяка отделна цел. Освен това всяка констатация от fuzzer-а идва с входящи данни, които я възпроизвеждат.

Как се проверяват констатациите на STAR Fuzzer? Всяка констатация идва с байтово точен зловреден код, който я възпроизвежда, а Bright Security я преиграва в чист контейнер преди да я докладва. Всеки резултат може също така да бъде възпроизведен отново на базата на записано произволно начално състояние (random seed).

Нуждае ли се STAR Fuzzer от граматики или речникови файлове? Не. Слой за синтактичен анализ, независим от форматите, трансформира всяко начално състояние (seed) в типизирано дърво от полета, така че не се изисква специфична граматика или речник за отделните цели.

Заменя ли STAR Fuzzer DAST? Не. DAST тества работещо приложение отвън навътре през HTTP. STAR Fuzzer тества критични за сигурността функции отвътре навън, без необходимост от стартирано приложение. Bright STAR изпълнява и двете с един и същ агент и със същия формат на предаване чрез pull request.

Какви видове програмни грешки открива STAR Fuzzer? Сривове, замръзвания, изчерпване на оперативната памет (out-of-memory) и неограничени заделяния на памет, дефекти в безопасността на паметта като четене извън границите (out-of-bounds reads) и грешки с отклонение с единица (off-by-one writes), смесване на типове (type confusion), препълване на стека от рекурсивни структури на входящите данни и взривове в алгоритмичната сложност, включително декомпресионни бомби, задействани от входящи данни с размер от само няколко десетки байта.

Кои програмни езици поддържа STAR Fuzzer? C/C++, Rust, Go, Java/Kotlin, .NET, Node, Python и Crystal.

За Bright Security

Bright Security е компания за агентна офанзивна сигурност на приложенията, помагаща на организациите да защитават софтуера със скоростта на разработката, управлявана от изкуствен интелект.

Нейната платформа Bright STAR, задвижвана от изкуствен интелект, интегрира сигурността директно в жизнения цикъл на разработка, автоматизирайки откриването, отстраняването и валидирането при уеб приложения, API и софтуерен код, вписвайки се както в работните процеси на разработчиците, така и в тези на екипите за сигурност на приложенията (AppSec).

Преди това известна като NeuraLegion, Bright Security е със седалище в Калифорния. Научете повече на brightsec.com.