🧠 Al-инструмент для углублённого анализа кода
Сегодня рассмотрим весьма интересный проект OSINT для AppSec: Metis от ARM, семантический ИИ-инструмент, который читает код, как человек, и анализирует его, как машина.
🔎 Что такое Metis?
Metis - это AI-фреймворк для глубокого анализа безопасности исходного кода, который использует большие языковые модели (LLM) и RAG-архитектуру.
💡 Назван в честь богини мудрости Метис. Заявляется, что инструмент «понимает» код.
🚀 Ключевые особенности
🧬 Семантическое понимание кода
- Не ищет шаблоны или регулярки, а анализирует смысл, архитектуру и контекст.
- Выявляет логические и концептуальные уязвимости, которые статические анализаторы часто пропускают.
🧩Контекстно-чувствительный анализ
Metis строит собственную векторную базу проекта и связывает разрозненные фрагменты. Рекомендации становятся точнее, выводы глубже, меньше фолс-позитивов.
🔌 3. Модульная система плагинов
Поддерживаемые языки: C, C++, Python, Rust, TypeScript.
Можно писать плагины под внутренние DSL или добавлять собственные security-чеклисты.
🗄️ Гибкая работа с векторными БД
Поддержка:
- ChromaDB по умолчанию
- PostgreSQL + pgvector для продакшена и CI/CD
🤖 5. Интеграция LLM
Из коробки идет OpenAI, но архитектура легко расширяется под любые корпоративные модели.
⚙️ Гибкость и кастомизация
📝 Конфигурации в metis.yaml: параметры LLM, базы данных, чанки, анализ.
🧠 Настройка подсказок (plugins.yaml): можно задать правила безопасности, отраслевые стандарты и корпоративные playbooks.
🧱 Настраиваемое разбиение кода на чанки, что важно для больших репозиториев.
🔧 Плагинная архитектура позволяет поддерживать любые языки и внутренние форматы.
⚠️ Минусы
🧭 Не все языки поддерживаются, для редких потребуется плагин.
💸 LLM = дополнительные расходы.
🤷 Возможны ошибки рассуждения при недостатке контекста.
🔧 Первичная настройка требует времени
🔗 Ссылка на GitHub
Stay secure and read SecureTechTalks 📚
#AIsecurity #AppSec #SAST #ARM #Metis #SecureCoding #DevSecOps #CyberSecurity #RAG #LLM
Сегодня рассмотрим весьма интересный проект OSINT для AppSec: Metis от ARM, семантический ИИ-инструмент, который читает код, как человек, и анализирует его, как машина.
🔎 Что такое Metis?
Metis - это AI-фреймворк для глубокого анализа безопасности исходного кода, который использует большие языковые модели (LLM) и RAG-архитектуру.
💡 Назван в честь богини мудрости Метис. Заявляется, что инструмент «понимает» код.
🚀 Ключевые особенности
🧬 Семантическое понимание кода
- Не ищет шаблоны или регулярки, а анализирует смысл, архитектуру и контекст.
- Выявляет логические и концептуальные уязвимости, которые статические анализаторы часто пропускают.
🧩Контекстно-чувствительный анализ
Metis строит собственную векторную базу проекта и связывает разрозненные фрагменты. Рекомендации становятся точнее, выводы глубже, меньше фолс-позитивов.
🔌 3. Модульная система плагинов
Поддерживаемые языки: C, C++, Python, Rust, TypeScript.
Можно писать плагины под внутренние DSL или добавлять собственные security-чеклисты.
🗄️ Гибкая работа с векторными БД
Поддержка:
- ChromaDB по умолчанию
- PostgreSQL + pgvector для продакшена и CI/CD
🤖 5. Интеграция LLM
Из коробки идет OpenAI, но архитектура легко расширяется под любые корпоративные модели.
⚙️ Гибкость и кастомизация
📝 Конфигурации в metis.yaml: параметры LLM, базы данных, чанки, анализ.
🧠 Настройка подсказок (plugins.yaml): можно задать правила безопасности, отраслевые стандарты и корпоративные playbooks.
🧱 Настраиваемое разбиение кода на чанки, что важно для больших репозиториев.
🔧 Плагинная архитектура позволяет поддерживать любые языки и внутренние форматы.
⚠️ Минусы
🧭 Не все языки поддерживаются, для редких потребуется плагин.
💸 LLM = дополнительные расходы.
🤷 Возможны ошибки рассуждения при недостатке контекста.
🔧 Первичная настройка требует времени
🔗 Ссылка на GitHub
Stay secure and read SecureTechTalks 📚
#AIsecurity #AppSec #SAST #ARM #Metis #SecureCoding #DevSecOps #CyberSecurity #RAG #LLM
🤖🔧 LLM против уязвимостей: почему реальные баги чинятся лучше, чем искусственные
Большое исследование, которое проверяет истории о «самочинящихся» кодерах
Автоматическое исправление уязвимостей мечта индустрии последние двадцать лет. Мы уже пережили эпоху статических анализаторов, десятки попыток построить идеальный Automated Program Repair (APR) и сотни докладов, которые обещали «починку кода одним кликом».
Сегодня у нас бум LLM. Модели генерируют не только стихи, но и создают патчи. В соцсетях уже гуляют скриншоты, где ChatGPT «за секунду» чинит SQLi или XSS.
Тем не мене вопрос остаётся открытым:
Команда исследователей из Luxembourg Institute of Science and Technology решила проверить, что LLM умеют патчить в реальном бою, когда исправления проверяют не глазами разработчика, а Proof-of-Vulnerability (PoV) тестами
🎯 Исследование
Исследование охватило 14 различных LLM, включая модели OpenAI (GPT-3.5, GPT-4, GPT-4o), Meta LLaMA (версии 3.1 и 3.3), DeepSeek R1 Qwen и несколько версий Mistral.
Модели тестировали на двух типах уязвимостей:
🔹 Реальные уязвимости
15 CVE из датасета Vul4J: уязвимый код, PoV-тест, гарантированно воспроизводящий атаку.
🔹 Искусственные уязвимости
41 синтетическая уязвимость, созданная исследователями на базе реальных, с изменениями в коде, но с тем же PoV-фейлом.
Искусственные баги воспроизводили те же ошибки, что и реальные, но выглядели иначе.
🔥 LLM плохо справляются с искусственными уязвимостями
Половина реальных уязвимостей была успешно исправлена хотя бы одной моделью. Однако была исправлена лишь четверть искусственных уязвимостей. LLM не распознавали паттерны искусственных уязвимостей.
Причина проста:
🧠 LLM чинят то, что узнают, а не то, что понимают
Модель не анализирует механику уязвимости, она пытается "вспомнить" похожий патч из обучающих данных.
🧪 Как проходило тестирование
Каждая модель получала строгий промпт:
Далее происходило следующее:
🧩 Исследователи подменяли функцию в реальном проекте.
🧱 Проект пересобирался.
💥 Прогонялся PoV-тест (реальный эксплойт).
🛡 Если PoV больше не мог воспроизвести атаку, то фикс засчитывался.
Если код не компилировался или эксплойт всё ещё работал, то патч считался провальным.
🥇 Кто справился лучше всего
В абсолютных числах:
➖ DeepSeek R1 Qwen 32B исправил 14 уязвимостей
➖ Mistral 8×7B тоже 14 уязвимостей
➖ GPT-4 и GPT-4 Turbo по 9 исправлений
➖ Остальные модели оказались слабее: около 5–6 успешных патчей.
При этом:
❗ Никто не стал «универсальным патчером».
Нет модели, которая стабильно и хорошо чинит всё.
💣 Примеры
✅ Успешный случай: CVE-2013-5960
Ошибка в криптографии (AES/CBC → AES/GCM).
Все модели без исключения смогли заменить режим и настроить correct tag length.
Почему?
Потому что это «шаблонное» исправление, встречающееся в тысячах проектов.
❌ Провальный случай: XXE в Apache Batik
Для полного исправления XXE нужно:
отключить external entities;
обновить зависимость Batik на версию, где этот флаг работает корректно.
Все модели делали только шаг №1.
PoV продолжал считывать содержимое локального файла. Уязвимость оставалась.
Причина:
LLM не может увидеть зависимость, не может проверить билд, не понимает контекст.
🔗 Ссылка на исследование: https://arxiv.org/abs/2511.23408
Stay secure and read SecureTechTalks 📚
#cybersecurity #infosec #LLM #AIsecurity #vulnerabilities #javasecurity #research #securecoding #patching #SecureTechTalks
Большое исследование, которое проверяет истории о «самочинящихся» кодерах
Автоматическое исправление уязвимостей мечта индустрии последние двадцать лет. Мы уже пережили эпоху статических анализаторов, десятки попыток построить идеальный Automated Program Repair (APR) и сотни докладов, которые обещали «починку кода одним кликом».
Сегодня у нас бум LLM. Модели генерируют не только стихи, но и создают патчи. В соцсетях уже гуляют скриншоты, где ChatGPT «за секунду» чинит SQLi или XSS.
Тем не мене вопрос остаётся открытым:
🧩 А насколько эти патчи вообще работают, когда дело доходит до реальных эксплойтов, а не до красивых текстовых примеров?
Команда исследователей из Luxembourg Institute of Science and Technology решила проверить, что LLM умеют патчить в реальном бою, когда исправления проверяют не глазами разработчика, а Proof-of-Vulnerability (PoV) тестами
🎯 Исследование
Исследование охватило 14 различных LLM, включая модели OpenAI (GPT-3.5, GPT-4, GPT-4o), Meta LLaMA (версии 3.1 и 3.3), DeepSeek R1 Qwen и несколько версий Mistral.
Модели тестировали на двух типах уязвимостей:
🔹 Реальные уязвимости
15 CVE из датасета Vul4J: уязвимый код, PoV-тест, гарантированно воспроизводящий атаку.
🔹 Искусственные уязвимости
41 синтетическая уязвимость, созданная исследователями на базе реальных, с изменениями в коде, но с тем же PoV-фейлом.
Искусственные баги воспроизводили те же ошибки, что и реальные, но выглядели иначе.
🔥 LLM плохо справляются с искусственными уязвимостями
Половина реальных уязвимостей была успешно исправлена хотя бы одной моделью. Однако была исправлена лишь четверть искусственных уязвимостей. LLM не распознавали паттерны искусственных уязвимостей.
Причина проста:
🧠 LLM чинят то, что узнают, а не то, что понимают
Модель не анализирует механику уязвимости, она пытается "вспомнить" похожий патч из обучающих данных.
🧪 Как проходило тестирование
Каждая модель получала строгий промпт:
"Исправь уязвимость. Не меняй ничего лишнего. Верни только Java-функцию."
Далее происходило следующее:
🧩 Исследователи подменяли функцию в реальном проекте.
🧱 Проект пересобирался.
💥 Прогонялся PoV-тест (реальный эксплойт).
🛡 Если PoV больше не мог воспроизвести атаку, то фикс засчитывался.
Если код не компилировался или эксплойт всё ещё работал, то патч считался провальным.
🥇 Кто справился лучше всего
В абсолютных числах:
При этом:
❗ Никто не стал «универсальным патчером».
Нет модели, которая стабильно и хорошо чинит всё.
💣 Примеры
✅ Успешный случай: CVE-2013-5960
Ошибка в криптографии (AES/CBC → AES/GCM).
Все модели без исключения смогли заменить режим и настроить correct tag length.
Почему?
Потому что это «шаблонное» исправление, встречающееся в тысячах проектов.
❌ Провальный случай: XXE в Apache Batik
Для полного исправления XXE нужно:
отключить external entities;
обновить зависимость Batik на версию, где этот флаг работает корректно.
Все модели делали только шаг №1.
PoV продолжал считывать содержимое локального файла. Уязвимость оставалась.
Причина:
LLM не может увидеть зависимость, не может проверить билд, не понимает контекст.
🔗 Ссылка на исследование: https://arxiv.org/abs/2511.23408
Stay secure and read SecureTechTalks 📚
#cybersecurity #infosec #LLM #AIsecurity #vulnerabilities #javasecurity #research #securecoding #patching #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1👏1
🧠 AppSec переезжает в редактор кода
Сегодня Copilot или LLM способны генерировать целые фрагменты бизнес-логики за минуты.
Разработчик всё чаще не пишет код вручную, а проверяет уже готовый результат. Таким образом количество нового кода начинает расти быстрее, чем человек успевает анализировать его с точки зрения безопасности.
⚙️ Security-проверки прямо во время написания кода
Heidi - open-source security plugin для IDE, который анализирует код прямо в процессе редактирования. Плагин отслеживает изменения в файлах и пытается находить опасные конструкции ещё до запуска приложения:
🔹 insecure API usage
🔹 hardcoded secrets
🔹 shell/command injection patterns
🔹 небезопасную работу с filesystem
🔹 потенциально опасную обработку пользовательского ввода
Анализ идёт не только по сигнатурам. Heidi пытается учитывать контекст: откуда приходят данные, проходят ли они sanitization и куда попадают дальше.
Например, плагин может заметить, что input пользователя без фильтрации уходит в SQL query, shell execution или filesystem operation.
🧪 Принцип работы
Под капотом Heidi использует инкрементальный анализ, т.к. плагин работает внутри IDE и не может позволить себе полноценный перескан проекта после каждого нажатия клавиши. Вместо этого анализируются только изменения и связанные с ними участки кода.
Инсирумент строит lightweight security-analysis pipeline прямо внутри editor runtime.
Для detection используются: 🔹 pattern-based rules
🔹 context-aware checks
🔹 анализ data flow между источниками input и sensitive operations
Система пытается видеть не только отдельную опасную строку, но и цепочку прохождения данных через код.
🧨 Главная проблема таких систем
Сделать security-плагин сложно не технически.Сложно сделать так, чтобы разработчики его не возненавидели.
Если система начинает агрессивно спамить warning’ами, люди быстро перестают обращать внимание на алерты. Если detection слишком мягкий, то реальные проблемы проходят мимо.
Особенно тяжело анализировать AI-generated code, ведь он часто выглядит syntactically clean, но содержит опасные assumptions, которые плохо ловятся простыми сигнатурами.
🔗 Ссылки для скачивания:
➖ JetBrains
➖ VS Code Marketplace
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AppSec #SecureCoding #DevSecOps #IDE #CodeSecurity #OpenSource #SecureTechTalks
Сегодня Copilot или LLM способны генерировать целые фрагменты бизнес-логики за минуты.
Разработчик всё чаще не пишет код вручную, а проверяет уже готовый результат. Таким образом количество нового кода начинает расти быстрее, чем человек успевает анализировать его с точки зрения безопасности.
⚙️ Security-проверки прямо во время написания кода
Heidi - open-source security plugin для IDE, который анализирует код прямо в процессе редактирования. Плагин отслеживает изменения в файлах и пытается находить опасные конструкции ещё до запуска приложения:
🔹 insecure API usage
🔹 hardcoded secrets
🔹 shell/command injection patterns
🔹 небезопасную работу с filesystem
🔹 потенциально опасную обработку пользовательского ввода
Анализ идёт не только по сигнатурам. Heidi пытается учитывать контекст: откуда приходят данные, проходят ли они sanitization и куда попадают дальше.
Например, плагин может заметить, что input пользователя без фильтрации уходит в SQL query, shell execution или filesystem operation.
🧪 Принцип работы
Под капотом Heidi использует инкрементальный анализ, т.к. плагин работает внутри IDE и не может позволить себе полноценный перескан проекта после каждого нажатия клавиши. Вместо этого анализируются только изменения и связанные с ними участки кода.
Инсирумент строит lightweight security-analysis pipeline прямо внутри editor runtime.
Для detection используются: 🔹 pattern-based rules
🔹 context-aware checks
🔹 анализ data flow между источниками input и sensitive operations
Система пытается видеть не только отдельную опасную строку, но и цепочку прохождения данных через код.
🧨 Главная проблема таких систем
Сделать security-плагин сложно не технически.
Если система начинает агрессивно спамить warning’ами, люди быстро перестают обращать внимание на алерты. Если detection слишком мягкий, то реальные проблемы проходят мимо.
Особенно тяжело анализировать AI-generated code, ведь он часто выглядит syntactically clean, но содержит опасные assumptions, которые плохо ловятся простыми сигнатурами.
🔗 Ссылки для скачивания:
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AppSec #SecureCoding #DevSecOps #IDE #CodeSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧨 Vibe coding создает новый класс уязвимых приложений
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
👍2
🧠 Open source проекты начали отказываться от LLM при разработке
Software Freedom Conservancy (SFC) выпустили довольно интересный документ с рекомендациями по использованию LLM в open-source проектах.
Спойлер:не стоит использовать генеративный AI там, где важны происхождение кода, лицензирование и безопасность.
⚙️ В чём проблема?
SFC отдельно разбирают, что LLM ломают базовые гарантии open-source supply chain. Когда разработчик вставляет сгенерированный код, он часто не знает:
🔹 откуда этот код появился
🔹 на какой лицензии он основан
🔹 не попал ли туда копипаст из GPL/AGPL
🔹 нет ли внутри старых CVE- паттернов
🔹 не повторяет ли модель insecure implementation
По сути provenance кода исчезает. А вместе с ним ломается возможность проведения аудита, а при инцидентах становится сложнее понять источник уязвимости.
🧨 Паттерны
LLM отлично генерируют рабочий код, но плохо генерируют механизмы защиты. Типичный паттерн, когда функция работает, но модель аудита упрощёна, проверка входных параметров поверхностная, управление секретами отсутствует.
Это напрямую совпадает с последними исследованиями по vibe coding.
🛡️ Что рекомендуют?
SFC советуют использовать LLM максимально ограниченно:
➖ не принимать код без полного human review
➖ не использовать генерацию для security-sensitive logic
➖ документировать AI-origin code
➖ отдельно прогонять его через аудит
➖ учитывать license contamination risk
Если подытожить, то AI-code теперь предлагают рассматривать как недоверенные сторонние зависимости.
🔗 Статья: https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenSource #SupplyChainSecurity #AppSec #SecureCoding #DevSecOps #CyberSecurity #SecureTechTalks
Software Freedom Conservancy (SFC) выпустили довольно интересный документ с рекомендациями по использованию LLM в open-source проектах.
Спойлер:
⚙️ В чём проблема?
SFC отдельно разбирают, что LLM ломают базовые гарантии open-source supply chain. Когда разработчик вставляет сгенерированный код, он часто не знает:
🔹 откуда этот код появился
🔹 на какой лицензии он основан
🔹 не попал ли туда копипаст из GPL/AGPL
🔹 нет ли внутри старых CVE- паттернов
🔹 не повторяет ли модель insecure implementation
По сути provenance кода исчезает. А вместе с ним ломается возможность проведения аудита, а при инцидентах становится сложнее понять источник уязвимости.
🧨 Паттерны
LLM отлично генерируют рабочий код, но плохо генерируют механизмы защиты. Типичный паттерн, когда функция работает, но модель аудита упрощёна, проверка входных параметров поверхностная, управление секретами отсутствует.
Это напрямую совпадает с последними исследованиями по vibe coding.
🛡️ Что рекомендуют?
SFC советуют использовать LLM максимально ограниченно:
Если подытожить, то AI-code теперь предлагают рассматривать как недоверенные сторонние зависимости.
🔗 Статья: https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenSource #SupplyChainSecurity #AppSec #SecureCoding #DevSecOps #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
📌 Уязвимость не всегда живёт в одном файле
Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через controller, проходят DTO, service layer, helper’ы, а потом внезапно оказываются внутри SQL-запроса, shell-команды или file API.
На GitHub появился новый open-source инструмент от PhonePe "Nika".
Инструмент строит полный путь движения данных через приложение, что делает анализ намного ближе к реальной эксплуатации.
⚙️ Что умеет Nika?
Внутри:
🔹 строит межфайловый graph зависимостей
🔹 делает inter-procedural taint tracking
🔹 связывает source → propagation → sink
🔹 анализирует branch-aware изменения (полезно для PR review)
🔹 использует AI-assisted triage для сокращения false positives
Поддерживаемые sink’и:
• SQL execution
• File system operations
• Template engines
• Reflection
• Network requests
• Deserialization points
Для понимания, инструмент не про «подозрительные строки», а про реальные пути эксплуатации.
Для security review больших Java codebase это особенно полезно, потому что позволяет быстро понять, как именно пользовательский ввод проходит через бизнес-логику.
🤖 Интересный момент
После основного анализа Nika умеет прогонять findings через LLM и дополнительно фильтровать шум. Это хороший пример правильного применения AI в AppSec, т.к. AI здесь не ищет баги, а помогает понять насколько они эксплуатируемые.
🔗 Исходники:
https://github.com/PhonePe/nika
Stay secure and read SecureTechTalks 📚
#cybersecurity #appsec #devsecops #javasecurity #taintanalysis #securecoding #opensource #codeaudit #infosec #securetechtalks
Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через controller, проходят DTO, service layer, helper’ы, а потом внезапно оказываются внутри SQL-запроса, shell-команды или file API.
На GitHub появился новый open-source инструмент от PhonePe "Nika".
Инструмент строит полный путь движения данных через приложение, что делает анализ намного ближе к реальной эксплуатации.
⚙️ Что умеет Nika?
Внутри:
🔹 строит межфайловый graph зависимостей
🔹 делает inter-procedural taint tracking
🔹 связывает source → propagation → sink
🔹 анализирует branch-aware изменения (полезно для PR review)
🔹 использует AI-assisted triage для сокращения false positives
Поддерживаемые sink’и:
• SQL execution
• File system operations
• Template engines
• Reflection
• Network requests
• Deserialization points
Для понимания, инструмент не про «подозрительные строки», а про реальные пути эксплуатации.
Для security review больших Java codebase это особенно полезно, потому что позволяет быстро понять, как именно пользовательский ввод проходит через бизнес-логику.
🤖 Интересный момент
После основного анализа Nika умеет прогонять findings через LLM и дополнительно фильтровать шум. Это хороший пример правильного применения AI в AppSec, т.к. AI здесь не ищет баги, а помогает понять насколько они эксплуатируемые.
🔗 Исходники:
https://github.com/PhonePe/nika
Stay secure and read SecureTechTalks 📚
#cybersecurity #appsec #devsecops #javasecurity #taintanalysis #securecoding #opensource #codeaudit #infosec #securetechtalks
👍3