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

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

Когато проект, който съзнателно сме пазили в тайна, прессъобщение за пет милиарда долара и Белият дом достигнат до една и съща дума в рамките на няколко седмици, това не е просто тенденция. Тенденциите са незадължителни. Това е формата на един проблем, който се променя под краката на всички едновременно. Затова позволете ми да обясня защо се появяват тези неща, защо повечето от тях няма да имат значение и защо малкото, които имат такова, тихо се надпреварват да се самозакрият.

Клиринговите къщи не са нещо ново за софтуера с отворен код. Имаме ги от десетилетия.

NVD е клирингова къща. Такава е и базата данни за съвети за сигурност на GitHub (GitHub Advisory Database), както и OSV, и всеки поток от данни за сигурност, от който някога сте теглили информация. Всеки доставчик с портал за уязвимости също управлява такъв, предназначен за собствения му софтуер. Всички те са едно и също нещо: база от данни за уязвимости с входна врата.

„Клиринговите къщи“, обявени това лято, не са нов вид, но събират нов тип данни: уязвимости преди публичното им оповестяване, разпръснати по дългата опашка на софтуера с отворен код. Някои в критични проекти, други в малки проекти, за които никой не е чувал; някои в най-новата версия, други в каквато и да е по-стара версия, която се е оказало, че работи. Това се равнява на най-неорганизирания, но най-задълбочен проект за изследване на сигурността, сглобяван някога. И поради модела на Unix процесите, всички те имат еднакво значение: грешка в най-неизвестната зависимост се изпълнява с абсолютно същите привилегии като приложението, което я е заредило, така че и най-малкото листо на дървото може да предаде целия процесен поток.

Ако базата данни не е нова, тогава тя не е същината на историята.

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

Това е частта, която Chainguard прави от години, намирайки се по веригата след всяка публична клирингова къща. Нашата система за изграждане следи хиляди проекти с отворен код и реагира в момента, в който се появи известие за сигурност: изтегляне, компилиране от изходен код, тестване, подписване. Повечето CVE уязвимости се коригират за около два дни, като огромното мнозинство никога не се докосват от човешка ръка. Поддържаме еднодневен SLA за уязвимостите, за които CISA твърди, че се експлоатират активно. Коригирали сме над 100 000 от тях. Данните от клиринговата къща винаги са били само входният материал. Фабриката беше продуктът.

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

Забравете за клиринговите къщи за секунда: защо изведнъж има наводнение от частни уязвимости в софтуера с отворен код и защо всички сканират един и същ код? Отговорът е, че никой не си го е поставял за цел. Това е страничен продукт.

Най-добрият начин да получите реален сигнал от модел като Mythos не е да го насочите към файл и да го помолите любезно. А да го поставите пред работещо приложение – реално изпълняващото се нещо, с прикачен дебъгер, пясъчник за игра, изходния код в контекст – и да му подадете неясна, състезателна подкана: „Счупи това“. И той го прави.

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

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