Patch the Planet: globalna koordynacja reakcji na krytyczne luki odkrywane przez agenty
Przez ostatnie dwa miesiące staliśmy na czele koalicji opiekunów projektów, badaczy i dostawców zabezpieczeń, by usunąć krytyczne luki w PHP — języku programowania open source używanym do obsługi stron i aplikacji internetowych. Calif wykrył krytyczną lukę za pomocą GPT‑5.6 Sol w ramach naszej inicjatywy Patch the Planet(otwiera nowe okno). Obie luki niezależnie odkryła i zgłosiła też firma Wiz. Opiekunowie PHP koordynowali przygotowanie i wydanie poprawek. Nasze zespoły oraz partnerzy, w tym Wiz i Cloudflare, wsparli badania, prace techniczne i koordynację, by przygotować zabezpieczenia przed ujawnieniem luk.
Dla organizacji korzystających z PHP priorytetem jest teraz wdrożenie poprawek. Udostępniamy narzędzie do sprawdzania wersji PHP jako umiejętność Codex(otwiera nowe okno), które pomaga administratorom identyfikować potencjalnie podatne wersje PHP i ustalać, które aktualizacje wdrożyć, z uwzględnieniem wytycznych zespołu PHP i dostawców.
Ze względu na wagę tych luk i powszechne użycie PHP uznajemy je za jeden z najpoważniejszych problemów bezpieczeństwa ostatnich lat. Pokazuje to, jak AI może wykrywać luki w zabezpieczeniach, których skutki mogą być odczuwalne na ogromną skalę w całym internecie. Te same możliwości mogą jednak pomagać atakującym szybko tworzyć narzędzia ofensywne i exploity.
Według naszej wiedzy pionierska AI znalazła te luki przed atakującymi, otwierając okno możliwości dla obrońców — czas, w którym opiekunowie projektów i dostawcy zabezpieczeń mogli przygotować poprawki i zabezpieczenia jeszcze przed ujawnieniem informacji o lukach.
Aby udostępnić te możliwości większej liczbie obrońców, zobowiązaliśmy się przeznaczyć miliard dolarów na dofinansowanie dostępu do Daybreak w ramach programu Daybreak for Frontline Defenders, skierowanego do organizacji chroniących kluczowe usługi, które dysponują ograniczonymi zasobami na bezpieczeństwo.
Choć te błędy są poważne, to tylko część istotnych luk, które już znaleźliśmy i nad których usunięciem pracujemy. Oczekujemy, że w najbliższych miesiącach liczba podobnych odkryć gwałtownie wzrośnie. Na podstawie dotychczasowych doświadczeń proponujemy dostosowany do ery AI sposób reagowania na krytyczne luki w powszechnie używanym oprogramowaniu. Prosimy społeczność zajmującą się bezpieczeństwem o pomoc w jego udoskonaleniu. Łączymy nasze modele i wiedzę o bezpieczeństwie z pracą opiekunów projektów, by przekuwać odkrycia w ochronę i rozwijać zdolność reagowania wraz ze wzrostem możliwości AI.
Wdrożenie poprawki może wymagać dostosowania jej do starszych wydań, przygotowania środków zaradczych przez dostawców i aktualizacji systemów w wielu organizacjach. Powtarzalny proces pomaga tym zespołom szybko reagować na kolejne odkrywane luki.
W ramach Patch the Planet wsparliśmy działania dotyczące PHP wiedzą o bezpieczeństwie i dostępem do modeli. Wraz z opiekunami projektu i partnerami badawczymi testowaliśmy poprawki i przygotowywaliśmy wytyczne. Pomagaliśmy też koordynować prace dostawców infrastruktury nad ochroną zagrożonych systemów i włączyliśmy rządowe agencje cyberbezpieczeństwa w przekazywanie wytycznych organizacjom o kluczowym znaczeniu. Wsparło to działania prowadzone przez opiekunów projektu i pomogło innym obrońcom się przygotować.
Przy niektórych odkryciach badacze mogą współpracować bezpośrednio z opiekunami oprogramowania, by zbadać problem i opracować poprawkę. Inne wymagają szerszych działań, bo dotyczą wielu produktów lub dystrybutorzy i usługodawcy potrzebują czasu na przygotowanie aktualizacji i zabezpieczeń. Tego czasu może być niewiele, jeśli możliwości pionierskich modeli nie wyprzedzają znacznie tych powszechnie dostępnych. W takich przypadkach proponowany schemat działania może pomóc opiekunom projektów ustalić, kogo należy zaangażować, i koordynować prace. Reakcja może obejmować pięć etapów:
Potwierdzenie i usunięcie luki w projekcie źródłowym. Opiekun projektu, badacze i kluczowi partnerzy techniczni potwierdzają odkrycie, oceniają jego skutki oraz opracowują i testują poprawkę. Proces obejmuje testy symulujące ataki z użyciem pionierskich modeli, by szukać sposobów obejścia poprawki i pokrewnych wariantów luki.
Zapewnienie zagrożonym organizacjom czasu na działanie. Proponujemy wprowadzenie zasad pozwalających ocenić, które organizacje potrzebują wcześniejszej informacji, by przygotować zabezpieczenia. Decyzję o tym, kogo zaangażować, podejmują opiekunowie projektów. Pomagamy nawiązywać kontakty, zawierać umowy o wymianie informacji i koordynować pracę zespołów. Dystrybutor może dostosować poprawkę do starszego wydania, dostawca hostingu — przetestować środki zaradcze, a dostawca zabezpieczeń — przygotować mechanizmy wykrywania lub zapobiegania atakom, w tym reguły zapory aplikacji internetowych (WAF).
Koordynacja z partnerami rządowymi w celu ochrony krytycznych systemów. Agencje rządowe odgrywają kluczową rolę w koordynowaniu szerszych działań i przekazywaniu wytycznych bezpieczeństwa organizacjom odpowiedzialnym za infrastrukturę krytyczną i inne niezbędne usługi. W przypadku PHP wraz z partnerami zabiegaliśmy o zaangażowanie wielu instytucji rządowych USA, w tym zespołu Super Intelligence Force w Białym Domu, Biura Krajowego Dyrektora ds. Cyberbezpieczeństwa (ONCD) i Agencji ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA), a także partnerów międzynarodowych, by wesprzeć te działania.
Przygotowanie aktualizacji dla zagrożonych produktów. Gdy poprawka, wytyczne i plany ujawnienia są już dopracowane, opiekunowie projektów mogą zaangażować kolejnych dystrybutorów, dostawców hostingu i usług, zespoły reagowania oraz administratorów, by przygotować aktualizacje i uzupełnić braki w ochronie.
Publikacja wytycznych i wsparcie wdrożenia po udostępnieniu poprawki. Publiczne wytyczne pomagają ocenić narażenie na zagrożenie, znaleźć aktualizacje z wiarygodnych źródeł lub tymczasowe środki zaradcze i sprawdzić, czy poprawka działa. Działania trwają nadal, gdy administratorzy wdrażają aktualizacje i zgłaszają, gdzie potrzebują pomocy.
Proponowane zasady uwzględniają rolę organizacji w zapewnianiu ochrony, w tym ochrony własnych systemów i klientów, czas potrzebny na działanie oraz zdolność do bezpiecznego obchodzenia się z informacjami wrażliwymi. Te same kryteria obowiązywałyby porównywalne organizacje, a opiekunowie projektów decydowaliby, kogo zaangażować przed ujawnieniem luki.
Każdy uczestnik otrzymuje informacje niezbędne do zapewnienia ochrony — od dzienników sieciowych ze wskaźnikami kompromitacji po bardziej wrażliwe materiały, takie jak działające exploity typu proof of concept. Nawet niewielka ilość informacji może ujawnić lukę, dlatego zestawiamy ryzyko ich udostępnienia z ochroną, którą umożliwiają.
Zespoły stosujące te zasady współpracowałyby z opiekunami projektów, by dać obrońcom czas na przygotowania. Weryfikowałyby też harmonogram w razie rzeczywistych ataków, wycieku, publikacji poprawki ujawniającej lukę lub wzrostu ryzyka dla użytkowników wskutek opóźnień w jej usunięciu.
Strona Patch the Planet(otwiera nowe okno) gromadzi publiczne informacje o lukach i wytyczne, by pomóc administratorom zidentyfikować zagrożone systemy, znaleźć właściwą aktualizację i sprawdzić, czy zaktualizowane oprogramowanie działa prawidłowo. W przypadku PHP odsyła do oficjalnej poprawki i instrukcji aktualizacji od opiekunów projektu oraz badań technicznych naszych partnerów. Wytyczne obejmują też tymczasowe środki zaradcze, sytuacje wymagające pomocy dostawcy lub eksperta oraz tworzenie kopii zapasowych i przywracanie danych. Tymczasowe zabezpieczenia mogą zmniejszyć ryzyko, ale jasno wskażemy ich ograniczenia i kompromisy związane z eksploatacją.
Administratorzy mogą skorzystać z wytycznych CISA dotyczących priorytetów i działań naprawczych(otwiera nowe okno), by ustalić, jak szybko należy zareagować, uwzględniając stopień narażenia, wykorzystywanie luk w atakach i potencjalne skutki. Może to oznaczać awaryjne wdrożenie poprawek, natychmiastowe środki zaradcze lub zaplanowaną aktualizację, a w uzasadnionych przypadkach także wstępną analizę śledczą, by ustalić, czy doszło już do naruszenia bezpieczeństwa systemów. Priorytety należy weryfikować wraz ze zmianą warunków, zachowując jasny plan trwałego usunięcia zagrożenia.
Globalna koordynacja zależy od ludzi, którzy utrzymują oprogramowanie. Wiele projektów prowadzą małe zespoły, które analizują zgłoszenia dotyczące bezpieczeństwa równolegle z bieżącymi pracami rozwojowymi. Zespoły te potrzebują pomocy w odróżnianiu nowych problemów od powielonych zgłoszeń, ocenie skutków i testowaniu poprawek we wspieranych wydaniach. Wspieramy te działania, zapewniając finansowanie, dostęp do zaawansowanych modeli i bezpośrednią pomoc inżynierów.
Zaawansowane możliwości AI rozwijają się w całej branży. Oczekujemy, że AI będzie coraz bardziej pomagać obrońcom w wykrywaniu luk, monitorowaniu systemów i reagowaniu na zagrożenia. Inwestujemy w modele, narzędzia i partnerstwa, by pomóc obrońcom wykorzystać te możliwości w praktyce.
Nasze inwestycje obejmują subskrypcje dla wszystkich opiekunów projektów w ramach Codex for OSS oraz bezpośrednie finansowanie inicjatyw takich jak Rust Foundation(otwiera nowe okno), z przeznaczeniem na wsparcie opiekunów i prace techniczne. Każdy projekt ustala własne priorytety. Testy i procedury bezpieczeństwa wielokrotnego użytku mogą zmniejszyć nakład pracy przy obsłudze kolejnych odkryć. Projekty open source mogą zgłosić się do Patch the Planet(otwiera nowe okno), by uzyskać bezpośrednie wsparcie.
Dostrajamy też dodatkowe klasyfikatory blokujące dla Daybreak, by ograniczyć ryzyko nadużyć. Wymaga to trudnych kompromisów: zabezpieczenia zapobiegające nadużyciom mogą też blokować uprawnione działania na rzecz bezpieczeństwa. Zarówno szeroki dostęp do zaawansowanych modeli, jak i skuteczna ochrona przed nadużyciami mają kluczowe znaczenie. Chcemy zachować możliwości potrzebne obrońcom do wykrywania i usuwania luk, a zarazem ograniczać szkodliwe zastosowania. Będziemy nadal dążyć do właściwej równowagi w miarę rozwoju możliwości i zdobywania wiedzy o wykorzystaniu tych narzędzi.
Wraz ze wzrostem możliwości modeli otwierają się perspektywy wykraczające poza wykrywanie i usuwanie pojedynczych luk. Chcemy pomagać inżynierom tworzyć bezpieczniejsze oprogramowanie od samego początku. Ulepszenia powszechnie używanego komponentu mogą zapobiegać błędom lub ograniczać ich skutki w wielu produktach i usługach.
AI może pomagać inżynierom rozumieć istniejący kod, przygotowywać zmiany i tworzyć testy. Opiekunowie projektów i eksperci ds. bezpieczeństwa sprawdzają przy tym, czy zmiany nie zakłócają działania oprogramowania w sposób istotny dla użytkowników. Dostrzegamy możliwości w kilku obszarach:
Bezpieczny kod od samego początku. Modele do programowania mogą pomagać programistom wybierać bezpieczniejsze ustawienia domyślne, poprawnie korzystać z bibliotek zabezpieczeń i wychwytywać ryzykowne wzorce już podczas pisania kodu. Zapobieganie powstawaniu luk podczas tworzenia oprogramowania oznacza mniej awaryjnych poprawek dla opiekunów projektów i użytkowników.
Oprogramowanie bezpieczne pamięciowo. Przeniesienie krytycznych komponentów do języków bezpiecznych pamięciowo może wyeliminować typowe klasy błędów pamięci. AI może wspierać migracje, a testy i weryfikacja przez ekspertów pozwalają sprawdzić działanie i zgodność.
Weryfikacja formalna. Dowody matematyczne mogą wykazać, że krytyczne komponenty spełniają określone właściwości bezpieczeństwa przy wskazanych założeniach. Zastosowanie tych metod do powszechnie używanych komponentów mogłoby pomóc wykluczyć całe klasy luk w usługach i infrastrukturze krytycznej, które od nich zależą.
Silniejsza izolacja. Systemy potrzebują ochrony przed lukami, których jeszcze nie znaleziono lub nie usunięto. Uruchamianie oprogramowania przetwarzającego niezaufane pliki, obrazy lub multimedia w ściśle ograniczonych środowiskach izolowanych może zmniejszyć szkody w razie jego przejęcia. AI może pomagać inżynierom testować i wzmacniać powszechnie stosowane technologie izolacji, poprawiając ochronę w wielu aplikacjach.
Przedstawiamy nasze podejście, by opiekunowie projektów, badacze, zespoły reagowania, dostawcy i administratorzy mogli pomóc dostosować je do realiów pracy. Chcemy zrozumieć, gdzie byłoby pomocne, gdzie mogłoby powodować opóźnienia lub dodatkowe obciążenia i co pominęliśmy. Szczególnie przydatne byłyby przykłady z wcześniejszych przypadków ujawniania luk.
Interesują nas zwłaszcza:
Czas do ujawnienia luki. Ile czasu potrzebują opiekunowie projektów, administratorzy i obrońcy na przygotowanie i wdrożenie niezawodnych poprawek? Jakie dowody powinny skłaniać do wcześniejszego ujawnienia luki, zwłaszcza gdy część użytkowników można ochronić szybciej niż innych?
Awaryjne wdrażanie poprawek. Czy — i kiedy — instytucje rządowe lub inni administratorzy powinni wykorzystać lukę do wdrożenia poprawki po utracie dostępu administracyjnego do systemów, które do nich należą lub którymi mają prawo zarządzać? Jakie zabezpieczenia powinny wtedy obowiązywać? Możemy sobie wyobrazić docelowe rozwiązanie polegające na ciągłym skanowaniu całego internetu w poszukiwaniu znanych luk oraz powiadamianiu właścicieli witryn o ich wykryciu lub wdrażaniu poprawek w systemie.
Wczesne powiadamianie. Kto potrzebuje wcześniejszego ostrzeżenia, by podjąć skuteczne działania ochronne — w tym obrońcy, których możemy przeoczyć? Kiedy powiadamianie etapami sprawdza się lepiej niż jednoczesne informowanie szerszej grupy i jak wyważyć zasięg ochrony względem ryzyka wycieku?
Domyślnie bezpieczne pakiety oprogramowania. Jak możemy pomóc wykrywać i usuwać luki w pakietach pochodnych, gdy poprawki w projekcie źródłowym nie są jeszcze gotowe, lub przenosić poprawki do starszych wersji, które nie otrzymują już aktualizacji bezpieczeństwa? Jakie testy i prace utrzymaniowe uczyniłyby te pakiety niezawodną alternatywą, gdy szybka aktualizacja nie jest możliwa?
Chętnie przyjmiemy też rekomendacje dotyczące niezależnych ekspertów ds. bezpieczeństwa, którzy mogliby ocenić to podejście, zakwestionować jego założenia i wskazać braki. Wasze uwagi pomogą nam udoskonalić sposób reagowania i ustalić priorytety wsparcia. Tutaj możesz podzielić się opinią(otwiera nowe okno).
