Посты
Как вы заметили, посты в канал последнее время выходили не чаще раза в неделю. Работы был…
17 декабря 2025 г. в 19:29•Max Knyazev is typing…Зеркало Telegram
Как вы заметили, посты в канал последнее время выходили не чаще раза в неделю. Работы было много, к концу года я устал сильнее обычного, параллельно еще и аспирантура свои приколы подкидывала (я сейчас одновременно три научные статьи пишу). И вот это все привело меня в дурку к решению уйти в отпуск 🌴
Итак, я взял отпуск впервые за последние 1,5 года. Чуть отдохнул, расслабился (даже поболеть успел за это время), поэтому наконец-то могу писать информативные длинные посты как и раньше. Надеюсь, что вы по ним соскучились. Сегодня поговорим про один классный инструмент, который я нашел на просторах опенсорса. Но обо всем по порядку⤵️
В AppSec есть один вечный парадокс. Мы умеем отлично искать типовые уязвимости, но часто промахиваемся мимо логических дефектов и каких-то более нестандартных вещей в коде. И каждый раз это заканчивается одной и той же фразой в отчете: "невозможно было выявить автоматизированными средствами". В подкасте КапИБары я об этом тоже говорил, когда отвечал на вопрос "Можно ли все закрыть сканерами?" (нет, нельзя, и причина как раз в этом)
FuzzForge AI как раз про попытку сломать этот паттерн👊
Классический AppSec-стек сегодня выглядит состоит из SAST, SCA, иногда DAST, иногда IAST, иногда фаззинг для критичных компонентов. Проблема в том, что почти все эти инструменты либо статичны, либо работают в рамках заранее известных паттернов. Они хорошо ловят инъекции, небезопасные зависимости, тривиальные ошибки сериализации. Но как только начинается сложная бизнес-логика, неочевидные сценарии, контекстные ограничения — сканер не справится
FuzzForge AI заходит ровно в эту серую зону. В AppSec-контексте идея проекта выглядит как LLM-assisted generation of application-aware inputs. То есть генерация тестовых данных не по формату, а с пониманием контекста API, протокола или сервиса. Модель может учитывать описание эндпоинта, предполагаемые сценарии использования, ожидаемые ограничения и целенаправленно пытаться их обойти😅
Проще говоря, это попытка автоматизировать то, что обычно делают пентестеры и AppSec-инженеры вручную: «а что будет, если передать это поле в другом состоянии», «а если шаги поменять местами», «а если соблюсти формат, но нарушить логику»
С точки зрения secure SDLC проект хорошо ложится в pre-prod и staging-контуры. Особенно там, где есть кастомные API и тд. Отдельно важно, что FuzzForge AI не позиционируется как «замена экспертизы». Это скорее ее усилитель. Инженер задает рамки, контекст, гипотезы, а LLM масштабирует попытки их сломать. Для AppSec это ровно та модель взаимодействия, которая нужна (человек думает, машина делает)
Если смотреть чуть вперёд, то тут уже читается задел под MLSecOps. Как мы контролируем поведение LLM-фаззера? Как фиксируем воспроизводимость багов? Как защищаемся от галлюцинаций модели? Как обеспечиваем детерминизм в CI/CD?
Конечно, проект ещё сырой. LLM может быть слишком вежливой к приложению, может зацикливаться, может генерировать валидные, но бесполезные кейсы. Но это проблемы роста, а не самой концепции. Думаю, через пару лет подобные инструменты прочно войдут в инструментарий AppDevMLSecOps-специалистов (запомните это, и если вдруг этого не будет, сможете тыкать в меня этим при встрече)😉
#информационная_безопасность
Открыть исходный пост в TelegramИтак, я взял отпуск впервые за последние 1,5 года. Чуть отдохнул, расслабился (даже поболеть успел за это время), поэтому наконец-то могу писать информативные длинные посты как и раньше. Надеюсь, что вы по ним соскучились. Сегодня поговорим про один классный инструмент, который я нашел на просторах опенсорса. Но обо всем по порядку
В AppSec есть один вечный парадокс. Мы умеем отлично искать типовые уязвимости, но часто промахиваемся мимо логических дефектов и каких-то более нестандартных вещей в коде. И каждый раз это заканчивается одной и той же фразой в отчете: "невозможно было выявить автоматизированными средствами". В подкасте КапИБары я об этом тоже говорил, когда отвечал на вопрос "Можно ли все закрыть сканерами?" (нет, нельзя, и причина как раз в этом)
FuzzForge AI как раз про попытку сломать этот паттерн
Классический AppSec-стек сегодня выглядит состоит из SAST, SCA, иногда DAST, иногда IAST, иногда фаззинг для критичных компонентов. Проблема в том, что почти все эти инструменты либо статичны, либо работают в рамках заранее известных паттернов. Они хорошо ловят инъекции, небезопасные зависимости, тривиальные ошибки сериализации. Но как только начинается сложная бизнес-логика, неочевидные сценарии, контекстные ограничения — сканер не справится
FuzzForge AI заходит ровно в эту серую зону. В AppSec-контексте идея проекта выглядит как LLM-assisted generation of application-aware inputs. То есть генерация тестовых данных не по формату, а с пониманием контекста API, протокола или сервиса. Модель может учитывать описание эндпоинта, предполагаемые сценарии использования, ожидаемые ограничения и целенаправленно пытаться их обойти
Проще говоря, это попытка автоматизировать то, что обычно делают пентестеры и AppSec-инженеры вручную: «а что будет, если передать это поле в другом состоянии», «а если шаги поменять местами», «а если соблюсти формат, но нарушить логику»
С точки зрения secure SDLC проект хорошо ложится в pre-prod и staging-контуры. Особенно там, где есть кастомные API и тд. Отдельно важно, что FuzzForge AI не позиционируется как «замена экспертизы». Это скорее ее усилитель. Инженер задает рамки, контекст, гипотезы, а LLM масштабирует попытки их сломать. Для AppSec это ровно та модель взаимодействия, которая нужна (человек думает, машина делает)
Если смотреть чуть вперёд, то тут уже читается задел под MLSecOps. Как мы контролируем поведение LLM-фаззера? Как фиксируем воспроизводимость багов? Как защищаемся от галлюцинаций модели? Как обеспечиваем детерминизм в CI/CD?
Конечно, проект ещё сырой. LLM может быть слишком вежливой к приложению, может зацикливаться, может генерировать валидные, но бесполезные кейсы. Но это проблемы роста, а не самой концепции. Думаю, через пару лет подобные инструменты прочно войдут в инструментарий AppDevMLSecOps-специалистов (запомните это, и если вдруг этого не будет, сможете тыкать в меня этим при встрече)
#информационная_безопасность