Журнал "Information Security/ Информационная безопасность" #3, 2026

Владимир Михайлов, "Смартап" Стоит разделять ИИ-агентов на внеш- них и внутренних. Внешний агент – это, по сути, злоумышленник, который может с молниеносной скоростью проэксплуа- тировать свежую уязвимость на пери- метре или внутри инфраструктуры. И здесь VM-система просто обязана обнаружить уязвимость как можно быстрее, скорость становится важней- шим фактором. Внутренний агент – это новый класс актива со своими возмож- ностями, зоной ответственности и поверхностью атаки, который также может сам стать источником угрозы. Для таких активов мы разрабатываем новые уникальные методы мониторинга и контроля. Роман Душков, Security Vision Я бы рассматривал ИИ-агента как отдельный составной актив. Это не только приложение или учетная запись, а модель, сервис, инструменты и дан- ные. Для VM важно понимать, где агент работает, к чему имеет доступ, кто за него отвечает и какие действия он выполняет. Вероятно, со временем для таких объектов появится отдельная категория. Виктория Шишкина, Positive Technologies Для компаний ИИ-агенты уже стали мощным инструментом, который уско- ряет достижение бизнес-целей. Про- цесс Vulnerability Management здесь не является исключением. Однако подключая в свою инфраструктуру такие решения, не стоит забывать о безопасности и необходимости регу- лярного аудита. Недавнее исследова- ние начала 2026 г. выявило в популяр- ной ИИ-платформе OpenClaw 341 вре- доносный навык и критическую RCE- уязвимость. Поэтому внедрение ИИ- инструментов для любых целей тре- бует применения тех же строгих пра- вил эксплуатации и контроля, что и для любых других обычных ИТ-акти- вов. Алексей Кузнецов, CICADA8 ИИ-агенты интересны не как новый тип актива, а как средство автоматиза- ции самого процесса VM. Очевидно, ИИ-агенты расширят функциональность с точки зрения нахождения уязвимостей, обогащения информации об уязвимо- стях, триажа уязвимостей, аналитики над уязвимостями (приоритизация, груп- пировка). ИИ-агенты будут также осу- ществлять проверку исправления (частичную). При этом с точки зрения аналитики это открывает возможность увеличить функциональность платфор- мы вплоть до построения и прохождения векторов атак и приоритизации патч- менеджемента. Александр Дорофеев, "Эшелон Технологии" 1. Общее количество уязвимостей, обнаруженное в контролируемой инфра- структуре. В современных реалиях оно всегда будет большим, но только реаль- но эксплуатируемые уязвимости кри- тичных активов требуют внимания. 2. Процент уязвимостей с уровнем опасности "высокий" и "критический" по CVSS. Уровни опасности не учитывают такие серьезные факторы, как наличие эксплойтов, наличие компенсирующих мер или размещение актива на пери- метре. 3. Процент закрытия уязвимостей. Данная метрика может улучшаться за счет устранения уязвимостей, которые проще исправить, пока реально опасные проблемы остаются. Алексей Кузнецов, CICADA8 1. Количество найденных уязвимостей. 2. Количество исправленных уязви- мостей. 3. Количество проверок на уязвимости (количество сканирований). Роман Душков, Security Vision Я бы с осторожностью относился к общему числу уязвимостей, доле закры- тых заявок и количеству критических CVSS. Первая цифра часто растет после улучшения охвата сканирования, вторая может отражать закрытие тикета, а не устранение, третья ничего не говорит без контекста актива. Гораздо полезнее видеть, какие реальные точки входа остались и сколько времени уходит на устранение действительно опасных про- блем. Виктория Шишкина, Positive Technologies Любые показатели, которые дают интегральную оценку без трендов и понимания крайних случаев: 1. Количество закрытых уязвимостей в инфраструктуре: можно исправить тысячи уязвимостей с низким уровнем опасности, оставив на периметре трен- довую уязвимость, ведущую к взлому. 2. Усредненный MTTR: быстрое закры- тие простых недостатков улучшает сред- ний график, маскируя критические бреши. 3. CVSS как метрика опасности уязви- мости: фокус на технической оценке багов без учета бизнес-значимости акти- ва заставляет тратить ресурсы впустую. Дмитрий Черняков, "АЛТЭКС-СОФТ" 1. Ни один сканер не покрывает все ПО в мире, а значит я бы перепроверил перечень детектирования в ПО и уста- новленный набор по факту – наверняка что-то останется за кадром исследования сканера. 2. Учетные записи не вечны – посто- янно проверяйте, что они имеют доступ к активам, в RedCheck это отдельная задача и показатель. 3. Политики устранения неидеальны, срок жизни уязвимости в допусках SLA может сыграть злую шутку с недо- оцененной проблемой – нужно обра- щать внимание на подробности уязви- мостей. Назовите топ-3 метрик VM, которые чаще всего вво- дят в заблуждение относи- тельно реального уровня защищенности. • 33 УПРАВЛЕНИЕ УЯЗВИМОСТЯМИ www.itsec.ru Реклама