Лидеры мнений

Для безопасности ИИ нужен второй взгляд

mm
Добавьте Unite.AI в избранные источники в Google

ИИ пишет код быстрее, чем мы успеваем его защищать. Вы не отстаёте?

Пока вы дочитаете это предложение, разработчики и их ИИ-агенты успеют отправить в репозитории пару тысяч коммитов. Год назад в это же время их было бы около 150.

За последний год разработка программного обеспечения с помощью ИИ ускорилась до поразительных темпов. В сентябре 2026 года GitHub зафиксировал 7,38 миллиарда коммитов только за один месяц — более чем в пять раз больше, чем годом ранее. Последствия этого взрывного роста для безопасности крайне серьёзны. Каждый из этих коммитов — это код, который кому-то предстоит понять, поддерживать и защищать. Cloud Security Alliance выяснила, что разработчики, использующие ИИ, в компаниях из списка Fortune 50 отправляют код в три-четыре раза чаще своих коллег, а число выявленных у них за месяц проблем безопасности выросло примерно в десять раз.

Теперь подумайте, кому приходится справляться с этим ростом. Команда директора по информационной безопасности (CISO) по-прежнему состоит из столько же человек, сколько и год назад, а очередь задач — уже нет. Число сообщений об уязвимостях растёт, количество исправлений за месяц сокращается, а число неустранённых критических уязвимостей увеличивается. Неудивительно, что Gartner заявляет: выгорание директоров по информационной безопасности становится критическим операционным риском.

Соблазн выбрать самую новую модель

Когда число настолько велико, возникает соблазн стремиться к ещё большему: находить больше проблем, расширять охват, запускать больше сканирований. Но это всё равно что вычерпывать воду из тонущей лодки и просить ведро побольше, хотя нужно найти течь. Эффективность программы безопасности определяется не количеством обнаруженных проблем. Она определяется тем, какая доля найденного действительно представляет собой проблему и сколько наиболее критичных уязвимостей в итоге устраняют.

Передовые модели ИИ отлично находят новые эксплойты и не внесённые в каталоги уязвимости благодаря вероятностному анализу. Но результаты различаются. Согласно исследованию Checkmarx, при пяти запусках одного и того же сканирования одного и того же кода совпадает лишь примерно треть обнаруженных проблем.

Именно поэтому анализ на основе правил по-прежнему важен. Он менее гибок, чем передовой ИИ, но каждый раз применяет проверенную логику одинаково, поэтому команды могут доверять результатам и проверять их. ИИ обнаруживает то, что упускают правила: например, известные слабые места в непривычном виде или уязвимости, которые можно использовать лишь при взаимодействии разных частей кода. Вместе ИИ и анализ на основе правил выявляют больше действительно важных проблем и дают меньше ложных срабатываний.

Всё это не аргумент против ИИ. Это аргумент в пользу того, что безопасности нужно второе мнение. Какой бы инструмент вы ни выбрали, задайте ему три вопроса.

Первый вопрос: достоверность

Если сканер сообщает о проблеме, стоит ли она вашего времени?

Достоверность — это доверие. Если обнаруженная проблема не существует, разработчик теряет полдня, а специалисты по безопасности — ещё немного доверия к себе. При большом масштабе именно ложные срабатывания заставляют команды перестать прислушиваться. Оповещения превращаются в очередную ложную тревогу и сливаются с фоновым шумом.

Вот почему важна стабильность результатов. Детерминированный анализ каждый раз выдаёт один и тот же ответ для одного и того же кода, что укрепляет доверие и позволяет проводить аудит результатов.

Второй вопрос: точность

Находите ли вы все наиболее важные проблемы?

Достоверность показывает, стоит ли найденная проблема вашего времени, но не говорит о том, что пропустил сканер. Мы используем принятую в науке о данных метрику под названием F1-мера. Она оценивает качество работы по шкале 1–0 с учётом двух факторов:

  • Точность: доля выявленных проблем, которые действительно существуют. Высокая точность означает меньше ложных срабатываний.
  • Полнота: доля реальных уязвимостей, которые сканер действительно обнаруживает. Высокая полнота означает, что почти ничего не ускользает от внимания.

Сканер может казаться точным, если отмечает почти ничего, или тщательным, если отмечает всё, но в обоих случаях показатель F1 будет низким. Средний показатель по отрасли — около 0,20. Мы много работали над этой проблемой и добились результатов, которые в три-четыре раза точнее результатов стандартного сканера.

Более высокая точность упрощает разработчикам все последующие этапы работы. Ваша команда тратит меньше времени на проверку и больше — на устранение проблем.

Третий вопрос: окупаемость инвестиций (ROI)

Как максимально эффективно использовать инвестиции и ресурсы?

Этот вопрос чаще всего упускают из виду на этапе пилотного проекта, а в рабочей среде ответ на него обходится особенно дорого.

За передовые модели платят за каждый токен, и токены расходуются независимо от того, находит сканирование проблемы или нет. Сканирование репозитория с миллионом строк кода по текущим опубликованным ценам обходится более чем в тысячу долларов. Кроме того, расход токенов у разных моделей сильно различается: цена варьируется в зависимости от выбранной модели и объёма рассуждений, необходимых для выполнения задачи.

Умножьте эти расходы на каждый коммит, запрос на слияние и репозиторий в крупной компании. По сообщениям, Uber, ежегодно тратящая 3,4 миллиарда долларов на исследования и разработки, израсходовала весь бюджет на ИИ на 2026 год за несколько месяцев после внедрения инструментов для написания кода с помощью ИИ.

Мы называем это налогом на токены. Это всё равно что ехать за продуктами на Ferrari: вы платите за мощность, которая для такой поездки не нужна. Зашитые в код учётные данные и SQL-инъекции — предсказуемые шаблоны, которые детерминированный анализ надёжно выявляет.

Безопасность приложений должна развиваться

Именно так устроена архитектура Checkmarx Fusion. Механизмы на основе правил формируют воспроизводимую эталонную основу, требуя при этом меньше затрат, чем анализ с использованием токенов. Передовые модели применяются для выявления того, что не могут предвидеть правила: новых шаблонов, сложной логики и возможности эксплуатации уязвимостей с учётом контекста. Затем слой анализа результатов объединяет их в единый надёжный набор.

Детерминированный анализ обеспечивает достоверность. ИИ расширяет охват. Вместе они повышают и охват, и доверие к результатам. По сравнению с отдельно работающей большой языковой моделью мы достигаем до четырёхкратного повышения точности соответствия, в два-четыре раза большей точности и примерно трети затрат.

Выявить проблемы — это только начало. Та же логика применима и к предотвращению. Рассмотрим пример. Если дать разработчикам нужные возможности непосредственно в момент создания кода — в IDE, где они его пишут, — мы сможем предотвратить проблемы ещё до их появления. И если уязвимости всё же проскальзывают, почему бы не предоставить разработчикам готовые к слиянию исправления для наиболее важных из них? Именно эти задачи мы и решаем, стремясь постепенно сократить существующую очередь проблем и добиться максимально быстрого эффекта с минимальными усилиями.

Код уже работает. Успеваете за ним?

ИИ подарил злоумышленникам скорость. Чтобы сократить этот разрыв, недостаточно добавить ещё один инструмент. Нужно решить, как вся ваша организация разрабатывает и защищает программное обеспечение. Код, который пишут сегодня, будет работать на ваш бизнес годами. Перед руководителями по безопасности теперь стоит не вопрос о том, насколько быстрее ИИ помогает создавать программное обеспечение. Важно другое: смогут ли ваши программы поспевать за тем, что создаёт ИИ.

Поэтому не зацикливайтесь на цифрах. Задайте любой программе три вопроса: могу ли я доверять тому, что она находит? Выявляет ли она достаточно всего самого важного? Реально ли внедрить её во всей моей организации? Сочетание точности детерминированного анализа с рассуждениями передовых моделей даёт наилучшие шансы ответить «да» на все три вопроса.

Разработка программного обеспечения не замедляется. Теперь наша задача — сократить разрыв в оценке рисков: расстояние между скоростью создания программного обеспечения и скоростью выявления и устранения рисков.

В качестве директора по продуктам Джонатан руководит разработкой продуктовой стратегии и формированием видения платформы безопасности приложений Checkmarx One. За свою карьеру он получил признание за руководство командами разработчиков в Mercury Software — лидере в области тестирования программного обеспечения, которую HP Software приобрела за 4,5 миллиарда долларов. После этого он увеличил бизнес по тестированию с 700 миллионов до более чем 1 миллиарда долларов благодаря органическому росту и приобретению компаний в сфере безопасности.

В течение последних восьми лет Ренде занимал должности старшего вице-президента и генерального директора по продуктам в PagerDuty — ведущей корпоративной облачной платформе для ИИ-операций. Там он руководил дальнейшим масштабированием организации и разработкой нового поколения продуктов для Operations Cloud от PagerDuty, уделяя особое внимание машинному обучению, ИИ и автоматизации, развивая бизнес как органически, так и за счет приобретений.