AWS представила трёхуровневый конвейер для приоритизации результатов сканеров уязвимостей с помощью ИИ

Современные сканеры уязвимостей генерируют находки быстрее, чем команды успевают их обрабатывать вручную. Разработчики выпускают больше кода с большим числом зависимостей — вместе с этим растёт и объём кандидатов на разбор. Большинство находок сканера вряд ли будут эксплуатированы, но те, что действительно важны, должны быстро попадать к инженеру вместе с достаточными доказательствами, чтобы он мог действовать немедленно, а не повторять анализ заново. Ключевая задача — отделить сигнал от шума на той скорости, которую требует пайплайн. В AWS Security Blog показали, как сократить разрыв между обнаружением и действием: трёхуровневый конвейер, который принимает сырые находки сканера и сужает их до небольшого приоритизированного набора с задокументированными доказательствами эксплуатабельности. Сопутствующая публикация — «Configuring your AI vulnerability harness» — будет посвящена steering-файлу, управляющему поведением модели внутри конвейера; первая часть описывает слои вокруг него.

Подробности

Ценность конвейера заключается в логике фильтрации и стандартах доказательств, а не в конкретных инструментах, поэтому свои сканеры и модели можно подставить без изменения архитектуры. Провайдер ИИ, инфраструктурный стек и набор сканеров у каждой команды будут отличаться от использованных в AWS, но архитектурные решения — что фильтровать на каждом слое, что считать доказательством и где переставать доверять модели — переносятся независимо от этого. Под test harness здесь понимается автоматизированный фреймворк, который подаёт в систему контролируемые входные данные и наблюдает, соответствует ли вывод ожидаемому поведению. В применении к обнаружению уязвимостей harness берёт каждую находку-кандидата, строит тест для оценки эксплуатабельности, выполняет его в контролируемой среде и фиксирует доказательства. Harness — это тестовая инфраструктура, а не результаты, которые она выдаёт. Традиционные инструменты статического анализа безопасности приложений (SAST) опираются на сопоставление с шаблонами, а анализ потоков данных варьируется в зависимости от инструмента и языка. Они хорошо находят стоки известной формы, но плохо справляются с многошаговыми цепочками, ошибками бизнес-логики, контекстно-зависимой санитизацией и вопросом, достижим ли сток из контролируемого атакующим ввода. Анализ с поддержкой ИИ закрывает именно этот разрыв в рассуждениях: прослеживает связи между файлами, выводит намерения и учитывает контекст развёртывания. Ключевое концептуальное различие: модель запускается не против всей кодовой базы. Кодовая база — это контекст, передаваемый модели вместе с конкретным промптом. Модель получает код и применяет рассуждения о том, как перемещаются данные, где проходят границы доверия и присутствуют ли паттерны, значимые для безопасности. Определение границ контекста — одна из самых сложных частей архитектуры: слишком большой объём контекста перегружает окно рассуждений модели, а слишком маленький приводит к пробелам в анализе и ложным отрицаниям. Для простой функции AWS Lambda релевантным контекстом может быть один файл плюс его роль AWS Identity and Access Management (IAM). Для сложного микросервиса с общими библиотеками и многоуровневой инфраструктурой решение о том, что включать, требует понимания графа зависимостей приложения.

Что делать

Практические выводы для команд, которые строят подобный конвейер: — проектируйте архитектуру вокруг логики фильтрации и стандартов доказательств, а не вокруг конкретного сканера или модели — так инструменты можно будет заменять; — определите для каждого слоя, что именно фильтруется, что считается доказательством эксплуатабельности и на каком этапе доверие к модели прекращается; — тщательно подходите к определению границ контекста: для простых компонентов достаточно одного файла и его IAM-роли, для сложных микросервисов потребуется анализ графа зависимостей; — сочетайте SAST-инструменты с ИИ-анализом: первые хорошо выявляют стоки известной формы, второй закрывает разрыв в многошаговых цепочках, бизнес-логике и достижимости из контролируемого ввода. Итог: вместо погони за инструментами AWS предлагает переносимую архитектуру, в которой ИИ применяется точечно — как инструмент рассуждений поверх ограниченного контекста, а не как универсальный анализатор всей кодовой базы. Такой подход позволяет сократить поток ложных срабатываний и быстрее доводить реально эксплуатируемые находки до инженеров.

Источник: AWS Security Blog