Смена парадигмы безопасной разработки в эпоху software 3.0
Часть 4 - AppSec 2.0, дизрапт технологийDisclaimer:
всё написанное является субботней фантазией автораНавигация:
-
Часть 1 - AppSec 1.0-
Часть 2 - AppSec 2.0, предпосылки-
Часть 3 - AppSec 2.0, дизрапт рынка- Часть 4 - AppSec 2.0, дизрапт технологий
-
Часть 5 - AppSec 3.0, сингулярностьПро рынок поговорили, а что по технологиям?
Почему нельзя просто попросить codex/claude code сделать безопасно?
Одна из причин, по которой фронтир лаборатории активно раздают партнерские программы в области кибербезопасности - этот домен пока плохо измерим на RL этапах обучения LLM, где важно
эффективное и стабильное использование окружения, поэтому находится в зоне шероховатости (какие шероховатости?
ловите таймлайн, Андрей Карпаты объясняет превосходно). Мы видим значительный прирост качества на многих бенчмарках, но условия этих бенчмарков проверяют самые простые задачи кибербезопасности (за исключением offense, где волей случая ctf соревнования получились идеальными RL средами с понятными метриками награды). Сложные же задачи, по типу PR на security issue, тяжело причесывать для RL, тяжко проверять сразу 2 сценария: закрыли безопасность, не поломали логику.
Решение, которое
предлагает Карпаты для борьбы с зонами шероховатости - строить среды/сценарии проверки качества. Но Андрей говорит об этом в контексте файнтюнинга, а я бы расширил этот тезис до обвязок/харнесса для этих сценариев, чтобы модели общего назначения смогли с их использованием выдавать хорошее качества, а эти трейсы в дальнейшем использовать уже для тюна своих моделей.
Вокруг агента нужны хорошие вендорские харнессы с глубокой экспертизой в безопасной разработке.
Возвращаясь к безопасной разработке,
каким будет AppSec 2.0 с точки зрения инструментов?- Поскольку агентская разработка многих компаний ушла в облако ради поспевания за прогрессом, это откроет дорогу к облачным AppSec инструментам там, где их раньше запрещали. А соло фаундеры и так всё держат в клауде: облачные модели, облачный гитхаб, хостинг, - AppSec 2.0 отлично ложится в эту парадигму.
- Инструменты - не только движки сканирования кода/приложений, но и харнесс: mcp, скиллы, sub-agents и т.д.
- Вендоры перейдут на md формат документации.
- Популярнее станут решения, которые сохранят ощущение "быстрой" разработки - быстрые сканирования, streaming вердикты. Такими уже как правило являются oss инструменты, поэтому вендоры возможно будут конкурировать за продажу экспертных паков правил под них.
- Вендорские харнессы будут сравниваться по совместимости с уже существующими кодинг агентами, потреблению токенов и, как ни странно, качеству.
- Клаудный подход поможет вендорам поддерживать экспертизу актуальной.
- Если инструменты использует AI, то они будут open-router формата с разделением на proxy/strict/local формат, где пользователь может выбрать фронтир модели и отдать безопасность на третью сторону, использовать модели иб вендора в strict mode (исключая 3-ю сторону) или выбрать локальное решение с допущением, что качество обычно кратно падает.
- Сами AppSec инструменты будут собирать множество логов для обучения моделей, конкурентных с фронтиром, как в своё время сделал Cursor на рынке агентской разработки (был харнесс IDE-проксей для claude и gpt, а затем выпустил composer)
Продолжение следует... 
