18 мая 2026 года Dark Reading выпустил колонку с простым и неприятным тезисом: скучная рутина в безопасности больше не защищает сама по себе. Пока команды массово ускоряют разработку с помощью ИИ-кода, ИИ-агенты учатся делать то, на что раньше у атакующих уходили дни: находить неприметные уязвимости, связывать их между собой и доводить цепочку до реального ущерба.
По данным Dark Reading, проблема не в том, что генеративные инструменты пишут заведомо плохой код на каждом шагу. Риск смещается в слой внедрения: неверные допущения о валидации API, повторяющиеся ошибки в настройке прав, одинаковые небезопасные паттерны, которые начинают размножаться по системе с той же скоростью, с какой команда выкатывает новые функции. Если раньше баг нужно было еще обнаружить, понять контекст и увязать с доступами, то теперь этот путь сокращается. Для русскоязычной IT-аудитории здесь плохая новость предельно прикладная: быстрый релизный цикл без пересмотра AppSec-процессов превращает технический долг в открытую поверхность атаки.
Автор колонки, основатель и CEO aisy Шломи Либеров, формулирует конфликт довольно жестко. С одной стороны, компании подталкивают разработчиков к обязательному использованию AI coding tools. С другой, рынок уже обсуждает сценарий, в котором автономные ИИ-агенты системно эксплуатируют даже не самые яркие дыры, а скучные и забытые места инфраструктуры. Не флагманский продукт на главной витрине, а внутренний сервис, который никто не любит трогать. Не экзотический zero-day, а давно известная слабость в зависимостях, конфигурации или маршруте доверия. Именно поэтому focus keyphrase здесь не про хайп, а про операционную реальность: ИИ-агенты меняют стоимость и скорость атаки.
Самый важный сдвиг, который описывает Dark Reading, касается исчезновения защиты через неочевидность. Долгое время у компаний была негласная ставка на то, что часть слабых мест останется вне прицела просто потому, что до них долго и скучно добираться. Нужно разбирать стороннюю экосистему, искать, какой SaaS-провайдер обслуживает комплаенс в конкретном регионе, выяснять, у какого внутреннего инструмента есть доступ на чтение в проде, поднимать шесть уровней зависимостей ради одной библиотеки. Это была не стратегия, а скорее случайная страховка на человеческой лени и ограниченности ресурсов злоумышленника. Либеров считает, что с агентными системами эта страховка сгорает. Машине не скучно. Она не устает, не теряет нить, не забывает про третьестепенный вендор и спокойно проходит по всей цепочке доверия до точки, где из маленькой ошибки получается большой инцидент.
Отсюда неприятный вывод для бизнеса: привычная модель приоритизации уязвимостей начинает ломаться. Если раньше можно было сосредоточиться на нескольких самых заметных приложениях и жить с мыслью, что старые интеграции и вендорский зоопарк как-нибудь переживут квартал, то теперь этот подход выглядит слишком дорогим. ИИ-агенты не обязаны бить в лоб. Они могут собрать маршрут через непрестижные активы, на которые никто не смотрит, но которые лежат на более привилегированном пути. В такой логике «критичность» уязвимости в отрыве от контекста становится почти бесполезной метрикой. Условно говоря, баг средней тяжести в тихом внутреннем сервисе может оказаться опаснее, чем громкая проблема в публичном приложении, если через него проще дотянуться до чувствительных данных или административных прав.
Для security-команд это значит еще и лавину отчетов, в которой старые методы triage начинают буксовать. Либеров прямо пишет: к инженерам нельзя приходить с каждой найденной уязвимостью и объявлять ее срочной. Если срочно все, значит срочно ничего. Доверие к AppSec у продуктовых и платформенных команд в таком режиме заканчивается быстро. Поэтому он предлагает не размахивать списками CVE, а начинать с другого вопроса: что именно для компании критично с точки зрения реального бизнес-ущерба? Доступ к PII, путь к привилегированным системам, чувствительные данные в облаке, уязвимые доверительные связи между сервисами. Уже после этого имеет смысл искать не просто отдельные дыры, а повторяющиеся паттерны, которые ведут к этим рискам.
Практическая часть в колонке тоже есть, и она звучит куда полезнее привычных мантр про «усилить кибергигиену». Во-первых, организациям нужно лучше видеть транзитивные зависимости, потоки данных, права доступа и повторяющиеся архитектурные шаблоны. Если команда не может быстро ответить, почему один и тот же класс ошибки всплывает снова и снова, у нее не просто backlog, а дефицит контекста. Во-вторых, патчить стоит не самые громкие активы, а корневые причины на маршрутах доверия. В-третьих, найденные шаблоны проблем нужно возвращать обратно в инструменты разработки, чтобы ИИ-код не воспроизводил вчерашние ошибки с новой скоростью. Иначе компания получит идеальный конвейер: модель помогает писать больше кода, а другая модель помогает быстрее находить в нем одинаковые дефекты.
У этого сюжета есть и более широкий отраслевой смысл. Несколько лет рынок безопасности жил в логике автоматизации рутины: меньше ручного разбора, больше подсказок, больше сканеров, больше playbook-ов. Теперь автоматизация меняет сам профиль угрозы. Когда ИИ-агенты у атакующей стороны умеют терпеливо ходить по скучным, грязным и давно забытым участкам инфраструктуры, ценность получает не самый красивый дашборд, а способность связать код, доступы, зависимости и бизнес-контекст в одну модель риска. Вопрос уже не в том, появится ли еще больше AI-generated code. Он появится. Вопрос в том, успеют ли защитники перестроить приоритизацию до того, как скучные уязвимости станут самым дешевым входом в серьезный инцидент.