Смена парадигмы безопасной разработки в эпоху software 3.0

Часть 1 - AppSec 1.0

Disclaimer: всё написанное является субботней фантазией автора

Навигация:
- Часть 1 - AppSec 1.0
- Часть 2 - AppSec 2.0, предпосылки
- Часть 3 - AppSec 2.0, дизрапт рынка
- Часть 4 - AppSec 2.0, дизрапт технологий
- Часть 5

Процессы безопасной разработки сложны для разработчиков.

За время работы в области Application Security меня не покидала мысль, что эта часть рынка ИБ недооценена, а её проникновение в процессы IT неоправданно низкое. Причина сложностей с осознанием ценности заключалась в целевой аудитории: классическая безопасность создана для безопасников, чей основной род деятельности - обеспечивать безопасность компании, такие продукты разрабатывать просто. Application Security, как класс продуктов, создан для разработчиков, чьим основным хлебом редко является написание безопасных программ, отдавая приоритет разработке бизнес логики, работающей функционально.

AppSec нужен для разработчиков, а создается безопасниками.

Индустрия построена на отсутствии знаний у первых и на глубокой экспертизе вторых. Это приводит к следующим побочным эффектам:
1. Инструменты требуют дополнительных знаний от разработчиков. Не столько даже про использование инструментов, сколько в целом domain knowledge, чтобы просто в процессе работы использовать безопасные парадигмы разработки ПО. Эта проблема закрывается дополнительными должностями, такими как devsecops и/или appsec специалисты, которые забирают на себя фукнцию ответственности за безопасную разработку.
2. Это делает процесс безопасной разработки дорогим, из-за чего средний и малый бизнесы предпочитает жить без него.

В этом уравнении разработчики отсутствуют как самодостаточная единица, изредка дополняя 1 категорию как security-чемпионы.

В результате чего появляется целый рынок продуктов с платной поддержкой и консалтингом, которые нацелены на первую группу (где есть деньги), а индустрия AppSec'а по большей части становится B2B. Т.к. домен оказался сложным для разработки, ЦА становятся appsec/devsecops инженеры и индустрия обретает уже знакомую ранее парадигму:

AppSec 1.0 - безопасность создана для безопасников, чей основной род деятельности - обеспечивать безопасность.

Смотря на это, ответьте: существовал ли Application Security органически до наших дней? Точно ли разработчики - идеологически правильная ЦА?

Продолжение следует...

Смена парадигмы безопасной разработки в эпоху software 3.0

Часть 2 - AppSec 2.0, предпосылки

Disclaimer: всё написанное является субботней фантазией автора

Навигация:
- Часть 1 - Appsec 1.0
- Часть 2 - AppSec 2.0, предпосылки
- Часть 3 - AppSec 2.0, дизрапт рынка
- Часть 4 - AppSec 2.0, дизрапт технологий
- Часть 5

Вайбкодинг и agentic engineering меняют подход к разработке.

Андрей Карпаты вводит термин software 3.0, который описывает текущее состояние мировой индустрии IT. Это понятие совмещает в себе подходы агентской разработки разного уровня зрелости: вайбкодинг и agentic engineering (о разнице между ними можно послушать тут).

AI трансформирует рынок IT сразу в нескольких направлениях:
- меньшее число разработчиков могут донести бизнес ценность. Продукты начинают создаваться командами до 10 человек вооруженных агентами, доходя до крайних случаев с штатом из одного CEO и десятка агентов вместо подчиненных. Кратно растет число продуктов и компаний стартапов/среднего/малого бизнеса
- подписки на кодинг агентов становятся коммодити при найме на работу, а где еще не стали - сотрудники скрыто используют за свои деньги из страха отстать от индустрии.
- фокус разработчиков переходит с написания кода на дизайн архитектуры/написание спецификаций и проверку результата.
- рост числа IT продуктов порождает рост популярности фреймворков для разработки.

Разработка, как написание кода, становится частью работы агентов, а не разработчиков.

Но новая реальность еще не устоялась и распределена неравномерно:
- LLM обучены на терабайтах кода, написанного разработчиками без знания безопасной разработки (почему - читайте часть 1). На это есть исследования, кому интересно - тык (тг обзор коллеги), тык
- так как фокус меняется с кода на дизайн системы и бизнес ценность, а LLM обучены на уязвимом коде - появляются сотни продуктов среднего/малого бизнеса и проектов с уязвимостями разного уровня критичности.
- Так как (см часть 1) для среднего/малого бизнеса не существует рефлекса на безопасную разработку, общая доля уязвимых к атакам приложений растет в абсолютном выражении.
- Но, как верно отмечено в комментах первой части, рынок безопасной разработки сфокусирован на B2B security-центричной модели, поэтому "проекты/компании из одного сотрудника" им не покрыты в должной степени


Тогда второй вопрос: если разработка ПО в части написания кода в ближайшее время перестанет быть рутиной разработчика, а новый рынок не имеет security отделов, то, чисто идеологически, кому должны быть удобны инструменты безопасной разработки?

Продолжение следует...

Простите, я допишу, работа просто

Любой открытый фиксированный бенчмарк (даже хороший) - устаревает, как только попадает за knowledge cutoff. Хотите держать актуальность - делайте закрытый или регулярно обновляемый.

Смена парадигмы безопасной разработки в эпоху software 3.0

Часть 3 - AppSec 2.0, дизрапт рынка

Disclaimer: всё написанное является субботней фантазией автора

Навигация:
- Часть 1 - AppSec 1.0
- Часть 2 - AppSec 2.0, предпосылки
- Часть 3 - AppSec 2.0, дизрапт рынка
- Часть 4 - AppSec 2.0, дизрапт технологий
- Часть 5

Свой дальнейший прогноз я собираю из следующего пазла фактов:
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

Продолжение следует...

Смена парадигмы безопасной разработки в эпоху software 3.0

Часть 3 - AppSec 2.0, дизрапт технологий

Disclaimer: всё написанное является субботней фантазией автора

Навигация:
- Часть 1 - AppSec 1.0
- Часть 2 - AppSec 2.0, предпосылки
- Часть 3 - AppSec 2.0, дизрапт рынка
- Часть 4 - AppSec 2.0, дизрапт технологий
- Часть 5

Про рынок поговорили, а что по технологиям?

Почему нельзя просто попросить 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)

Продолжение следует...

Помните кейс LiteLLM?

Мы дропаем OMCBench (Open Malicious-Code Benchmark) - бенчмарк оценки качества по обнаружению вредоносного кода:
- 3 языка: Python, JavaScript, TypeScript
- 400 вредоносных пакетов, 400 чистых из pypi/npm
- пофайловая LLM разметка, о которой говорили на OFFZONE прошлым летом
- Открытая лицензия, BSD-2

Открытые решения на нем набирают не больше 75% F1, выдавая ~50% False Positive результатов...

Те, кто уже нажал звездочку на гитхабе, могли заметить, что в таблице мы также анонсим MOLOT - нашу модель для решения этого класса задач. Ловите блогпост, а на подходе arxiv статья с подробностями про анализ графов вызовов бертами, LLM разметку и выкатку в prod!

Ждите дроп статьи в канале, stay tuned!

Все, кому не отвечал последние недели - надеюсь вы меня простите!

Потому что мы еще не выложили статью на arxiv, я еще немного поигнорю...

В лс получил вопрос по поводу актуальных ML&Security тем для диплома:

Следующий год - ВКР. Сейчас начинаю искать тему для научного трека. <...тут текущие треки, интересные студенту...>

Буду признателен если сориентируете по актуальным темам сейчас в отрасли MLSec.

Предложил следующее (опустим обсуждение тем студента):

Из того, что индустрии нужно "сегодня":
- Всевозможные триаж технологии - триаж инцидентов SOC (сеть, хосты, веб), триаж сработок инструментов AppSec (sast/dast/секреты/комбинация предыдущих)
- Agent оркестраторы/агенты поверх инструментов ИБ (автопентест/автофаззер/авто...), всевозможные тестирования на OSS базах уязвимостей/CTF и bugbounty
- Оптимизация decoder/encoder архитектур под домен ИБ (лучше токенизация, разделение срытого пространства на какой-то задаче, удержание длинного контекста)
- Интерпретируемость моделей и агентов в контексте ИБ (умение комбинировать ML методы типа shap/logprob анализа и ИБ запросов к обоснованию вредоноса/инцидента/атаки/..., может быть смотреть скрытые представления)
- RL среды для генерации ИБ сценариев (gym фреймворки, генерация синтетики там, где не хватает настоящих данных)
- Борьба с deepfake
- Правовые аспекты: соблюдение правовых норм при работе с данными, используемыми для обучения модели, автоматизация требований ГОСТ по безопасной разработки систем с ИИ
- Аппаратная безопасность, Безопасность современных ЦОД (RDMA, Infiniband, GPU)


Из того, что индустрии пригодится "завтра", подо что пока не так много спроса у рынка, но потребности растут как грибы - AISec/MLSec/...:
- анализ скрытых возможностей LLM/агентов - умение выходить из среды текстирования/докера/..., умение скрывать логику размышлений
- llm-firewall как в классификации request/response, так и prompt-injection/sponge-атаки и подобные защищающие агентов механизмы
- элаймент на уровне обнуления/изменения весов модели (не проверять через llmwaf политический контекст, а заблокировать модели возможность говорить об этом)
- Верификация скиллов и MCP
- Защита моделей на конечных устройствах

Что скажете по написанному - нигде не соврал? Может что забыл?

Давайте поможем студентам, накидаем вариантов:)

UPD: пост обновлен, с тематических каналов прилетело много полезного!

Теперь я могу публиковать пейперы! 🎉

Статья по MOLOT’у уже в пути

2 года назад для повышения знаний MLE в ИБ, в качестве эксперимента, нас посадили на 3 дня в смену первой линии SOC (Security Operations Center).

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

Cейчас меня откинуло на 2 года назад - прошел игру Dwell Time, сделанную коллегой, чтобы каждый мог пережить опыт работы ИБ специалиста SOC без смс и регистрации.

Объяснение базы, имитация рабочего процесса, хинты, сюжетность - идеальная игра для погружения в ИБ с нуля!

Это было потно, но удалось забрать 29/30. Кидайте в комменты как прошла бы ваша смена?


Fun fact: В один из трех дней я проспал будильник и проснулся прям к началу смены, и, открыв ноут сразу следом за глазами, я не смог 11 раз ввести свой пароль. Было забавно увидеть свою учетку в списке инцидентов на брутфорс...

Так, блог-заметки по MOLOT'у подоспели, го читать и лайкать:
- ru
- eng

Сегодня наша команда держала стенд на технохабе Сбера, активность по ML System Design в ИБ дропну тут на память ✍️