AWS Continuum закрыў 89% поўных задач — але тэст бачыць толькі C і C++

Апублікаваны 5 кастрычніка 2026 года тэхнічны допіс AWS паведамляе, што сістэма Continuum for code vulnerabilities прайшла 819 з 920 поўных задач CyberGym-E2E у межах 90 хвілін на задачу: 89,0%, або 89% пры акругленні. Залік азначае, што агент знайшоў і ўзнавіў збой, выправіў яго, а праект пасля змены прайшоў свае функцыянальныя тэсты. Набор прысвечаны ўразлівасцям бяспекі памяці ў кодзе на C і C++.

Папярэдні публічны максімум па той жа асноўнай метрыцы складаў 65,9%, а асобная праверка выпраўлення менавіта гістарычнай уразлівасці дала Continuum 37,8%, вынікае з агляду CiberSeguridad Latam. Таму вынік гаворыць пра паспяховы цыкл пошуку і выпраўлення ўзноўленага збою, а не пра ліквідацыю кожнай уразлівасці ў рэпазіторыі. Для каманды бяспекі гэта істотнае адрозненне: праходжанне тэстаў пацвярджае ўласцівасці канкрэтнага патча ў межах заданай праверкі.

Што трапляе ў заданне CyberGym-E2E

Апісанне CyberGym-E2E задае 920 задач на аснове рэальных уразлівасцей у 139 праектах з адкрытым кодам. Агент атрымлівае ўразлівую версію праграмы разам са сродкамі зборкі і тэстамі, працуе непасрэдна ў яе асяроддзі і павінен сам стварыць уваходныя даныя, якія выклічуць збой. Такі фармат змушае даследаваць зыходнікі і паводзіны праграмы, перш чым прапаноўваць выпраўленне.

На старце агенту не раскрываюць апісанне памылкі, гатовы прыклад яе ўзнаўлення, журнал аварыйнага завяршэння або патч, якім уразлівасць калісьці выправілі. Выкананне ідзе ў ізаляваным кантэйнеры: знешняя сетка недаступная, а абароненыя файлы ацэнкі змяняць нельга. Трэба спачатку здабыць доказ, што знойдзены шлях сапраўды прыводзіць да збою.

Аснова набору — гістарычныя памылкі ў праектах з адкрытым кодам. Для машыннай праверкі патрэбны ўвод, які можна зноў запусціць на ўразлівай зборцы, і патч, паводзіны якога можна параўнаць з паводзінамі старой версіі. Гэта робіць вынік больш канкрэтным за простае сцвярджэнне агента, што ён знайшоў падазроны код: збой павінен адбыцца пры выкананні праграмы.

Чатыры паслядоўныя этапы ацэнкі

Кожны наступны этап залічваецца толькі пасля папярэдняга. Асноўная метрыка спыняецца на праверцы працаздольнасці выпраўленага праекта; заключная праверка паказвае, ці супала знойдзеная памылка з той, якую аўтары набору выбралі для гэтага задання.

1. S1 — узнаўленне. Уваходныя даныя, створаныя агентам, павінны выклікаць збой у пачатковай уразлівай зборцы. Падазрэнне, выказанае толькі на падставе агляду кода, заліку не дае.
2. S2 — ліквідацыя знойдзенага збою. Пасля прымянення патча той жа ўваход больш не павінен аварыйна спыняць праграму. Этап звязвае выпраўленне з праблемай, якую агент сам прадэманстраваў.
3. S3 — захаванне функцыянальнасці. Выпраўлены праект павінен прайсці існыя функцыянальныя тэсты. Паспяховае праходжанне гэтага этапу разам з папярэднімі і ёсць асноўны залік поўнай задачы.
4. S4 — гістарычная ўразлівасць. Асобны дыягнастычны тэст высвятляе, ці ліквідуе патч таксама збой, які адпавядае эталоннай памылцы ў заданні.

Розніца паміж асноўным залікам і заключнай праверкай мае тэхнічную прычыну. У адной версіі праекта могуць існаваць некалькі сапраўдных памылак; агенту не кажуць, якую з іх пазначылі стваральнікі набору. Ён можа адшукаць іншую праблему, даць уваход, які яе ўзнаўляе, і выправіць яе без парушэння правяраных функцый. Такі вынік праходзіць асноўную метрыку, нават калі патч не закранае эталонную ўразлівасць.

Што паказвае перавага над папярэднім максімумам

Параўнанне мае сэнс менавіта для аднолькавага этапу: сістэма AWS часцей даводзіла заданне да патча, які спыняе знойдзены збой і захоўвае функцыі, ахопленыя тэстамі. Вынік Continuum належыць усёй шматагентнай сістэме з інструментамі, а не адной моўнай мадэлі.

У Continuum працэс падзелены паміж пошукам магчымых памылак, іх пацвярджэннем праз узнаўленне і падрыхтоўкай патча. Доказ збою пераходзіць з аднаго этапу ў наступны, таму выпраўленне можна праверыць супраць таго самага ўваходу. Такая арганізацыя тлумачыць, што менавіта ацэньваецца: здольнасць усёй канфігурацыі выканаць паслядоўную працу з уразлівым кодам у зададзены час.

Абмежаванне часу таксама ўплывае на вынік. Калі агенту даць даўжэй працаваць над складаным шляхам праз зыходнікі і тэсты, доля завершаных задач можа змяніцца; такія запускі ўжо нельга без агаворкі змешваць з афіцыйным вынікам пры часовым ліміце. Для параўнання важныя не толькі назва набору і працэнт, але і аднолькавыя ўмовы выканання.

Дзе заканчваецца ахоп тэсту

CyberGym-E2E сканцэнтраваны на збоях бяспекі памяці, якія фіксуюцца санітайзерам падчас выканання C або C++ праграмы. Назіральны збой дазваляе пабудаваць аўтаматычны ланцуг праверак: да патча праграма аварыйна завяршаецца, пасля яго гэты ўваход не выклікае збою, а функцыянальныя тэсты па-ранейшаму праходзяць. Выразнасць такога сігналу робіць задачы прыдатнымі для паўторнай ацэнкі.

Іншыя мовы і класы памылак патрабуюць іншых спосабаў пацвярджэння. Напрыклад, хіба ў аўтарызацыі можа адкрываць чужыя даныя, хоць праграма працягне працаваць без аварыйнага завяршэння. Няправільныя правы доступу, небяспечная канфігурацыя і памылкі бізнес-логікі таксама могуць ствараць рызыку без збою, які выяўляе санітайзер. Працэнт, атрыманы на задачах бяспекі памяці, не вымярае здольнасць сістэмы закрываць гэтыя выпадкі.

Вытворчы прыярытэт уразлівасці залежыць яшчэ і ад асяроддзя разгортвання: даступнасці сэрвісу звонку, сеткавых шляхоў да яго, дазволаў і налад. У заданні з зыходным кодам такога кантэксту няма. Патч, які прайшоў бенчмарк, паказвае дасягнуты вынік у ізаляванай праграме; рызыка для канкрэтнага сэрвісу залежыць таксама ад таго, дзе і з якімі правамі гэты код працуе.

Чытайце таксама:

• Toggl ці Harvest: аднолькавыя $9, але рахунак ёсць толькі ў аднаго
• GPT-6 Sol і Luna сталі таннейшымі, але прызначаны для розных задач
• GitHub схаваў частку абмеркавання ўразлівасцей — REST API яе не бачыць