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