Часть 3 - AppSec 2.0, дизрапт рынка
Disclaimer: всё написанное является субботней фантазией автора
Навигация:
- Часть 1 - AppSec 1.0
- Часть 2 - AppSec 2.0, предпосылки
- Часть 3 - AppSec 2.0, дизрапт рынка
- Часть 4 - AppSec 2.0, дизрапт технологий
- Часть 5 - AppSec 3.0, сингулярность
Свой дальнейший прогноз я собираю из следующего пазла фактов:
1. Процессы безопасной разработки так и не стали органической частью жизни разработчиков. Этому не учат на первых курсах по программированию, этот процесс искусственно заводится в компаниях, где размер бизнеса становится критичнее расходов на поддержание appsec.
2. Одной подпиской на кодинг агента, как правило, пользуется один разработчик (team plan - это набор подписок, по одной на каждого сотрудника)
3. Агенты забирают на себя написание кода, его тестирование и деплой, оставляя человеку дизайн/спецификации/приемку результата.
4. В первой части я упоминал проблему отсутствия knowledge base у разработчиков как один из барьеров работы по appsec правилам. В отличие от разработчиков, у LLM уже достаточно теоретических/энциклопедических знаний о ИБ и безопасной разработке в частности.
5. Как упоминал во второй части - число соло фаундеров/мэинтейнеров растет с проникновением software 3.0 в IT.
6. Также растущая хакерская агентская активность побуждает соло фаундеров/мэинтейнеров заниматься вопросами безопасности больше, чем это было раньше. Важность AppSec начинает расти для сегмента среднего/малого бизнеса.
Разработчики так и не освоят базовые энциклопедические знания по безопасной разработке, а агенты уже сейчас имеют их в обучающей выборке и забирают процесс написания кода.
Каким я вижу AppSec с точки зрения бизнеса?
- B2B рынок AppSec продолжит расти темпами роста всего ИБ. Старые процессы не умрут моментально, аппсек отделы и регуляторика останутся, удерживая рынок, но взрывного роста не случится из-за большой связности текущих процессов на человеке (несение ответственности в крупном бизнесе, сертификации и т.д)
- Дизраптом AppSec индустрии станет появление B2C решений (или по модному - B2A, agent), где разработчик будет платить за инструменты/харнесс для своего персонального агента, чтобы не погружаться в домен и поддерживать безопасность среднего/малого бизнеса, который раньше обходился без безопасной разработки.
- Заберут этот рынок AppSec вендоры, чьи решения окажутся наиболее удобными в использовании агентами, а пользователь сможет начать работу сразу после оплаты картой подписки, как это сейчас происходит с кодинг агентами. Важны оба фактора, считаю что не выживут как удобные агентские решение с B2B квартальными циклом внедрения, так и удобные сервисы оплаты с медленными и неприспособленными инструментами.
- Как сейчас у многих сформировалась привычка к агентской разработке, так сформируется и рынок персональных подписок на AppSec, который со временем вытеснит классический B2B цикл внедрений/пилотов/тендеров.
AppSec 2.0 - переход от security-центричной B2B парадигмы к agentic-центричной B2C/B2A.
TLDR: Рынок AppSec кратно вырастит, но не органически, а за счет дизрапта в B2C/B2A. Со временем удобство нового подхода погубит сегодняшний B2B (2029+):
Новый рынок создаст новую привычку, новая привычка вытеснит старый рынок.
Тезисы выше также неплохо ложатся на размышления Карпаты о (не)удобстве сервисов разработки в целом для агентов (таймкод):
I’m hoping there will be a lot of agent-first infrastructure out there. For Menugen, when I wrote the blog post about it, a lot of the trouble was not even writing the code. It was deploying it in Vercel, because I had to work with all these different services, string them together, go into their settings and menus, configure my DNS, and it was just so annoying.
That’s a good example of what I’d hope for: I could give a prompt to an LLM — “Build Menugen” — and then I wouldn’t have to touch anything, and it would be deployed on the internet in that same way. I think that would be a good test for whether our infrastructure is becoming more agent-native
Продолжение следует...