Эта статья про SAST в IDE: как Veai проверяет Java/Kotlin-проект, показывает путь данных по коду и помогает исправлять найденные уязвимости, а не просто оставляет разработчику длинный список находок.

Речь про статический анализ безопасности кода, недоверенные данные в Java/Kotlin, уязвимости в Spring/JPA/Kotlin coroutines и разбор найденных проблем без отдельного web UI, экспорта отчётов и ручного копирования цепочки вызовов в AI-чат.

Если коротко про релиз 5.11: Veai собирает JVM-проект, запускает анализ безопасности и показывает уязвимости в панели результатов. Конкретную находку можно прикрепить к чату с агентом. Дальше уже не нужно самому собирать контекст по кускам: агент помогает понять, откуда пришли данные, где они используются опасно, как это воспроизвести, как исправить код и что проверить после фикса.

Материал в первую очередь для Java/Kotlin-разработчиков. Но QA и аналитикам он тоже полезен: первым — чтобы понимать, какие сценарии проверять после фикса, вторым — чтобы переводить security-находку в риск, приоритет и критерии приёмки.

Ниже пять практических вопросов, вокруг которых обычно и крутится SAST:

TL;DR

• Veai SAST проверяет JVM-проекты: Java и Kotlin.

• Главный сценарий — SAST в JetBrains IDE: IntelliJ IDEA, OpenIDE, GigaIDE, Android Studio и IDE на JetBrains Platform.

• Запуск — из чата Veai по кнопке со щитом.

• Перед анализом плагин пытается собрать проект через Maven или Gradle.

• Анализ работает локально: код не отправляется на сервер.

• Движок выполняет межпроцедурный анализ: отслеживает, как недоверенные данные проходят через методы и классы, а не только ищет опасные вызовы внутри одной функции.

• Для многих находок доступна цепочка вызовов: кликаете шаг — IDE подсвечивает место в коде.

• Уязвимость можно прикрепить к чату: AI-агент объяснит находку, предложит фикс, поможет оценить критичность и проверить, не ложное ли это срабатывание.

Проблема: Поиск уязвимостей часто заканчивается не фиксом, а разбором находок

Сценарий знакомый.

Запускаете SAST на большом Spring-проекте. Инструмент находит SQL injection, XSS, SSRF, небезопасную десериализацию, странные места с путями к файлам. Часть находок выглядит страшно. Часть выглядит так, будто анализатор просто не понял проект.

И дальше начинается не исправление, а расследование:

1. открыть файл;

2. найти контроллер;

3. понять, откуда пришли данные;

4. пройти через сервисы и репозитории;

5. проверить, очищаются ли или валидируются данные;

6. понять, доступен ли обработчик запроса реальному пользователю;

7. решить, блокирует ли это релиз.

Сам по себе факт обнаружения ещё мало что даёт. Дорогая часть начинается дальше: понять, что реально эксплуатируется, что является ложным срабатыванием, что блокирует релиз, а что можно спокойно отложить.

Veai как раз пытается сократить этот участок: от найденной уязвимости до понятного действия. Исправить код. Добавить тест. Оценить критичность. Или закрыть находку как ложное срабатывание, но с нормальным обоснованием, а не "кажется, не страшно".

Что появилось в Veai

В чате Veai есть кнопка со щитом. Нажимаете её, и плагин делает примерно то, что разработчик обычно собирает вручную из нескольких инструментов:

1. пытается собрать проект через Maven или Gradle;

2. строит модель проекта;

3. запускает собственный движок статического анализа;

4. показывает результаты в панели IDE;

5. даёт открыть цепочку вызовов и перейти к конкретным местам в коде;

6. позволяет прикрепить находку к чату.

Для каждой уязвимости доступны действия:

Результаты можно группировать:

Почему перед SAST нужна сборка

Veai SAST работает не просто по тексту исходников. Он использует всю полноту модели проекта: классы, сигнатуры, типы, зависимости, связи между методами.

Поэтому перед анализом плагин пытается собрать проект.

Без сборки анализатор быстро скатывается к эвристикам уровня "нашёл опасный метод рядом с подозрительной строкой". На маленьком примере иногда прокатывает. В enterprise Java/Kotlin — редко.

Spring DI, JPA, proxy, generic-типы, Kotlin suspend, Deferred, extension-функции — всё это плохо восстанавливается простым grep.

Коротко:

Для SAST это неприятный, но полезный компромисс. Да, зависимость от сборки может раздражать. Но без неё сложные цепочки вызовов в JVM-проектах становятся намного менее надёжными.

Входные данные, опасное использование и цепочка вызовов

В security-инструментах для этого есть свои термины, но разработчику обычно важнее более приземлённые вопросы: где значение вошло в программу, куда оно дошло и почему это опасно.

Хороший SAST не должен просто писать "вот строка с SQL injection". Разработчику нужна дорога до этой строки: через какой контроллер пришло значение, в какой сервис ушло, где попало в репозиторий. Для SQL injection, XSS, SSRF, path traversal и похожих проблем уязвимость почти всегда живёт не в одной строке, а на пути от внешнего ввода к опасной операции.

Пример:

@RestController
class ReportController {
    private final ReportService reportService;

    @GetMapping("/reports")
    List<Report> reports(@RequestParam String sort) {
        return reportService.findReports(sort);
    }
}

@Service
class ReportService {
    private final ReportRepository repository;

    List<Report> findReports(String sort) {
        return repository.findReports(sort);
    }
}

@Repository
class ReportRepository {
    List<Report> findReports(String sort) {
        String sql = "select * from reports order by " + sort;
        return jdbcTemplate.query(sql, rowMapper);
    }
}

В контроллере нет SQL. В репозитории нет HttpServletRequest. Если анализатор смотрит только одну функцию, он увидит либо входные данные без опасного использования, либо опасный SQL-вызов без понимания, что туда пришло от пользователя.

Межпроцедурный анализ связывает эти куски.

Условная цепочка для SQL injection:

Та же модель работает для других типов находок:

В панели Veai можно кликать по шагам цепочки и переходить в соответствующее место в редакторе.

Как выглядит рабочий процесс

Минимальный сценарий:

Пример фикса: SQL injection в сортировке

Вернёмся к примеру с ORDER BY.

Уязвимый код:

@Repository
class ReportRepository {
    List<Report> findReports(String sort) {
        String sql = "select * from reports order by " + sort;
        return jdbcTemplate.query(sql, rowMapper);
    }
}

Интуитивная реакция — заменить конкатенацию на bind-параметр. Но с именем колонки это не всегда работает: bind-параметры подставляют значения, а не SQL-синтаксис.

Поэтому здесь безопаснее сделать список разрешённых полей:

@Repository
class ReportRepository {
    private static final String DEFAULT_SORT_COLUMN = "created_at";

    private static final Map<String, String> ALLOWED_SORT_COLUMNS = Map.of(
        "createdAt", "created_at",
        "name", "name",
        "status", "status"
    );

    List<Report> findReports(String sort) {
        String sortColumn = ALLOWED_SORT_COLUMNS.getOrDefault(sort, DEFAULT_SORT_COLUMN);
        String sql = "select * from reports order by " + sortColumn;
        return jdbcTemplate.query(sql, rowMapper);
    }
}

Пользователь всё ещё выбирает сортировку, но в SQL попадает уже не произвольная строка из запроса, а значение, которое контролирует приложение.

Если нужно направление сортировки:

private static final String DEFAULT_SORT_DIRECTION = "asc";
private static final Set<String> ALLOWED_SORT_DIRECTIONS = Set.of("asc", "desc");

private static String resolveSortDirection(String direction) {
    if (direction == null) {
        return DEFAULT_SORT_DIRECTION;
    }

    String normalizedDirection = direction.toLowerCase(Locale.ROOT);
    return ALLOWED_SORT_DIRECTIONS.contains(normalizedDirection)
        ? normalizedDirection
        : DEFAULT_SORT_DIRECTION;
}

Что должен проверить QA после фикса:

Сохранённая инъекция: когда данные возвращаются позже

Самые неприятные уязвимости часто не выглядят как "взяли параметр и сразу использовали его опасно".

С сохранённой инъекцией всё менее прямолинейно:

1. один обработчик принимает данные пользователя;

2. сервис сохраняет их через JPA;

3. через время другой обработчик читает эти данные;

4. значение попадает в шаблон, JSON, WebView или другое опасное место использования.

Пример с комментариями:

Если анализатор не понимает persistence layer, он легко потеряет связь между записью и чтением.

Veai SAST отслеживает недоверенные данные через JPA save/find, сервисы, внедрённые через DI, и поля сущностей. Это важно для больших систем, где запись и чтение часто живут в разных модулях и у разных владельцев.

Kotlin coroutines: путь данных не должен теряться на await

В Kotlin значение может проходить через suspend, async, await, Deferred, launch, runBlocking.

Пример:

@GetMapping("/profile")
suspend fun profile(@RequestParam id: String): ProfileDto {
    val profile = async { profileService.load(id) }
    return renderer.render(profile.await())
}

Если анализатор плохо понимает корутины, цепочка вызовов может оборваться на async или await. В исходниках всё выглядит нормально, но для статического анализа это уже не прямой вызов.

Veai SAST отслеживает недоверенные данные через основные coroutine-конструкции. Для Android это тоже важно: входом может быть не HTTP-запрос, а deep link, Intent extra, clipboard или данные из внешнего storage. Если такое значение попадает в WebView, файловый путь или сетевой клиент, это уже не "просто данные из приложения", а security-сценарий.

Где помогает AI-агент при разборе уязвимости

SAST-движок находит подозрительные места и строит цепочку вызовов. Агенту не нужно угадывать уязвимость с нуля. Его работа начинается дальше: объяснить путь данных, сократить ручной разбор, предложить минимальный патч и подсказать проверки.

Важно: AI для исправления уязвимостей не должен выглядеть как магическая кнопка "починить безопасность". Агент не заменяет инженера и AppSec. Он ускоряет скучный участок: собрать факты, пройтись по коду, предложить патч, сформулировать проверку и явно показать предположения.

Оценка критичности

Для формальной оценки часто используют CVSS — шкалу критичности уязвимости от 0 до 10. Ноль — практического влияния нет. Десять — потенциально критический ущерб.

В Veai уязвимость можно прикрепить к чату и попросить агента оценить её критичность. Агент проходит по факторам, показывает предположения и объясняет итог.

Пример для SSRF:

Хорошая оценка критичности выглядит не как "это 9.8, потому что страшно". Она выглядит как список предположений, которые можно проверить.

Что получает разработчик, QA и аналитик

Пример критериев приёмки для SSRF:

• backend принимает только домены из списка разрешённых;

• private IP, localhost и link-local адреса отклоняются;

• пользователь получает предсказуемую ошибку без внутренних деталей;

• событие логируется без токенов и полного стека вызовов;

• старые валидные сценарии продолжают работать.

Глубокая поддержка JVM-фреймворков

Veai SAST сейчас не пытается покрыть десятки языков. Фокус уже: JVM и глубокая поддержка Java/Kotlin-стека.

Ниже — сравнение по сценариям, которые важны именно для JVM-проектов. Поддержка у конкурентов зависит от версии, правил и конфигурации анализа, поэтому таблицу стоит читать как ориентир, а не как исчерпывающий benchmark.

Смысл не в красивой таблице. Смысл в классах проблем, которые легко потерять, если анализатор не понимает фреймворк.

Языки и расширяемость

Новые типы уязвимостей добавляются вместе с обновлениями плагина. Правила поставляются с Veai.

Собственные правила сейчас добавить нельзя. В будущем хочется прийти к сценарию, где агент помогает дописывать правила под проект, но это не должно превращаться в "LLM написала regex". Правило должно быть проверяемым, воспроизводимым и достаточно точным. Иначе команда просто получит новый источник ложных срабатываний.

Что работает оффлайн

Сам SAST-анализ работает локально. Кодовая база не отправляется на сервер, подключение к серверам для анализа не требуется.

Это важно для enterprise-команд: в репозитории могут быть закрытые алгоритмы, персональные данные, коммерческая логика, интеграционные ключи в тестовых конфигах.

Отдельный слой — чат с агентом. Если вы прикрепляете уязвимость к диалогу и просите объяснить или исправить её, включается LLM. Это уже надо оценивать по политике вашей компании.

Коротко:

Чек-лист перед релизом

Если времени мало, можно идти так:

Антипаттерны

Ответы на вопросы

Это замена AppSec?

Нет. Это инструмент для разработчиков и командного разбора находок. AppSec всё равно нужен для политики безопасности, моделирования угроз, сложных случаев и финальных решений по риску.

Можно ли запускать анализ без интернета?

Да, сам SAST-анализ работает локально. Интернет нужен только для взаимодействия с LLM, если вы обсуждаете находку с агентом.

Почему только Java и Kotlin?

Потому что текущая ставка — глубина JVM-анализа, а не максимальное число языков в таблице. Поддержка Python, Go, C#, JavaScript и TypeScript в планах.

Что делать, если проект не собирается?

Сначала чинить сборку или хотя бы ту часть, от которой зависит анализ. Для Veai SAST сборка — источник фактов о проекте, а не декоративный шаг.

Можно ли использовать QA и аналитикам?

Да. QA может превращать цепочку вызовов в сценарии проверки и регрессионные тесты. Аналитик — в описание риска, критерии приёмки и релизное решение.

Чем это отличается от "спросить AI-чат про уязвимости"?

Обычный чат пытается угадать по фрагментам. Здесь сначала работает статический анализатор, затем IDE даёт факты о проекте, и только потом агент помогает с объяснением и фиксом.

Итог

SAST полезен не в момент, когда он нашёл тысячу уязвимостей. Он полезен, когда команда быстро понимает: это реальная проблема, вот путь данных, вот риск, вот фикс, вот проверка.

Veai переносит этот цикл в JetBrains IDE. Сборка, анализ, цепочка вызовов, чат с агентом, исправление и проверка остаются в одном рабочем контуре.

Ограничения есть: сейчас это Java/Kotlin, нужна сборка, ложные срабатывания не исчезают полностью, кастомных правил пока нет. Но для JVM-команд, которые живут в IntelliJ IDEA или Android Studio, подход выглядит практично: меньше ручного разбора, больше проверяемых действий.

Если хотите попробовать: установите Veai, откройте JVM-проект, нажмите щит в заголовке чата и начните с high/critical находок. Самое интересное начинается не в списке уязвимостей, а в цепочке вызовов.

SEO-блок для публикации

Этот блок нужен для подготовки публикации, а не как обязательная часть статьи. Перед отправкой на Хабр его можно оставить внизу или перенести в редакционный бриф.

SEO title

SAST прямо в IDE: как Veai ищет уязвимости в Java/Kotlin-проекте

Альтернативные заголовки

1. SAST прямо в IDE: как Veai ищет уязвимости в Java/Kotlin-проекте

2. Как Veai отслеживает путь данных в Java/Kotlin и находит уязвимости

3. От SAST-находки до фикса: как Veai разбирает уязвимости в чате IDE

4. Почему SAST для Java/Kotlin должен понимать проект, сборку и JetBrains IDE

5. AI-агент для security review: как Veai помогает чинить уязвимости без ручного разбора

Meta description

Veai запускает SAST-анализ Java/Kotlin-проекта из JetBrains IDE, показывает путь данных от внешнего ввода до опасного использования и помогает разбирать ложные срабатывания, оценку критичности и исправления SQL injection, XSS, SSRF и других security-находок через AI-агента.

Короткий лид для превью

Разбираем, как Veai проверяет безопасность JVM-проекта прямо в JetBrains IDE: сборка, статический анализ, путь данных по коду, оценка критичности, ложные срабатывания, фиксы через агента и сценарии проверки для QA.

Основные ключевые фразы из аналитики

1. SAST в IDE, статический анализ безопасности в IDE, как проверять безопасность кода в IntelliJ IDEA.

2. анализ потока данных Java, межпроцедурный анализ Java, как SAST отслеживает путь данных.

3. SAST Java Kotlin, поиск уязвимостей в Java проекте, статический анализ Spring Boot безопасность.

4. разбор SAST находок, как исправлять уязвимости после SAST, ложные срабатывания SAST что делать.

5. AI для исправления уязвимостей, ИИ-агент для security review, AI coding agent SAST.

Вторичные ключевые фразы

• статический анализ кода Java;

• поиск уязвимостей в коде;

• SAST в JetBrains IDE;

• проверка безопасности Java проекта;

• проверка безопасности Kotlin проекта;

• Veai SAST;

• анализ потока данных Java;

• SQL injection Java;

• XSS SSRF SAST;

• безопасность Spring Boot;

• статический анализ JVM проекта;

• поиск уязвимостей в IntelliJ IDEA;

• межпроцедурный анализ;

• путь данных по коду;

• оценка критичности уязвимости;

• разбор security-находок;

• Kotlin coroutines security;

• Spring DI SAST;

• JPA stored injection;

• Android Studio Kotlin security.

Рекомендуемые хабы Хабра

• Информационная безопасность;

• Java;

• Kotlin;

• Программирование;

• Текстовые редакторы и IDE;

• Машинное обучение.

Рекомендуемые теги

SAST, Java, Kotlin, JetBrains, IntelliJ IDEA, Android Studio, Spring, JPA, SQL injection, XSS, SSRF, оценка критичности, AI-агенты, Veai, статический анализ, безопасность кода.

GEO / AI-search формулировки

Для попадания в AI-ответы и пересказы статья должна явно отвечать на такие вопросы:

Внутренние ссылки, которые стоит добавить при публикации

• страница установки Veai;

• документация по SAST / security scan, если есть отдельная страница;

• предыдущая статья Veai про настройку AI-агента под проект;

• материал про AGENTS.md / rules / skills, если нужен контекст про работу агента в IDE;

• страница с описанием поддержки Java/Kotlin и JetBrains IDE.

Риск переспама

Низкий. Ключевые фразы распределены естественно: SAST, Java/Kotlin, JetBrains IDE, статический анализ, уязвимости, путь данных по коду. Не стоит дополнительно повторять "поиск уязвимостей" в каждом подзаголовке.

Устанавливайте Veai 5.11 бесплатно в JetBrains IDE. А если в работе вам не хватает каких-то возможностей или сценариев, пишите нам в чат или на support@veai.ru. Такие сообщения напрямую влияют на план следующих обновлений.

Для всех, кому интересно следить за продуктом, новостями из мира AI и техниками использования AI в разработке, оставляем ссылку на наш телеграм-канал.