Уязвимости в коде теперь находят не неделями, а часами, но чинят их по старому календарю: через очереди, согласования и выгорание мейнтейнеров. На этом фоне управление уязвимостями перестает быть рутинной функцией AppSec и становится узким местом для разработчиков, вендоров и компаний, которые завязаны на open source.
Именно об этом 24 августа 2026 года написал Christopher Robinson, главный архитектор безопасности OpenSSF: как пишет Dark Reading, AI-модели уже научились выдавать качественные отчеты о багах и уязвимостях с темпом, который отрасль физически не успевает переварить. Проблема не в том, что находок стало мало или много сама по себе. Проблема в том, что старое бутылочное горлышко никуда не делось: патчинг, проверка отчета, координация disclosure и выпуск релиза все еще занимают недели и месяцы.
Раньше серьезную дыру в популярной open source-библиотеке мог неделями копать опытный ресерчер. Теперь, по оценке автора, этот цикл схлопнулся до часов. В статье прямо сказано, что с осени прошлого года сообщество наблюдает, как инструменты на frontier-моделях и сильных open-weight-моделях массово выдают вполне добротные находки. Для индустрии это одновременно хорошая и неприятная новость. Хорошая, потому что дефекты обнаруживаются раньше. Неприятная, потому что устранение дефектов не ускорилось сопоставимо. Если раньше поток репортов еще можно было разбирать вручную, то теперь есть риск получить не помощь, а DDoS из хорошо оформленных находок.
Цифры, на которые ссылается Robinson, только усиливают эффект. В отчете IBM Cost of a Data Breach 2026 сказано, что каждая четвертая вредоносная утечка в прошлом году была AI-enabled, а это на 56% больше, чем годом ранее. Средняя стоимость такого инцидента составила $6 млн, примерно на $1 млн выше общего среднего уровня утечки. При этом только 18% организаций используют AI-агенты в управлении уязвимостями, хотя в threat detection их внедрили уже более половины компаний. Иначе говоря, атакующая сторона уже ездит на автомате, а защитная все еще заводит двигатель вручную.
Отсюда главный вывод для разработки и безопасности: управление уязвимостями больше нельзя вести в режиме «каждый новый CVE как пожар». Когда AI начинает производить отчеты тысячами строк, triage превращается в самостоятельную инженерную дисциплину. Нужны заранее согласованные критерии приоритизации, понятные правила оценки эксплуатируемости и формат репорта, который помогает мейнтейнеру, а не добивает его. Иначе даже добросовестные исследователи будут просто увеличивать шум. В статье отдельно отмечено, что сейчас несколько организаций могут параллельно сканировать одну и ту же малоизвестную библиотеку, а затем независимо засыпать мейнтейнера дубликатами. Для проекта, который поддерживают вечерами после основной работы, это не зрелый процесс раскрытия, а наказание.
Рынок уже пытается закрыть этот разрыв точечными инициативами. Robinson упоминает provenance guard у Valkey, инструмент Buttercup от Trail of Bits, который показывали после победы команды в AIxCC и демонстраций на DEF CON 2025, а также Project Akrites, нацеленный на верификацию находок, передачу контекста мейнтейнерам и синхронизацию disclosure. Но общий диагноз от этого не меняется: ускорение поиска уязвимостей само по себе не решает проблему, если инфраструктура исправления осталась на скорости 2020-х. Поддержка мейнтейнеров, secure-by-design-практики и нормальная координация между исследователями, фондами и вендорами здесь выглядят не как nice to have, а как базовая санитария.
Для бизнеса к этому добавляется еще и регуляторный таймер. Robinson напрямую привязывает ситуацию к EU Cyber Resilience Act. Регламент вступил в силу 10 декабря 2024 года, а обязательства по отчетности начинают применяться с 11 сентября 2026 года. Основные требования заработают с 11 декабря 2027 года, но расслабляться никто уже не может: если компания продает цифровой продукт на рынке ЕС, ей придется укладываться в жесткие процедуры работы с уязвимостями и инцидентами. На практике это означает неприятное сочетание: находок становится больше, приходят они быстрее, а дедлайн регулятора не переносится из-за того, что апстрим-проект держится на двух уставших людях и одном контрибьюторе по выходным.
Для русскоязычной IT-аудитории здесь нет экзотики. Почти любая продуктовая команда использует open source-компоненты, а значит, зависит от чужого ритма исправлений. Для CTO и CISO это сигнал пересматривать не только сканеры, но и процесс: как быстро команда валидирует находку, кто общается с апстримом, как устроен intake security-репортов, где лежит SBOM, какие зависимости реально критичны, а какие просто пугают названием. Для разработчиков вывод еще проще: эпоха, когда безопасностью можно было заниматься после релиза и по остаточному принципу, заканчивается не из-за моды на AI, а из-за того, что поток уязвимостей теперь движется с машинной скоростью.
Главный вопрос на ближайшие месяцы даже не в том, сможет ли ИИ находить еще больше багов. Скорее, успеет ли индустрия перестроить управление уязвимостями так, чтобы поток автоматизированных находок не обрушил и без того хрупкую экосистему сопровождения open source. Иначе выигрыш в скорости поиска быстро превратится в новый класс операционного долга. Подробнее об исходной колонке — .