Актуализация относно Athena и някои непоискани прогнози за това какво предстои

В събота Дарио Амодей публикува We Must Pace the Frontier („Трябва да контролираме темпото на авангарда“). Съгласен съм с него. Прочетете го, ако все още не сте. Прекарах лятото, разглеждайки какво откриват тези модели, и пропастта, която той описва между това, което те могат да правят, и това, за което останалите от нас сме готови, е същата, в която се взирам от май насам.

Най-трудната част от неговия план е тази, която изисква от правителствата да се координират. Те са в трудна позиция: ако регулират твърде малко, американска компания случайно ще създаде оръжието; ако регулират твърде много, то ще бъде създадено другаде, а софтуерът с отворен код така или иначе не подлежи на управление. Там, където правителствата могат да действат, е потреблението: не какво могат да правят моделите, а какво се случва с това, което откриват. Кой пръв получава информация за дадена уязвимост, колко бързо корекцията за сигурност достига до хората, използващи кода, и дали операторите, които не могат да реагират със скоростта на атакуващия, получават преднина. Това представлява Gold Eagle.

Това има значение заради мястото, където реално пада рискът. Опасността в есето на Дарио не е модел в лаборатория. Опасността е модел, насочен към електропреносната мрежа, водоснабдителната система, болничната мрежа – всички те работещи със софтуер на десетилетия със същия уязвим за експлоатиране дизайн. Авангардът е мястото, откъдето идва способността. Потреблението е мястото, където тя нанася щети, и това е краят, който все още можете да защитите.

Така че контролирането на темпото има два края. Краят на авангарда е проблем на Дарио и на правителството, и той е труден. Краят на потреблението е наш: процесите по разкриване на уязвимости, каналите за доставка на корекции за сигурност и самият софтуер – всичко, което трябва да поеме онова, което моделите произвеждат. Контролирането на темпото печели време в края на авангарда. Тази публикация е доклад за състоянието на това как го оползотворяваме, в три части:

  1. Този месец започваме да разкриваме откритията на Athena, като стартираме с 50.
  2. Присъединихме се към Project Glasswing на Anthropic и откриваме наши собствени уязвимости, като ще ви покажа как изглежда това.
  3. Изградихме инфраструктура, за да направим и двете неща възможни, и възнамеряваме да я отворим.

Кратката версия: по-притеснен съм, отколкото бях през май, и по-сигурен какво трябва да се направи по въпроса.

Първите 50

Athena приема открития от юни насам. Данните за входящия поток са публични: повече от 40,000 открития, 42% от които критични или с висок риск, в над 500 проекта, с над 2,000 създадени корекции за сигурност. Това, което не беше публично, е колко от тях задържахме при нас. Генерирането на корекции никога не е било тясното място. Отговорното им разкриване, в мащаб, който никой досега не е опитвал, е истинското предизвикателство.

На 28 септември започваме. Стартираме с около петдесет и нито едно от тях не е от страшните. Това е умишлено. Плашещите открития – активните уязвимости за отдалечено изпълнение на код преди удостоверяване (pre-auth RCE) – минават през Akrites под ембарго, към което ще се върна по-късно. Първите 50 са с нисък залог нарочно: малка партида, която да завърти маховика и да покаже какво се чупи, преди хилядите след тях да го ударят.

Всичките 50 са тихи корекции: уязвимости, които вече са отстранени в основния клон (head), понякога преди години, за които никой никога не е регистрирал CVE. Вашият скенер няма какво да каже за тях, а старите версии все още работят навсякъде. Този модел се появи в Athena почти веднага. Голям дял от това, което моделите откриват, засяга само стари версии, защото моделите сканират това, което реално е внедрено, а внедреното е старо.

При тихите корекции две системи се провалят едновременно и нито една от тях няма вина за това. Разработчиците на основния проект (upstreams) обикновено не сливат корекции към стари версии и имат право да не го правят: кодът е пренаписан преди години, няма клон, в който да се слее, и „надстройте“ е правилният отговор. А слоят за бюлетини за сигурност няма с какво да работи, тъй като не се регистрират CVE идентификатори за неща, които вече са отстранени в основния клон. Това е единственият клас открития, при който предприемането на действия не настъпва ничий чужд процес, просто защото такъв не съществува.

За всяко едно от тях, когато проектът няма механизъм за приемане на корекции за стари версии, ние правим три неща.

Публикуваме корекцията за сигурност. Обикновени .patch файлове в публично хранилище на Chainguard, което прави точно това, което името му подсказва, под оригиналния лиценз на проекта. Това умишлено не е ход от типа „поддържащ от последна инстанция“. Имаме планове и за това и ще стигна до тях по-долу, но те са за проекти, които вече никой не поддържа. Това тук са активни проекти, които вече са отстранили грешката в основния клон. Ние не разклоняваме (fork) нищо, не претендираме за стопанисване, не създаваме ново именовано пространство и не каним никого да компилира от него. Това е просто място, където да поставим корекции за сигурност за хората, които все още не могат да надстроят, и нищо повече. Трайното решение си остава надстройването, но тази стъпка отразява днешната реалност, в която по-голямата част от внедрения софтуер не е надстроен.

Публикуваме бюлетина за сигурност. OSV емисия на Chainguard с напълно изброени диапазони от засегнати версии и точните засегнати символи. Не „вероятно някои версии 2.x“. Партньорските скенери на Athena се интегрират с нея в момента, така че тези данни да се появяват там, където вашият екип вече проверява.

Доставяме корекцията. Версиите с приложени корекции за сигурност пристигат в Chainguard Libraries за всеки клиент на Chainguard в момента, в който бюлетинът стане активен.

Не планираме да се свързваме с поддържащите екипи предварително за всяко едно от тези открития. Те вече се справят с повече шум, отколкото би трябвало, и не искаме да добавяме още към него, най-малкото за грешки, които са отстранили преди години. Ако поддържате проект и занапред бихте предпочели да се свързваме с вас предварително, или имате някакви други притеснения относно това как този процес засяга вашия проект, уведомете ни на cna@chainguard.dev и с радост ще работим с вас.

Ставаме CNA

Преди време тихата корекция беше до голяма степен безобидна. Никой не беше описал грешката, а откриването ѝ от подадения код с корекцията (fix commit) изискваше сериозна експертиза и реално време. Това приключи. Един модел може за един следобед да премине от публичен запис с корекция към работещ експлойт срещу всяка версия, която никога не е получила корекцията. Откритието съществува, независимо дали го публикуваме, или не. Единственият въпрос е дали защитниците също ще получат копие.

След като хората разберат за дадена грешка, светът се нуждае от сигнал за надстройване, а сигналът, с който светът вече разполага, е CVE. Скенерите, каталогът KEV и всеки режим за съответствие разчитат на него. Тихите корекции нямаха такъв. Ето защо, в подкрепа на инициативата Gold Eagle и в партньорство със CISA, Chainguard е в процес да стане орган за номериране на CVE (CVE Numbering Authority – CNA) с обхват уязвимости в софтуера с отворен код, обработени чрез Athena, при които основният проект вече е отстранил недостатъка без идентификатор, или при които не е останал поддържащ екип, който да присвои такъв, и никой по-специфичен CNA не покрива проекта.

Неудобната част: това ще вкара нов шум във вашите скенери. Стари версии, които миналата седмица са се сканирали като чисти, сега ще светнат. Това е по-добре от липса на шум и пробив в сигурността. Тишината в този канал никога не е означавала безопасност – означаваше просто, че никой все още не е погледнал там.

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

Именно тази прецизност е целта. Присвояваме идентификатори само там, където няма основен проект (upstream), към който да се обърнем. Ако дадена уязвимост съществува в последната версия и поддържащият разработчик е откриваем, собственият CNA орган на проекта я регистрира, а ние сме докладващият, никога присвояващият. Всяко присвояване преминава през едни и същи проверки: възпроизведена констатация, никога необработен изход от модел; защитим диапазон от къмити; засегнати версии в реална употреба; уведомен поддържащ разработчик със срок за отговор; и оттегляне, ако поддържащият разработчик ни покаже, че грешим. Проекти, които станат свой собствен CNA, излизат от нашия обхват. Това е преходна роля, а не териториална.

Къде отива всичко останало

Картата за всичко останало е проста. Ако дадена уязвимост съществува в последната версия и поддържащият разработчик е откриваем, това е План А и той минава през Akrites — съвместния орган за разкриване на уязвимости, който Linux Foundation стартира през юни и за чието основаване помогнахме. Ако съществува в последната версия и проектът не се поддържа, това е територия на „поддържащ от последна инстанция“ и ние работим с други членове на Akrites, за да изградим този механизъм вътре в Akrites, където му е мястото. А Gold Eagle, федералният координационен център, създаден вследствие на изпълнителната заповед от юни, е слоят, който представя приоритизираните констатации пред операторите на критична инфраструктура, които не могат да се движат със скоростта на атакуващия.

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

Модел откри всичко това за един следобед

Втората причина да се тревожа е свързана по-малко с процеса и повече с това, което видях. Присъединихме се към Project Glasswing на Anthropic. Много организации вече го направиха до този момент — приблизително 200 в над 15 държави — така че самото ни присъединяване не е новина само по себе си. Важното е какво означава това за Athena: вече разполагаме с Mythos и го пускаме срещу софтуера, който изграждаме и доставяме.

Ето как изглежда едно изпълнение, като съм го избрал, защото това е най-малко успокояващият резултат, който имаме.

Един широко използван проект с отворен код. Едно изпълнение, около шест часа. Тестовата рамка (harness) се върна с повече от дузина потвърдени уязвимости, повечето от които позволяват отдалечено изпълнение на код преди автентикация, достижими без идентификационни данни и без действие от страна на оператора. Всяка една беше възпроизведена три пъти в чиста виртуална машина (VM), преди да бъде зачетена, съгласно правилото, което ще опиша след минута: моделът няма право просто да заяви откритие, хост системата трябва да го възпроизведе. Това не е изоставен пакет. Това е един от най-интензивно сканираните, тествани и подлагани на размито тестване (fuzzing) проекти в екосистемата — код, който е оцелял след години на експертни прегледи и безмилостен фъзинг. Модел откри всичко това за един следобед. Тези констатации преминават през Akrites като откритията на всички останали и тук няма да кажа нищо повече за конкретния проект освен това.

Ето какво ще кажа вместо това. Да наблюдавам какво откриват тези модели и колко време отнема една корекция да стигне до когото и да било, след като я открият — това е нещото, което ме тревожи. Проблемът не е в самите модели. Проблемът е в надпреварата между два часовника. При единия индустрията се опитва да поеме краткосрочен прилив от констатации чрез процеси за разкриване, които вече изоставаха. При другия способностите на атакуващите напредват към точката, в която компрометирането на критична инфраструктура в голям мащаб става евтино. В момента вторият часовник тиктака по-бързо от първия и не виждам нищо, което да затвори тази пропаст от само себе си.

Изолирани среди и изолиране в пясъчник

Което е другата причина изолираната среда да има значение. Генерирането на констатация като горната означава изграждане и детониране на работещ експлойт срещу реален код, отново и отново, управлявано от агент, когото никой не наблюдава в реално време. Това е опасно за изпълнение и това лято беше поредица от примери за хора, които го пускат по небезопасен начин. Инцидентът, около който Дарио изгради своето есе — агентите на OpenAI, които пробиват извън кибероценка и се озовават в продукционната инфраструктура на Hugging Face — започна с уязвимост от тип нулев ден в кеша за пакети, предоставен на агентите. Пакетната инфраструктура е това, което ние изграждаме, така че този случай ни засегна много близко. През юли Pillar Security прекара една седмица в публикуване на бягства от изолирана среда при Cursor, Codex, Gemini CLI и Antigravity, а констатацията, която ги свързваше, беше, че агентът почти никога не пробиваше пясъчника фронтално. Той записваше файл, който му беше позволено да запише, а нещо доверено извън изолираната среда го стартираше по-късно. Нито един от тези случаи не беше проблем на недостатъчни пясъчници. Те бяха проблем на недостатъчно изолиране в пясъчник: границата съществуваше, а всичко интересно се случваше в пролуките около нея. Списъците със забрани (denylists) не ограничават по-добре, отколкото контейнерите.

Всичко, което Athena прави — от разработването на експлойт до доказването, че дадена корекция за сигурност затваря пробойната — се изпълнява вътре в microVM, същия примитив, върху който нашите компилации на пакети, изграждания на образи и CI работят от години. Мат описа архитектурата през юли. Кратката версия: всяка задача получава хардуерно виртуализирана гост система със собствено ядро и коренова файлова система, изградена от нулата, изходящият трафик се контролира принудително на ниво хипервайзор и е разрешен чрез списък с позволени адреси единствено до регистрите за пакети и нищо друго, първата забранена връзка унищожава виртуалната машина и никакви идентификационни данни никога не влизат в гост системата. И тъй като споделеният примитив умножава радиуса на поражение на всяка слабост, ние насочваме AI агенти към самата изолирана среда с инструкции да я пробият. Всяка констатация първо се превръща в неуспешен тест, а след това идва и корекцията.

Тестовата рамка започва с човек

Тестовата рамка (harness), която се изпълнява вътре в тези изолирани среди, е частта, която намирам за най-интересна, и тя започва с човек. Иън Биър прекара около шест месеца в писане на верига от експлойти за iOS без взаимодействие (zero-click), и ако прочетете техническия му анализ като процес на търсене, можете да видите формата му: пробване на целта, навлизане в дълбочина, сблъсък със задънена улица, връщане назад и в крайна сметка свързване на достатъчно точки, за да се стигне до работещ експлойт. Никой човек не може да задържи шест месеца от такъв процес в работната си памет. Той го съхраняваше в бележки и извличаше нужния му фрагмент при всяка сесия. Неговият бележник беше средата.

Това е, което изградихме, разпределено между много агенти паралелно: търсене в дървовидна структура, при което всеки агент започва начисто с ограничен обхват и синтезирана следа от вече известното, а приемствеността се съхранява в трайни констатации, а не в нечий контекстен прозорец. Правилото, на което държа най-много, е, че хостът има решаващия глас, никога моделът. Една констатация се зачита само ако хостът може да я възпроизведе срещу чиста инстанция: проверката се проваля преди това, възпроизвеждането се изпълнява, проверката преминава успешно след това. Нищо не влиза в регистъра, докато реалността не го потвърди, и това единствено правило е основната причина делът на фалшиво положителните резултати да е толкова нисък.

Няколко неща, които научихме, докато изграждахме това, ако работите по нещо подобно:

  • Свеж контекст, ограничена задача. Всеки агент започва начисто с ограничен обхват. Приемствеността се крие в констатациите, написани като за непознат, а не в транскрипцията.
  • Всеки запис е обвързан с доказателства. Без предварително условие, последващо условие и изпълнимо от хоста възпроизвеждане, нищо не влиза в регистъра.
  • Проучването насочва, то не доказва. То решава къде да погледне агентът след това и никога не се брои за констатация.
  • Записвайте и задънените улици като констатации. Фалшиво положителният резултат се сблъсква с реалността и отмира от само себе си. Фалшиво отрицателният резултат е тих, постоянен и е провалът, който всъщност ви коства дълбоките грешки.
  • Преценката побеждава размера на флотилията от агенти. При търсене като това преценката на модела на всяка стъпка за това къде да търси е основата на степенния показател, а паралелизмът се появява само вътре в логаритъма. Не можете да компенсирате по-лошата преценка с купуване на повече агенти. Това е конкретната, немаркетингова причина да искаме Mythos и защо Glasswing има по-голямо значение от това колко агента можете да пуснете.

Сглобете парчетата и цикълът се затваря. Откриване, изолиране, коригиране, доставяне. Всичко това върху един примитив.

Какво изградихме, за да направим това, и какво отваряме за достъп

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

Изолираната среда е онази microVM, за която току-що прочетохте: изолационната граница, която ни позволява да изпълняваме ненадежден код и враждебни агенти, без радиусът на поражение да достига до нищо съществено. Работната рамка е търсенето, което се изпълнява вътре в нея – нещото, което откри онези уязвимости за отдалечено изпълнение на код преди удостоверяване (pre-auth RCE). А третото е непрекъснатата интеграция (CI) като функция: нашата собствена флотилия от агенти спря да изпраща код към CI система преди година. Проверките се изпълняват вътре в цикъла и промените пристигат вече доказани, при над десет пъти по-голям обем на CVE уязвимости от този, с който се справяхме преди.

Изградихме и трите, защото се налагаше; управляваме цялата си дейност върху тях и през следващите тримесечия ще започнем да ги отваряме за директен достъп. Ако изпълнявате ненадеждни работни натоварвания с изкуствен интелект, или се опитвате да откриете реални уязвимости в собствения си код, или се давите в CI система, която ви казва по-малко, отколкото бихте искали, това са инструментите, към които посегнахме ние. Скоро и вие ще можете да посегнете към тях.

И така, каква е крайната цел тук?

Ето и непоисканата прогноза. В момента всички се тревожат за zero-day уязвимостите от Mythos, а почти никой не успяваше да насмогне и с обикновените CVE уязвимости, преди всичко това да започне. Средностатистическото предприятие изостава с месеци с корекциите за сигурност, за които от години има решения, бюлетини и покритие от скенери. Това е системата, в която сме на път да излеем хиляди нови констатации. По-бързото разкриване и по-бързото инсталиране на корекции за сигурност помагат само на хората, които могат да действат по тях, а по-голямата част от света не може да се движи със скоростта, задавана от един модел. Ако трябва да си вземете едно нещо от тази публикация, нека бъде това: потопът идва, а тръбите вече бяха пълни.

Ето защо нищо от горното не е финалната права. Всичко в тази публикация ни прави по-бързи и всичко то приема една губеща предпоставка: че целта е да се поддържа темпото спрямо скоростта на откриване, задавана от водещите модели. Класовете уязвимости, които тези модели експлоатират, не са дефекти в днешния софтуер. Те са неговият дизайн. Повреждане на паметта, десериализация, инжектиране, объркани посредници (confused deputies): последствия от това как са били изградени технологичните стекове под всяко корпоративно приложение. Не можете да се измъкнете от една архитектура чрез инсталиране на корекции за сигурност.

Така че крайната цел са нови основи: стек, изграден да бъде сигурен по замисъл, където доминиращите класове уязвимости изобщо не могат да бъдат написани, изпълняващ ролята, която Spring Boot изпълнява днес, във всеки корпоративен програмен език, под програмните рамки и регистрите, от които те черпят. В продължение на четиридесет години разходите за миграция защитаваха всяка утвърдена платформа. Никой не пренаписа кода на COBOL, защото никой не можеше да си го позволи. Агентите току-що сринаха тази цена.

Работим върху това и ще кажа повече, когато има какво повече да се каже. Защо ние: ние виждаме световните констатации преди публичното им оповестяване по-рано от почти всеки друг, така че знаем кои класове грешки имат значение, и разполагаме с единствения инструмент, който може да докаже, че дадена основа ги е премахнала. Насочете Mythos към нея, преди да я пуснете в употреба, и ще знаете.

Дарио е прав, че контролирането на темпото купува време, и всичко по-горе е начинът, по който ние го оползотворяваме. Но контролираното темпо на водещите технологии има значение само ако софтуерът отдолу преживее технологичната граница, която вече сме достигнали. Ако доминиращите класове уязвимости не могат да бъдат написани, критичната инфраструктура, изградена върху тях, не може да бъде пробита чрез тях и един водещ модел в неподходящи ръце ще има много по-малко неща, до които да се добере. Контролирането на темпото ограничава риска чрез забавяне на способностите. Основите го ограничават чрез премахване на мишената и това е единствената версия на нещата, която виждам, която слага край на бягащата пътека, вместо просто да тичаме по-бързо по нея.

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

Ако поддържате проект, до който се докосва нещо от това, или ако откривате уязвимости, присъединете се на chainguard.dev/athena. А ако нещо от това ви звучи като нещо, което искате да изграждате, ние наемаме хора.