OpenAI

21 жовтня 2026 р.

ЗахистПродукт

Patch the Planet: глобальне реагування на критичні вразливості, які виявляють агенти

Протягом останніх двох місяців ми очолювали коаліцію супроводжувачів, дослідників і постачальників рішень із безпеки, щоб усунути критичні вразливості в PHP — мові програмування з відкритим кодом, на якій працюють сайти й вебзастосунки. Calif виявила критичну вразливість за допомогою GPT‑5.6 Sol у межах нашої ініціативи Patch the Planet⁠(відкривається у новому вікні). Wiz також незалежно виявила обидві вразливості й повідомила про них. Супроводжувачі PHP очолили роботу над виправленнями та їх випуском. Наші команди й партнери, зокрема Wiz і Cloudflare, долучилися з дослідженнями, технічною підтримкою та координацією, щоб підготувати захист до оприлюднення інформації.

Для організацій, які використовують PHP, зараз головне — встановити виправлення. Ми публікуємо засіб перевірки версії PHP як навичку Codex⁠(відкривається у новому вікні) для адміністраторів: він допоможе виявити потенційно вразливі версії PHP та, разом із рекомендаціями PHP і постачальників послуг, визначити потрібні оновлення.

З огляду на серйозність цих вразливостей і поширеність PHP, ми вважаємо цю проблему безпеки однією з наймасштабніших за останній час. Це показує, як ШІ може виявляти вразливості з наслідками для всього інтернету. Водночас ці можливості можуть допомагати зловмисникам швидко створювати інструменти для атак та експлойти.

Наскільки нам відомо, передовий ШІ знайшов ці вразливості раніше за зловмисників, відкривши вікно можливостей для захисників: час, щоб супроводжувачі й постачальники рішень із безпеки підготували виправлення та захист до оприлюднення.

Щоб більше захисників могли скористатися цими можливостями, ми зобов’язалися надати субсидований доступ до Daybreak на 1 млрд доларів через програму Daybreak for Frontline Defenders. Вона орієнтована на організації, які захищають життєво важливі послуги, маючи обмежені ресурси безпеки.

Попри свою серйозність, ці помилки — лише частина значних вразливостей, які ми вже знайшли й над усуненням яких працюємо. Ми очікуємо, що найближчими місяцями кількість подібних знахідок різко зросте. Спираючись на набутий досвід, ми пропонуємо підхід до реагування на критичні вразливості в поширеному ПЗ, адаптований до епохи ШІ, і просимо спільноту фахівців із безпеки допомогти його вдосконалити. Він поєднує наші моделі, досвід у сфері безпеки та роботу супроводжувачів, щоб перетворювати знахідки на захист і масштабувати реагування в міру розвитку ШІ.

Координація глобального реагування

Впровадження виправлення може потребувати адаптації для старіших версій, підготовки захисних заходів постачальниками послуг та оновлення систем у багатьох організаціях. Відтворюваний процес допомагає цим командам діяти швидко, коли виявляють нові вразливості.

Через Patch the Planet ми надали експертну підтримку з безпеки й доступ до моделей для реагування на вразливості PHP, а також разом із супроводжувачами та дослідницькими партнерами тестували виправлення й готували рекомендації. Ми також допомогли скоординувати захист уразливих систем із постачальниками інфраструктури та залучили державні кібербезпекові відомства, щоб донести рекомендації до критично важливих організацій. Це підтримало реагування під керівництвом супроводжувачів і допомогло іншим захисникам підготуватися.

У деяких випадках дослідники можуть напряму співпрацювати із супроводжувачами ПЗ, щоб дослідити проблему й розробити виправлення. Інші випадки потребують ширшого реагування, бо зачіпають багато продуктів або дистриб’юторам і постачальникам послуг потрібен час для підготовки оновлень і захисту. Цього часу може бракувати, якщо передові можливості не надто випереджають загальнодоступні. У таких випадках запропонований підхід допоможе супроводжувачам визначити, кого залучити, і скоординувати роботу. Реагування може охоплювати п’ять етапів:

  • Підтвердити й усунути вразливість у вихідному проєкті. Супроводжувач, дослідники й ключові технічні партнери підтверджують знахідку, оцінюють її вплив, розробляють і тестують виправлення. Цей процес включає тестування з імітацією атак за допомогою передових моделей для пошуку способів обійти виправлення та споріднених варіантів вразливості.

  • Дати час на дії організаціям, яких стосується вразливість. Ми пропонуємо підхід до визначення організацій, яким завчасно потрібна інформація для підготовки захисту. Рішення про залучення ухвалюють супроводжувачі. Ми допомагаємо налагоджувати контакти, укладати угоди про обмін інформацією та координувати команди. Дистриб’ютор може адаптувати виправлення для старішої версії, хостинг-провайдер — протестувати захисний захід, а постачальник рішень із безпеки — підготувати засоби виявлення чи запобігання атакам, зокрема правила брандмауера вебзастосунків (WAF).

  • Координувати дії з державними партнерами для захисту критично важливих систем. Державні установи відіграють ключову роль у координації ширшого реагування й поширенні рекомендацій із безпеки серед організацій, відповідальних за критичну інфраструктуру та інші життєво важливі послуги. У випадку PHP ми разом із партнерами налагоджували взаємодію з органами влади США, зокрема групою з питань суперінтелекту Білого дому, Офісом національного директора з кібербезпеки (ONCD) та Агентством із кібербезпеки й безпеки інфраструктури (CISA), а також із міжнародними партнерами.

  • Підготувати оновлення для всіх уразливих продуктів. Коли виправлення, рекомендації та плани оприлюднення набувають остаточної форми, супроводжувачі можуть залучити інших дистриб’юторів, хостинг-провайдерів і постачальників послуг, команди реагування й адміністраторів, щоб підготувати оновлення та закрити прогалини в захисті.

  • Після випуску виправлення опублікувати рекомендації та підтримати впровадження. Публічні рекомендації допомагають оцінити ризики, знайти офіційні оновлення чи тимчасові захисні заходи й перевірити, чи діє виправлення. Реагування триває, поки адміністратори впроваджують оновлення й повідомляють, де їм потрібна допомога.

Запропонований підхід враховує роль організації в захисті, зокрема власних систем і клієнтів, потрібний для дій час та її здатність працювати з конфіденційною інформацією. До зіставних організацій застосовувалися б однакові критерії, а супроводжувачі вирішували б, кого залучити до оприлюднення.

Кожен учасник отримує потрібну для захисту інформацію: від мережевих журналів з індикаторами компрометації до більш чутливих даних — працездатних демонстраційних експлойтів. Навіть обмежені відомості можуть розкрити вразливість, тому ми зіставляємо ризик їх поширення із захистом, який вони дають змогу забезпечити.

За цим підходом команди разом із супроводжувачами давали б захисникам час на підготовку та переглядали б строки в разі активної експлуатації вразливості, витоку, публічного виправлення, що розкриває її суть, або зростання ризику для користувачів через затримки з усуненням.

Сайт Patch the Planet⁠(відкривається у новому вікні) об’єднує публічні повідомлення про вразливості й рекомендації, щоб адміністратори могли виявити вразливі системи, знайти потрібне оновлення та перевірити, чи правильно працює оновлене ПЗ. Для PHP він містить посилання на офіційне виправлення й інструкції з оновлення від супроводжувачів, а також технічні дослідження наших партнерів. Рекомендації також охоплюють тимчасові захисні заходи, залучення постачальника послуг чи експерта, резервне копіювання та відновлення. Тимчасовий захист може знизити ризик, але ми чітко пояснюватимемо його обмеження й компроміси для роботи систем.

Адміністратори можуть скористатися рекомендаціями CISA щодо пріоритетів та усунення вразливостей⁠(відкривається у новому вікні), щоб оцінити терміновість дій з огляду на вразливість систем до атак, факти експлуатації та можливі наслідки. Це може означати екстрене встановлення виправлень, негайні захисні заходи або планове оновлення. За потреби варто також провести первинний криміналістичний аналіз, щоб з’ясувати, чи системи вже скомпрометовано. Пріоритети слід переглядати зі зміною умов, зберігаючи чіткий план остаточного усунення вразливостей.

Можливості й ресурси для реагування супроводжувачів

Глобальна координація залежить від людей, які супроводжують програмне забезпечення. Багато проєктів ведуть невеликі команди, які розглядають повідомлення про вразливості паралельно з поточною розробкою. Цим командам потрібна допомога, щоб відрізняти нові проблеми від повторних повідомлень, оцінювати вплив і тестувати виправлення в усіх підтримуваних версіях. Ми підтримуємо цю роботу фінансуванням, доступом до потужних моделей і практичною інженерною допомогою.

Потужні можливості ШІ розвиваються в усій галузі. Ми очікуємо, що ШІ дедалі більше допомагатиме захисникам знаходити вразливості, відстежувати стан систем і реагувати на загрози. Ми інвестуємо в моделі, інструменти й партнерства, щоб допомогти захисникам застосувати ці можливості на практиці.

Наші інвестиції включають підписки для всіх супроводжувачів через Codex for OSS і пряме спонсорування таких проєктів, як Rust Foundation⁠(відкривається у новому вікні), для підтримки супроводжувачів і технічної роботи. Кожен проєкт сам визначає свої пріоритети. Тести й процеси безпеки, придатні для повторного використання, можуть зменшити зусилля, потрібні для опрацювання майбутніх знахідок. Проєкти з відкритим кодом можуть подати заявку до Patch the Planet⁠(відкривається у новому вікні), щоб отримати практичну підтримку.

Ми також калібруємо додаткові класифікатори блокування для Daybreak, щоб зменшити можливості для зловживань. Це потребує складних компромісів: запобіжники проти зловживань можуть блокувати й законну роботу з безпеки. І широкий доступ до потужних моделей, і дієвий захист від зловживань є критично важливими. Наша мета — зберегти можливості, потрібні захисникам для пошуку й усунення вразливостей, водночас обмежуючи шкідливе використання. Ми й далі вдосконалюватимемо цей баланс у міру розвитку можливостей і накопичення досвіду використання цих інструментів.

Створення безпечнішої основи для програмного забезпечення

З розвитком моделей відкриваються можливості, що виходять за межі пошуку й усунення окремих вразливостей. Ми хочемо допомогти інженерам створювати безпечніше ПЗ від самого початку. Удосконалення поширеного компонента може запобігти помилкам або обмежити їхній вплив у багатьох продуктах і сервісах.

ШІ може допомогти інженерам розібратися в наявному коді, підготувати зміни й розробити тести, а супроводжувачі та експерти з безпеки перевірятимуть, чи зберігають ці зміни поведінку ПЗ, на яку покладаються користувачі. Ми бачимо можливості в кількох напрямах:

  • Безпечний код від самого початку. Моделі для програмування можуть допомогти розробникам вибирати безпечніші типові налаштування, правильно використовувати бібліотеки безпеки та виявляти ризиковані конструкції під час написання коду. Запобігання вразливостям під час розробки означає менше екстрених виправлень для супроводжувачів і користувачів.

  • ПЗ із безпечним керуванням пам’яттю. Перенесення критично важливих компонентів на мови з безпечним керуванням пам’яттю може усунути поширені класи помилок роботи з пам’яттю. ШІ може допомагати з міграцією, а тести й експертний аналіз — перевіряти поведінку та сумісність.

  • Формальна верифікація. Математичні докази можуть показати, що критично важливі компоненти мають задані властивості безпеки за визначених припущень. Застосування цих методів до поширених компонентів могло б виключити цілі класи вразливостей у сервісах і критичній інфраструктурі, які від них залежать.

  • Надійніша ізоляція. Системи потребують захисту від вразливостей, які ще не знайшли або не усунули. Запуск ПЗ, яке обробляє недовірені файли, зображення чи медіадані, у суворо обмежених ізольованих середовищах може зменшити шкоду в разі його компрометації. ШІ може допомогти інженерам тестувати й посилювати поширені технології ізоляції, поліпшуючи захист багатьох застосунків.

Допоможіть нам удосконалити цей підхід

Ми ділимося нашим підходом, щоб супроводжувачі, дослідники, команди реагування, постачальники послуг та адміністратори допомогли зробити його дієвим на практиці. Ми хочемо зрозуміти, де він допоможе, де може спричинити затримки чи додаткове навантаження і що ми не врахували. Особливо корисними були б приклади з попередніх випадків оприлюднення вразливостей.

Нас особливо цікавлять такі питання:

  • Строки оприлюднення. Скільки часу потрібно супроводжувачам, адміністраторам і захисникам, щоб підготувати та впровадити надійні виправлення? Які факти мають стати підставою для ранішого оприлюднення, особливо коли одних користувачів можна захистити швидше за інших?

  • Екстрене встановлення виправлень. Чи варто державним органам або іншим операторам після втрати адміністративного доступу використовувати вразливість для виправлення систем, якими вони володіють або уповноважені керувати? Якщо так, то коли? Які запобіжники мають діяти? Ми можемо уявити кінцевий результат: безперервне сканування всього інтернету на відомі вразливості та, в разі виявлення, сповіщення власників сайтів або встановлення виправлень у системі.

  • Завчасне сповіщення. Кому потрібне завчасне попередження, щоб ужити дієвих захисних заходів, зокрема серед захисників, яких ми могли не врахувати? Коли поетапні сповіщення дієвіші за одночасне інформування ширшого кола учасників і як зіставляти охоплення з ризиком витоку?

  • Програмні пакети, безпечні за замовчуванням. Як допомогти виявляти й усувати вразливості в похідних пакетах, поки виправлення у вихідних проєктах ще готуються, або переносити виправлення до старіших версій, які вже не отримують оновлень безпеки? Які тестування й супровід зробили б ці пакети надійною альтернативою, коли своєчасний перехід на новішу версію неможливий?

Також будемо вдячні за рекомендації незалежних експертів із безпеки, які можуть оцінити цей підхід, поставити під сумнів його припущення й виявити прогалини. Ваші пропозиції допоможуть нам удосконалити реагування й визначити пріоритети підтримки. Поділіться відгуком тут⁠(відкривається у новому вікні).

Автор

OpenAI