OpenAI запустила программу совместно с фирмой по кибербезопасности Trail of Bits для использования ИИ с целью поиска и устранения уязвимостей в широко используемом программном обеспечении с открытым исходным кодом, поскольку предприятия сталкиваются с растущими рисками, связанными с недостатками, скрытыми глубоко в их цепочках поставок ПО.
Инициатива под названием Patch the Planet использует исследования уязвимостей с помощью ИИ наряду с человеческой проверкой, чтобы помочь преобразовать результаты аудита безопасности в протестированные исправления, которые могут быть раскрыты через существующие каналы проектов.
В число первоначальных участников входят Python, Go, cURL, Sigstore, NATS Server, aiohttp, freenginx, pyca/cryptography и python.org. Эти проекты поддерживают разработку программного обеспечения, сетевые технологии, криптографию и инфраструктуру цепочки поставок, используемые в широком спектре корпоративных приложений и сервисов.
OpenAI заявила, что каждое взаимодействие начнется с консультации с мейнтейнерами для определения того, где поддержка безопасности наиболее необходима. Затем исследователи будут изучать потенциальные уязвимости, проверять значимые проблемы, разрабатывать или дорабатывать исправления, поддерживать тестирование и координировать раскрытие информации через существующие каналы проекта.
Участвующие исследователи в области безопасности будут использовать модели компании и Codex Security для анализа кода и содействия внедрению исправлений. Инженеры Trail of Bits будут проверять результаты перед отправкой мейнтейнерам — это шаг, призванный отфильтровать ложные срабатывания и дублирующиеся отчеты, прежде чем они увеличат рабочую нагрузку проектов с открытым исходным кодом.
Компания также сотрудничает с HackerOne и Calif для поддержки триажа уязвимостей, скоординированного раскрытия информации и дополнительной работы по обнаружению по мере расширения программы.
OpenAI сообщила, что в рамках программы уже были выявлены «сотни проблем безопасности и объединены десятки исправлений, при этом многие другие все еще проходят скоординированное раскрытие информации».
Эта работа также привела к созданию инструментов для фаззинга, анализа исторических CVE и дифференциального тестирования, а также систем для фильтрации неточных результатов до генерации исправлений, добавили в OpenAI.
Фокус на безопасности открытого исходного кода последовал за такими инцидентами, как Log4Shell и бэкдор XZ Utils, которые продемонстрировали, как быстро ошибка в общем компоненте может распространиться по корпоративному ПО.
Аналитики считают, что Patch the Planet изменит уравнение риска только в том случае, если предприятия будут рассматривать исследования уязвимостей с помощью ИИ как один из вкладов в более широкую программу управления рисками цепочки поставок ПО, а не как ее замену.
«Ключевое изменение — это скорость: исследования с помощью ИИ могут помочь быстрее находить, проверять, исправлять, тестировать и документировать проблемы, в то время как человеческие рецензенты уменьшают количество ложных срабатываний до того, как мейнтейнеры будут перегружены», — заявил Бисваджийт Махапатра, ведущий аналитик Forrester. «Но зависимость от дефицитного опыта никуда не исчезает; она смещается в сторону триажа, оценки эксплуатируемости, безопасности исправлений, сроков раскрытия информации и развертывания в продакшене».
Ограничители перед развертыванием
Руководителям по информационной безопасности (CISO) следует внедрить механизмы управления, прежде чем использовать исследования уязвимостей с помощью ИИ в корпоративных конвейерах безопасности, чтобы гарантировать, что непроверенные результаты не перегрузят инженерные команды, — считает Девашри Датта, архитектор по кибербезопасности открытого исходного кода.
«CISO должны требовать наличия уровня релевантности безопасности (Safety Relevance Layer) в своей модели рисков — структурированной основы, которая требует, чтобы каждый результат, сгенерированный ИИ, прошел автоматическую проверку, включая динамическую проверку концепции (proof-of-concept) и строгую фильтрацию ложных срабатываний, прежде чем он попадет к аналитику-человеку», — сказал Датта.
Эти механизмы контроля также должны охватывать раскрытие информации, особенно когда инструменты ИИ выявляют недостатки в сторонних компонентах с открытым исходным кодом, которые предприятие не контролирует, добавил Датта. Организации нуждаются в заранее определенных путях эскалации, сроках уведомления и назначении ролей, которые вступают в силу после обнаружения подтвержденной проблемы во внешней зависимости.
«Ад хок раскрытие информации в среде, ускоренной ИИ, — это не просто пробел в процессе; это зона ответственности», — отметил Датта. «Доверие к ИИ в производственном конвейере требует проверяемой аудируемости: организации должны иметь возможность отследить, почему ИИ пометил строку кода, как он проверил эксплойт и как он определил, что исправление не нарушит работу систем в продакшене».
Постоянное снижение подверженности
Аналитики считают, что исследования уязвимостей с помощью ИИ могут вынудить предприятия отказаться от периодических циклов установки исправлений в пользу более непрерывной оценки рисков. Если анализ вариантов и дифференциальное тестирование могут быть сжаты с недель до дней, командам безопасности могут потребоваться более быстрые способы определения того, какие результаты наиболее важны в их собственных средах.
Этот сдвиг также означает, что предприятия больше не могут полагаться только на общие оценки CVSS для определения приоритетов устранения, сказал Датта. Результаты необходимо будет оценивать с учетом затронутой системы, ее бизнес-роли, подверженности в рантайме и вероятности эксплуатации уязвимости.
«Мы должны двигаться к приоритизации, осведомленной о контексте и критичной для безопасности», — заявил Датта. «Корпоративные программы SBOM и VEX должны трансформироваться из пассивных таблиц соответствия в живые, машиночитаемые потоки данных. Для конвейеров, ускоренных ИИ, это означает расширение модели VEX для охвата поверхностей риска, вносимых ИИ».
Махапатра отметил, что программы управления уязвимостями также должны будут стать более тесно связанными с владением программным обеспечением, реакцией поставщиков и влиянием на бизнес.
«Команды безопасности должны перейти от периодической обработки уязвимостей к постоянному снижению подверженности», — сказал Махапатра.
Это означает, что SBOM следует рассматривать как живые инвентарные списки, привязанные к подверженности в рантайме и реакции поставщика, а не как статические документы о соответствии. Решения об установке исправлений также должны учитывать критичность актива, возможность эксплуатации, компенсирующие меры и влияние на бизнес.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Prasanth Aby Thomas
