Искусственный интеллект (ИИ) кардинально ускорил и увеличил объемы разработки программного обеспечения. Согласно недавнему опросу Google, 90% разработчиков используют ИИ-инструменты в своей работе, при этом 71% применяют их непосредственно для написания кода. Например, одна компания, сообщившая New York Times, после внедрения продукта Cursor — ИИ-системы для написания кода — увеличила ежемесячный объем создаваемого кода с 25 000 до 250 000 строк. Это привело к значительному росту объема кода, требующего проверки.
Хотя эти инструменты значительно ускоряют процесс создания ПО, они также привносят новые риски. Одно из исследований показало, что 45% кода, сгенерированного ИИ, содержит уязвимости безопасности, а запросы на слияние (pull requests), созданные ИИ, в среднем содержат в 1,7 раза больше проблем, чем те, что написаны человеком. Современные средства безопасности способны выявлять эти проблемы, генерируя беспрецедентное количество обнаружений и уязвимостей. Однако главная трудность для большинства команд безопасности и инженеров заключается в следующем шаге. В условиях огромного потока ИИ-генерированного кода команды безопасности не справляются с темпами, им сложно определить, какие именно проблемы представляют реальную угрозу. Статические уровни критичности рассматривают каждую помеченную проблему одинаково, что усложняет процесс приоритизации. Разрозненные и неинтегрированные инструменты безопасности замедляют устранение проблем, вынуждая разработчиков постоянно переключать контекст, чтобы оценить каждую угрозу. И чем больше отчетов об уязвимостях нужно проанализировать, тем выше вероятность того, что реальные риски будут упущены.
Требуется более интеллектуальный уровень между обнаружением и разработкой — такой, который бы подтверждал выявленные угрозы, определял, что действительно может быть эксплуатировано, и предлагал решения, которые разработчики могут применить, не отрываясь от своего рабочего процесса.
Обнаружение угроз работает, но что дальше?
Современные инструменты безопасности, использующие статический анализ, динамическое тестирование и автоматическое сканирование, эффективно выявляют уязвимости. Однако более сложная задача состоит в следующем: как командам безопасности определить, какие уязвимости представляют реальный риск, и как донести исправления до разработчиков до того, как эти проблемы попадут в эксплуатацию? Большинство команд по умолчанию используют оценки критичности для управления накопившимися задачами, но эти оценки были разработаны для иной эпохи разработки ПО. Они ранжируют уязвимости по стандартизированной методике, а не с учетом конкретной архитектуры, потоков данных или профиля воздействия конкретного приложения. Уязвимость, оцененная как «критическая» в одном контексте, может быть полностью недостижима в другом. Когда каждое предупреждение требует срочного внимания, в итоге ни одно из них не получает должного. Инженеры перестают реагировать на оценки и начинают действовать интуитивно, что приводит к упущению реальных рисков. Разработка с использованием ИИ лишь усугубляет эту проблему. Увеличивается количество обнаружений, растет «шум», и становится гораздо сложнее отделить важное от неважного. По мере ускорения разработки, окно для выявления и устранения проблем до их попадания в продакшн постоянно сужается.
Интеллектуальный уровень: приоритизация, контекст и оперативные действия
Чтобы пробиться сквозь этот «шум», необходимы инструменты, обеспечивающие интеллектуальный уровень между обнаружением и разработкой, помогающие командам проверять проблемы, приоритизировать их и принимать меры до того, как ситуация выйдет из-под контроля. Это начинается с нескольких ключевых изменений:
- Переход от статического анализа к анализу во время выполнения. Для точного выявления и устранения уязвимостей командам необходимо перейти от статического анализа к анализу в процессе выполнения (runtime analysis). Статический анализ кода оценивает код в момент его написания, не учитывая его поведение при выполнении. Анализ во время выполнения, напротив, повышает точность обнаружения и устанавливает четкую связь между уязвимостью и ее исправлением. В результате, принятие решений по приоритизации становится проще, и команды могут быстрее приступить к устранению проблем.
- Интеграция безопасности в рабочий процесс разработчика. Скорость устранения проблемы зависит от того, насколько быстро информация доходит до разработчиков, насколько она понятна и применима в их текущих рабочих средах. Вынуждать разработчиков покидать привычные ИИ-среды, такие как Cursor или Claude Code, чтобы проверить отдельную панель безопасности, создает ненужные препятствия и замедляет работу. В масштабах проекта такие препятствия превращаются в задержки, и именно в таких задержках уязвимости успевают закрепиться. Разработчикам нужны инструменты безопасности, которые интегрируются непосредственно в их рабочий процесс и функционируют скорее как инженерные инструменты, а не как совершенно отдельная система — сканирование для обнаружения, проверка возможности эксплуатации и предоставление исправления в контексте.
Роль искусственного интеллекта в интеллектуальной системе безопасности
Устранение растущего разрыва между количеством уязвимостей, обнаруженных инструментами безопасности, и реакцией на них команд разработки требует ряда изменений. Чтобы средства безопасности могли идти в ногу с разработкой, поддерживаемой ИИ, они должны стать частью решения. Интегрированный в рабочий процесс разработки, ИИ может помочь командам проверять проблемы, приоритизировать риски по критичности и возможности эксплуатации, а также предоставлять рекомендации, позволяющие разработчикам вносить исправления в режиме реального времени. Вот как это работает:
- Интеграция инструментов безопасности в рабочие процессы разработки. Разработчикам необходимы рекомендации по устранению проблем здесь и сейчас, прямо в тех инструментах, которыми они пользуются ежедневно. Инвестиции в инструменты безопасности, интегрированные с ИИ-средами разработки кода, позволяют командам снизить трение в рабочем процессе, исключить переключение контекста и ускорить этапы устранения ошибок.
- Отказ от статической оценки критичности. Статические оценки со временем теряются в общем потоке. Отметка «критическая» не привлечет внимания, особенно если для оценки помеченной уязвимости разработчику придется переключаться на совершенно другое приложение (а затем возвращаться для внесения исправления). Вместо этого команды, переходящие на приоритизацию на основе возможности эксплуатации (т.е., возможности использования уязвимости злоумышленником), гарантируют, что их команды разработки смогут отфильтровать лишний «шум» и в первую очередь устранять уязвимости, представляющие реальный риск.
- Ранняя проверка. Исправлять ошибки гораздо дороже, когда код уже попал в эксплуатацию. Выявляя, проверяя и устраняя проблемы на ранних этапах разработки, команды экономят время и ресурсы, а также снижают общий риск для своей организации.
Организациям не придется выбирать между скоростью и безопасностью при внедрении разработки с использованием ИИ. Вместо этого им нужны инструменты безопасности, которые помогают пробиваться сквозь «шум», соответствовать новой скорости производства и сокращать разрыв между выявленными уязвимостями и их последующим устранением.
Данная статья, подготовленная при участии генерального директора и соучредителя Appknox, представлена в рамках программы TechRadar Pro Perspectives — платформы для публикации мнений ведущих экспертов в сфере технологий. Высказанные здесь мнения принадлежат автору и не обязательно совпадают с позицией TechRadarPro или Future plc. Если вы заинтересованы в публикации материалов, подробности можно найти здесь: https://www.techradar.com/pro/perspectives-how-to-submit
