Представьте то вторничное утро, которое всем нам знакомо. Новое уведомление падает во входящие: CWE-22, обход пути (path traversal), и там указана зависимость, которую вы используете в продакшене. Уведомление говорит вам, какого типа баг существует. Но оно не говорит, где именно в репозитории с 300 файлами он находится.
Так начинается налог на триаж: инженер, кофе и два часа работы с grep, прежде чем вообще кто-то сможет начать разговор о том, подвержены ли вы риску. Умножьте это на каждое уведомление, каждый репозиторий, каждый квартал. Это не проблема безопасности, это проблема фонда оплаты труда!
Запомните этот вторник. Эта серия статей призвана решить эту проблему правильно и от начала до конца. Нам понадобится пять постов, каждый из которых отвечает на один вопрос:
- Где мне искать? Этому посвящен данный пост.
- То, что я там нашел, действительно реально? Это Часть 2.
- Как мне убедиться, что никто — ни человек, ни ИИ — больше никогда не напишет этот код? Это Часть 3.
- Действительно ли это предотвращение работает? Это Часть 4, контролируемый эксперимент, поскольку средство защиты, эффективность которого вы не измерили, — это просто надежда.
- Может ли всё это работать как единый цикл? Это Часть 5.
На эти вопросы можно ответить с помощью нескольких весьма интересных проектов компании Cisco, и мне нравится представлять их в виде небольшой труппы: Antares — это звезда, которая показывает, где искать, Foundry — это кузница, доказывающая, что реально, а CodeGuard — это страж, который не дает уязвимости вернуться. Части 4 и 5 подвергают эту труппу испытанию, а затем заставляют работать вместе. Сегодня очередь звезды.
Я потратил несколько недель на запуск Cisco’s Antares-1B на общедоступном бенчмарке полностью на своем ноутбуке, и я хочу показать вам, на что способна модель с одним миллиардом параметров, когда её научили не просто «знать» вещи, а расследовать их. Никакого облачного API. Никакой исходный код не покидает устройство. Никаких счетов за GPU.
Всё, что описано ниже, получено в ходе сохраненных запусков, которые вы можете воспроизвести самостоятельно в моем репозитории Antares. Поехали.
Идея: поиск, который ведет себя как следователь
Большинство демоверсий в стиле «ИИ находит ваши баги» работают в один проход. Вы вставляете код, гигантская модель сопоставляет его с шаблонами, и вы получаете ответ с уровнем уверенности, который никак нельзя проверить.
Antares делает кое-что другое, и именно в этом разница для всего продукта. Cisco взяла IBM’s Granite 4.0 1B за основу и дообучила её (контролируемая точная настройка, затем GRPO) на задачах локализации уязвимостей. То, чему она научилась, — это не каталог CVE. Она усвоила поисковую стратегию: учитывая класс уязвимости и незнакомый репозиторий, какой самый умный следующий вопрос нужно задать?
Этот цикл намеренно прост и рутинен. Модель получает описание CWE и репозиторий в режиме «только чтение» в изолированной среде. Она может выполнять до 15 команд оболочки (это намеренное ограничение), таких как find, rg, grep или sed. Никакой сети, никакой записи, никаких интерпретаторов. Она рассуждает, выполняет команду, читает вывод, снова рассуждает, а затем выдает отсортированный список файлов, которые могут быть уязвимы.
Базовые инструменты. Ценность кроется во всем остальном: когда расширить поиск, когда сузить, когда отказаться от гипотезы.
Посмотрите, как она мыслит
Позвольте мне показать вам один эпизод, чтобы вы увидели её в действии. Это Antares, примененная к репозиторию tokio-rs/slab, которой не дали ничего, кроме общего текста CWE-119 о границах буфера памяти, и которая работала в рамках того же лимита в 15 команд от начала и до конца (полную трассировку вы можете найти в моем репозитории).
Ходы 1–2. Она хочет сориентироваться, поэтому обращается к обычному рабочему процессу оболочки: cd /workspace/repo && ls. Песочница отклоняет &&. Она заменяет его на точку с запятой. Тоже отклонено. Тьфу.
Вот первый интересный момент: она не зацикливается. Она полностью перестраивает план, выполняет find . -maxdepth 2 и получает структуру проекта за один присест. Бюджет потрачен на изучение местности перед охотой.
Ход 4. Теперь она выполняет трансляцию. CWE-119 — это абстрактный текст комитетов по стандартизации о границах буфера. Antares конвертирует его в Rust: unsafe, from_raw, ptr::, copy_nonoverlapping, неидексированные смещения (unchecked offsets). Такое сопоставление общего класса уязвимости с идиомами конкретной экосистемы — это как раз тот объем знаний, за который вы обычно платите старшему инженеру.
Она пробует всё это в одном хитроумном регулярном выражении с альтернативами. Песочница отклоняет и его. Поэтому она отбрасывает составной паттерн и запускает самую простую версию: rg -n "unsafe" src tests. Находки есть, и только в src/lib.rs.
Ходы 7–9. Она проверяет ptr:: и copy_nonoverlapping. Обе команды ничего не возвращают. Более слабая модель в панике расширила бы поиск. Antares трактует тишину как доказательство: риск уже сосредоточен в одном файле, поэтому её следующие шаги удваивают усилия именно там, с помощью grep, а затем rg, ограниченных только src/lib.rs. Те же строки, выше уверенность.
От поиска к чтению
Ход 12. Оставив три команды из своего лимита в 15 команд, она прекращает использовать grep и начинает читать: nl -ba src/lib.rs | sed -n '700,900p', извлекая реальную реализацию вокруг блоков unsafe.
Ход 14. За один шаг до того, как ей пришлось бы остановиться и гадать, она отправляет src/lib.rs. Один файл. Ровно тот файл, которого касался патч безопасности. F1-мера 1.0 за 17.5 секунд.
Отклоненные команды, восстановление, негативные свидетельства, чтение перед ответом. Это не автодополнение кода. Это младший аналитик с хорошей интуицией, и каждый его шаг записан в трассировке, которую человек может проверить.
Честные цифры на 500 репозиториях
Один удачный эпизод может быть просто анекдотом. Поэтому я запустил полный публичный манифест VLoc Bench (бенчмарк локализации уязвимостей): 500 реальных репозиториев, каждый из которых зафиксирован на коммите перед патчем безопасности. Около 9 часов работы на моем Mac.
Давайте проясним ситуацию с этой F1-мерой. Cisco публикует значение 0.209 для тех же весов на том же бенчмарке, обслуживаемых с помощью vLLM на датацентровских графических процессорах и усредненных по трем запускам. Я получил 0.168 за один проход на Apple M1. Та же модель, другой стек. Воспроизведение 80% опубликованного вендором балла на железе, которое помещается в рюкзак, — это, честно говоря, отличный результат для вендора.
И обратите внимание, какая метрика имеет значение для сценария использования. Если ваша задача — «какой файл мне открыть первым?», ваш показатель — hit@any, и каждый третий результат представляет собой короткий список, который окупает себя за считанные минуты.
«Хорошо, но почему бы просто не использовать большую модель?»
Справедливый вопрос, и честный ответ заключается в том, что я не могу решить это со своего ноутбука, потому что запускал только Antares. Но технический отчет Cisco закрывает этот вопрос.
Они пропустили всё поле моделей (передовые закрытые модели, крупные открытые модели, небольшие открытые модели и семейство Antares) через идентичный тестовый стенд: те же инструменты, те же входные данные задач, тот же бюджет на взаимодействие, та же температура, с усреднением по трем запускам для каждой. Вот какое значение F1-меры для файлов получилось на Фазе А:
Вдумайтесь в это на секунду. Модель с одним миллиардом параметров, которая работает на вашем ноутбуке, занимает четвертое место, опережая каждую крупную модель с открытыми весами в исследовании и обгоняя Gemini 3 Pro. А по полноте (recall), то есть доле действительно уязвимых файлов, которые ей удается обнаружить, Antares-1B превосходит всё, включая GPT-5.5 при максимальном уровне рассуждений.
Собственное определение авторов отчета для формы этой таблицы — «обрыв возможностей» (capability cliff): системы либо достигают уровня 0.186–0.229, либо падают ниже 0.152, и количество параметров едва ли предсказывает, на какой стороне вы окажетесь. GPT-5 набирает 0.048. Её собственный меньший собрат GPT-5 Mini набирает в два раза больше. Масштаб модели — это просто не та ось, которая здесь имеет значение.
Стоит упомянуть и нижнюю планку. Cisco также протестировала классические инструменты для этой задачи: лучшая конфигурация Semgrep достигла F1-меры по файлам 0,086, а CodeQL — 0,023, при этом пропустив более 92% репозиториев, так как не смогла собрать извлеченные снимки. Модель с 1 млрд параметров, которая считывает код адаптивно, делает то, что механизмы на основе правил структурно неспособны выполнить.
Разница в стоимости
И показатель стоимости — это кульминация. Весь бенчмарк из 500 задач выполняется примерно за 15 минут на одном H100: менее двух секунд и менее 0,002 доллара на репозиторий, примерно один доллар за весь прогон. Cisco оценивает аналогичную рабочую нагрузку через пограничный API более чем в сто долларов. Та же задача, разница в два порядка, и только один из двух вариантов может работать внутри вашей собственной границы доверия.
Это и есть реальный ответ на вопрос «почему не большая модель?». В этой работе большая модель не лучше. И она дороже. И ей нужен ваш исходный код.
Одно предостережение и одна проверка, которую я провел сам
Эта таблица — собственная оценка Cisco, поэтому относитесь к ней как к бенчмарку вендора, именно поэтому так важно, что тестовый комплекс и веса общедоступны, а цифры воспроизводимы. Мой прогон — лишь небольшая часть этого воспроизведения, и он дал именно те результаты, которые должен был.
Я провел одну проверку исключительно в методологических целях: те же 500 репозиториев против базовой модели Granite, неотрегулированной контрольной точки, с которой начинает Antares. Разумеется, она вообще не справилась, так как никогда не обучалась для этой задачи. Это нечестный бой, и я не утверждаю обратное; Cisco сообщает о таком же близком к нулю результате для нее. Единственной задачей этого исследования было исключить скучное объяснение моих собственных цифр: что VLoc Bench — это просто, и любая компетентная модель на 1B, помещенная в эту песочницу, случайно найдет правильный файл с помощью обычных grep. Этого бы не произошло. Она даже не может замкнуть цикл. Так что 33% получаются благодаря весам, а не вспомогательным механизмам.
Почему это должно волновать бизнес
Ваш исходный код никуда не уходит. Это главный тезис для каждого регулируемого клиента, с которым я общаюсь: финансовые услуги, государственный сектор, оборона, здравоохранение и любые партнеры, которым контракт запрещает отправлять проприетарный код клиента на сторонний API инференса. Antares работает в изолированной среде (air-gapped). Весы находятся на машине, репозиторий находится на машине, анализ происходит на машине. Вопрос о локализации данных закрывается еще до того, как он успевает возникнуть.
Экономика кардинально меняется. Доли цента за репозиторий вместо счета за токены, который растет в зависимости от того, насколько тщательными вы готовы быть. Это меняет подход: вы можете позволить себе запускать это для каждого уведомления против каждого репозитория, а не только для самых опасных. И Cisco подобрала линейку под реальные места обитания кода: 350M для мобильных устройств и IoT, 1B для ноутбуков и рабочих станций, 3B для любого одиночного GPU.
Она показывает ход своей работы. Каждый эпизод создает трассировку рассуждений, а официальный интерфейс командной строки Antares выводит SARIF 2.1.0 (формат, используемый GitHub Code Scanning) плюс флаг --fail-on-findings, который вы можете встроить в свои CI/CD конвейеры. Это встраивается в привычные для клиентов инструменты. Для партнеров это предложение услуг с приложенным журналом аудита, а не черный ящик.
Это сужает область поиска до запуска дорогостоящего шага. Этот шорт-лист, предоставленный Antares, служит фильтром. Направьте детектор потяжелее на базе LLM, более глубокий индексатор или полный проход рассуждений на 30 файлов вместо 300, и весь последующий конвейер станет дешевле и точнее. Запомните это предложение; финал этой серии построен на нем.
Чем это не является
Было бы медвежьей услугой с моей стороны не прояснить это.
Antares выполняет локализацию, а не детектирование. Она отвечает на вопрос «где мне искать?», а не «эксплуатируемо ли это?». Путь в списке — это гипотеза, а не уязвимость, и человек, тест или более глубокий анализ все равно должны ее подтвердить.
Списки содержат много шума. Разница между hit@any (треть репозиториев) и F1 (0,17) — это и есть этот шум: правильный файл часто соседствует с неправильными.
На уже пропатченных деревьях кода она все равно склонна предлагать файлы, а не объявлять код чистым. Она была обучена находить кандидатов, а не подтверждать исправления. Так что никогда не воспринимайте слабый список как знак «мы в безопасности».
И у нее есть рабочие ограничения. Ее точность резко падает, когда репозитории вырастают более чем до нескольких мегабайт, потому что 15 команд просто не могут охватить кодовую базу в 100 МБ. Я сам столкнулся с этой стеной позже в этой серии и покажу вам в точности, где она находится.
Если использовать это как ускоритель триажа, это превосходно. Если использовать как оракул, это вас заблудит.
Cisco заложила этот сценарий сбоя на пропатченном дереве прямо в бенчмарк. Каждый репозиторий оценивается дважды: один раз на уязвимом дереве и один раз на пропатченном, поэтому поведение ложных срабатываний измеряется открыто, а не скрывается. Вендоры, которые нервничают из-за своих цифр, не проектируют оценки таким образом.
Далее: звезде нужна кузница
Итак, у нас есть звезда. Она направляет луч в темноту и говорит «посмотри сюда». Это дешево, это конфиденциально, и в одном случае из трех она указывает на правильный файл.
Но «посмотри сюда» не означает «это реально». Если вы передадите этот шорт-лист прямо разработчику, вы просите его доверяться предчувствию. Если вместо этого вы передадите весь репозиторий большой LLM, вы получите уверенную стену текста, которую невозможно проверить, невозможно воспроизвести на следующей неделе и на которой невозможно построить процесс.
Именно поэтому в моем следующем посте мы перенесем Cisco’s Foundry Security Spec из проектной документации в реальный мир: рабочая реализация, запущенная на некоторых популярных репозиториях и библиотеках реального мира, с каждой найденной уязвимостью, проверенной на уровне байтов на диске. Вот где предчувствия становятся доказательствами. И, конечно же, я покажу вам, как применить это к вашему собственному коду.
Увидимся на следующей неделе!
Все в этом посте воспроизводимо с помощью : сохраненные прогоны по 500 репозиториям, сохраненные трассировки и скрипты анализа. Веса Antares-1B и технический отчет доступны на Hugging Face.
