Cisco представила семейство небольших языковых моделей Antares для поиска уязвимостей в исходниках. Ключевая идея — прогонять анализ локально и ускорять разбор инцидентов там, где отправлять код во внешние сервисы нельзя или слишком рискованно.
Cisco анонсировала семейство небольших языковых моделей Antares, которые ориентированы на практичную задачу — помогать находить известные классы уязвимостей в исходном коде без дорогих вычислений и без необходимости загружать репозиторий в облачные «универсальные» помощники.
Что именно запустили
Линейка Antares включает три модели: Antares-350M, Antares-1B и Antares-3B. Две младшие доступны на Hugging Face, а значит, их можно развернуть у себя — от рабочей станции до изолированного контура компании. Это важно для команд, которые работают с закрытым кодом или подпадают под требования комплаенса.
Почему маленький размер здесь — не недостаток
Вокруг LLM уже сформировался стереотип: «чем больше, тем лучше». Но в прикладной безопасности часто важнее не “красивый ответ”, а стабильный и воспроизводимый процесс. Небольшие модели дешевле в эксплуатации и проще вписываются в регулярные проверки — например, при каждом pull request или ночном прогоне в CI.
В материалах Cisco сравнивает результаты Antares с рядом известных моделей и подчёркивает, что цель — не заменить разработчика или полноценный аудит, а сделать первичную проверку уязвимостей доступной там, где раньше это было слишком дорого по времени и инфраструктуре.
Как Antares ищет проблемы в репозитории
Ключевой подход Antares — итеративный поиск, который имитирует работу исследователя в кодовой базе:
- модель стартует с описания уязвимости и пытается найти характерные шаблоны;
- выбирает файлы-кандидаты и читает их фрагменты;
- если “след” ложный, меняет направление и сужает область поиска.
Такой сценарий хорошо ложится на реальную жизнь: в больших репозиториях проблема редко «лежит на поверхности», и даже опытный инженер сначала ищет, куда смотреть.
Где это может пригодиться на практике
В описании Antares упоминаются несколько понятных сценариев, в которых такие модели могут дать быстрый эффект:
- поиск файлов, связанных с категориями CWE (когда нужно отработать известный класс проблем и понять, есть ли он в проекте);
- триаж инцидентов — расстановка приоритетов, что проверять в первую очередь, если есть подозрение на уязвимость;
- усиление статического анализа за счёт «осмысленного» просмотра структуры репозитория;
- ускорение CI/CD: когда система подсвечивает потенциально рискованные файлы, чтобы ревьюер не искал их вручную.
Пример из жизни: если команда получила уведомление о новой уязвимости в популярном классе ошибок (например, небезопасная десериализация или некорректная проверка прав), можно быстро прогнать локальный анализ по своим сервисам и получить список мест, которые стоит перепроверить в первую очередь.
Важная оговорка: это не «автопочинка» и не гарантия безопасности
Даже самые сильные модели могут ошибаться: пропускать реальные проблемы или, наоборот, генерировать ложные срабатывания. Поэтому разумный вариант использования — встраивать Antares в процесс как инструмент подсказок:
- поднять вероятность того, что критичное место попадёт в поле зрения;
- сократить время на первичный поиск по репозиторию;
- систематизировать разбор типовых классов уязвимостей.
Если у компании уже есть SAST/DAST и ручные ревью, подобные модели могут сыграть роль «ускорителя» и помощника в сортировке, но не должны заменять контроль качества и безопасность как дисциплину.
Источник: Habr
