HackerOne присоединилась к проекту Project Glasswing для развития киберзащиты с помощью передового ИИ, применив Claude Mythos 5 к нашей собственной производственной среде. В июле мы развернули изолированный конвейер для работы с нашим кодом и проводили эксперименты в течение 30 дней.
Вот что мы выяснили.
Критическая RCE чуть не осталась незамеченной
При первом запуске против нашей кодовой базы Mythos обнаружил критическую уязвимость удаленного выполнения кода (RCE) без экспозиции в продакшене. Мы устранили ее менее чем за 48 часов. Хотя условия развертывания предотвращали ее эксплуатацию, изменение, сделанное в любой из дней, могло сделать ее доступной.
Самым интересным был не сам факт обнаружения. Интересно то, как эта уязвимость туда попала.
RCE возникла в результате трех по отдельности безопасных изменений кода:
- Динамическая диспетчеризация методов, защищенная строго типизированным перечислением схемы GraphQL. Безопасно в контексте перечисления.
- Новая версия аналитики, в которую добавлен нетипизированный аргумент фильтра. Безопасно в контексте нового фильтра аналитики.
- Рефакторинг объединил их вместе. Безопасно в узком контексте отрефакторенных компонентов, но не для связанных ими систем.
Предположение системы типов не сработало. Она направила нетипизированный ввод в первый построитель запросов, которому никогда не требовался белый список на уровне приемников. Система типов должна была справиться с этим на более раннем этапе. Уязвимость RCE существовала только тогда, когда все три изменения находились в продакшене одновременно.
Мы называем это композиционным риском: уязвимости, которые кроются не в каком-то одном коммите, а в том, как безопасные по отдельности изменения взаимодействуют со временем. Традиционный анализ кода оценивает пул-реквесты изолированно; он структурно слеп к этому классу проблем. Статический анализ всего приложения имел больше шансов найти что-то подобное, так как он анализирует все дерево целиком, а не по одному дифф-файлу за раз. Однако эти инструменты с трудом моделируют пользовательские приемники и часто не могут разрешить динамическую диспетчеризацию.
Что сделало Mythos, так это проследило нить через коммиты и авторов до тех пор, пока не нашло место сбоя логики. Модель проанализировала историю репозитория, реконструировала намерения разработчиков разных авторов и применила методы наступательной безопасности ко всему графу вызовов. Не только к диффу.
Три вещи, которые мы поняли, запустив передовую модель на собственном коде
После обнаружения RCE мы провели серию структурированных экспериментов. Три вещи выделяются особенно.
1. Как эволюционируют модели
Mythos не только нашла больше уязвимостей, чем предыдущие модели, но и более сложные. Мы запустили тесты на двух независимых тестовых стендах, чтобы исключить артефакты настройки. Прирост заключается в полноте охвата (recall). Она находит больше того, что реально существует, с сопоставимой точностью.
2. Устранение уязвимостей — это и есть настоящая работа
Несколько недель сканирования привели к сотням находок. Именно здесь валидация — подтверждение того, что уязвимость эксплуатируема, и присвоение ей степени тяжести — может стать узким местом для организаций. Модель генерирует находки быстрее, чем организации традиционно выделяли ресурсы на их триаж, маршрутизацию и патчинг. Инновации и ускорение в области валидации и устранения уязвимостей крайне необходимы, чтобы поспевать за возможностями обнаружения передовых моделей.
3. Развитие нашего тестового стенда и средств защиты
Запуск Mythos подтвердил то, в чем мы убеждаемся снова и снова: по мере развития моделей фокус работы смещается. Если раньше время уходило на то, чтобы объяснить модели, как думать, то теперь оно уходит на рецензирование найденного и управление тем, как эти находки преподносятся.
Сегодня мы отдельно отслеживаем находки, которые модель сначала отметила, а затем аргументированно отвергла сама. Это позволяет нам отличать уровень валидации, фильтрующий шум, от того, который подавляет реальные проблемы. Мы также добавили критерий покрытия: запуск, который исследовал лишь часть кодовой базы, может выдать находки, выглядящие столь же полноценно, как и результаты проверки всей базы целиком, поэтому теперь тестовый стенд отклоняет запуски, которые перед формированием отчета проверили недостаточно большой объем поверхности.
Еще один урок касается памяти. Поскольку модели теперь способны отслеживать годы коммитов в системах с множеством репозиториев, нам пришлось выстроить защитные механизмы вокруг того, как они интерпретируют историю вклада. Пример тому — так называемый анализ первопричин без поиска виновных (RCA): принцип, согласно которому уязвимости безопасности порождаются системой и процессом работы, а не конкретным человеком. Это справедливо даже тогда, когда код пишет ИИ-агент. Агент является продолжением инструментария разработчика, и имя разработчика остается на коммите. Тестовый стенд строго придерживается этой рамки.
Композиционный риск масштабируется вместе с вашей кодовой базой, и многие команды к этому не готовы
Композиционный риск — это проблема не только HackerOne. Любая организация, выпускающая код на высокой скорости, накапливает неявные предположения между подсистемами, авторами и временем. Большинство из них верны. Некоторые — нет, и те, что неверны, не проявят себя до тех пор, пока не сложатся нужные условия.
Mythos представляет собой инструмент, способный проводить рассуждения на фоне всего этого накопленного объема. Она не просто указывает на плохую строчку кода. Она реконструирует полный контекст того, почему нечто представляет опасность, охватывая множество авторов и коммитов за долгое время.
Создание инфраструктуры для реагирования на находки передовых моделей
Запуск Mythos на нашей собственной платформе был только началом. Более масштабная задача — создание инфраструктуры для реагирования на ее находки: масштабная валидация, маршрутизация, доставляющая результаты до нужных инженерных команд без трений, и верификация исправлений, которая замыкает цикл, а не просто закрывает тикеты.
Наше участие в Project Glasswing ограничивается исключительно нашей собственной инфраструктурой. Доверие исследователей очень важно для нас, поэтому мы хотим внести ясность в то, как конфиденциальные данные обрабатываются на платформе: HackerOne не использует конфиденциальные отчеты исследователей или данные о клиентских уязвимостях для обучения, тонкой настройки или иного улучшения генеративных моделей ИИ.
Более подробную информацию вы можете найти в нашей документации по безопасности и доверию (Hai Security and Trust) и в блоге Responsible AI на HackerOne.
Об авторе
Нидхи Аггарвал
Директор по продукту (Chief Product Officer)
Нидхи занимает должность директора по продукту в HackerOne, где она руководит реализацией видения и стратегии продуктовой платформы компании. Она является технологическим предпринимателем и бизнес-лидером с более чем 15-летним опытом стимулирования роста и трансформации в технологических компаниях.
