Agile Application Security (Рубрика #Security)

Три года назад я прочитал книгу "Agile Application Security", чтобы понять как можно встроить безопасность в процессы современной разработки.
Книга оказалась крутой — картинка в моей голове сложилась, но вот написать краткий обзор руки дошли только сейчас:)
Изначально я думал, что книжка поможет мне ознакомиться с текущим состоянием дел в безопасности. Но на самом деле авторы подошли с большим размахом к этой теме. В книге они поставили перед собой задачи:
- Рассказать разработчикам о том, как выглядит современные подходы к безопасности
- Рассказать олдскульным безопасникам как выглядит современная разработка и что запретительный подход из прошлого перестал работать при появлении современных подходов, например, CI/CD
И у авторов получилось:)
Подробности можно прочитать в обзоре https://apolomodov.medium.com/review-agile-application-security-e1c18ed65c19

#Software #SoftwareDevelopment #Security #DevSecOps #ExternalReview

Безопасность разработки в Agile-проектах (Agile Application Security: Enabling Security in a Continuous Delivery Pipeline)

Три года назад я прочитал эту превосходную книгу. Тогда я думал, что книжка поможет мне ознакомиться с текущим состоянием дел в безопасности. Но авторы подошли с большим размахом и поставили перед собой задачу:
- рассказать разработчикам о том, как выглядит современные подходы к безопасности
- рассказать олдскульным безопасникам как выглядит современная разработка и что запретительный подход из прошлого перестал работать при появлении современных подходов навроде CI/CD

В самом начале идет краткий экскурс в современную разработку в главах:
Глава 2. Элементы гибких методик
Глава 3. Революция в методах разработки - присоединяйтесь!
Глава 4. Работа с существующим жизненным цилком разработки
Эти начальные главы дают настолько хороший экскурс, что они будет полезны не только безопасникам, но и самим разработчикам, работающим в рамках гибких подходов, т.к. иногда следование процессам преващается в карго-культ или формопоклонничество как это называл Фейнман:) Поэтому иногда стоит вспоминать, что важен не сам процесс ради процесса, а те результаты, которые он помогает достигать.

Дальше идут главы про безопасность
Глава 5. Безопасность и требования. Тут речь идет о том, что безопасность - это просто еще одна область нефункциональных требований и ее стоит встривать в процесс работы над системой с самого начала как, например, вопросы производительности конечного решения или его удобства
Глава 6. Гибкое управление уязвимостями. Тут речь идет о том, как относится к уязвимостям, как учитывать их и как планировать их устранение, а также как связано тестирование и безопасность
Глава 7. Риск для гибких команд. Вся глава посвящена основам риск менеджмента в контексте вопросов безопасности. Если вы уже знакомы с этой областью знаний, то сложно будет найти что-то новое
Глава 8. Оценка угроз и осмысление атак. Одна из самых содержательных глав по безопасности:)
Глава 9. Построение безопасных и удобных для пользователей систем. Здесь рассматриваются варианты проектирования безопасности так, чтобы она приводила в итоге к продукту, которым нельзя пользоваться, т.к. средства безопасности рушат весь user experience
Глава 10. Инспекция кода в интересах безопасности. Здесь рассматриваются варианты code review причем с точки зрения того, как их использовать правильно, чтобы повысить безопасность конечного решения
Глава 11. Гибкое тестирование в безопасности. Здесь речь о том, как тестировать код, инфраструктур и CI/CD пайплайн в интересах обеспечния безопасности. Авторы упоминают несколько инструментов, которые могут быть полезны практикующим специалистам
Глава 12. Внешние инспекции, тестирование и рекомендации. Лучше всего про содержание этой главы говорит следующая фраза, завершающая главу: "Если вы не собираетесь использовать внешние инспекции, чтобы учиться у экспертов, то только зря тратите их время и свои деньги"
Глава 13. Эксплуатация и безопасность. Здесь рассматриваются вопросы мониторинга и обнаружения вторжений, реакций на инциденты, защиты CI/CD пайплайно и работы с секретами:)
Глава 14. Сообщение нормативным требованиям. Здесь расматриваются 2 подхода:
1. Подход на основе правил (Пример: PCI DSS)
2. Подход на основе результатов (Пример Reg SCI)
Эту главу полезно прочитать, чтобы понять разницу в этих подходах, а заодно ознакомиться с человеческим описанием того, что за правилы описаны в PCI DSS, которые часто поминауются всуе по поводу и без:)
Глава 15. Культура безопасности. Очень хорошо про культуру. Замечательно про "тяни, а не толкай" и принципы эффективности:
1. Содействуй, а не блокируй;
2. Прозрачная безопасность;
3. Не ищите виноватых;
4. Масштабировать безопасность, усиливать фланги;
5. Кто - не менее важно, чем как
Глава 16. Что такое гибкая безопасность. Здесь каждый из 4-х авторов книги рассказывает свою историю и делится тем, как пришел к вопросам безопасности в разработке и кристализует свои мысли относительно темы книги

#Sec #Security #Agile #Processes #Software #SoftwareDevelopment #DevSecOps

The Developer's Playbook for LLM Security (Рубрика #Books)

Прочитал эту книгу за авторством Steve Wilson, который был руководителем проекта "OWASP Top 10 for LLM Applications". Брался за нее с вопросом, насколько книга 2024 года про безопасность больших языковых моделей еще актуальна в 2026-м. Ответ такой: как базовая инженерная рамка - да, очень. Как полный обзор текущей повестки - уже нет, потому что область за два года заметно уехала вперед.

Книга ценна тем, что она не пытается объяснять безопасность LLM как набор страшилок про промпт инъекции”, а показывает более широкую картину: где проходят границы доверия, почему приложение с языковой моделью нельзя воспринимать как обычное приложение, как появляются утечки данных, что делать с галлюцинациями, обработкой ответа, цепочкой поставки, паспортами моделей, SBOM/ML-BOM, защитными ограничениями, проверками атакующими сценариями и эксплуатацией LLM-систем.

Основные моменты из книги следующие

1️⃣ LLM - это не просто модель, а компонент программной системы. У него есть пользователи, контекст, данные, внешние источники, инструменты, среда выполнения, журналы, лимиты, права доступа и последствия действий. Поэтому безопасность нельзя повесить на один фильтр запросов перед моделью.

2️⃣ Промпт инъекции важны, но это не все. Ведь модель имеет доступ к внутренним сервисам, документам, базе знаний или инструментам, риск не в самом тексте, а в том, что он может сдвинуть поведение системы за границу допустимого.

3️⃣ Цепочка поставки в AI становится сложнее обычной цепочки поставки ПО. Кроме библиотек и контейнеров появляются модели, обучающие данные, векторные представления, подключаемые инструменты, шаблоны запросов, наборы для оценки качества и внешние провайдеры. Все это нужно описывать, версионировать, проверять и наблюдать в работе.

4️⃣ Важно выстроить безопасные процессы, а не просто реагировать на инциденты. Книга хорошо подводит к мысли, что безопасность LLM должна жить внутри разработки и эксплуатации: моделирование угроз, тесты, проверки атакующими сценариями, защитные ограничения, централизованные журналы, наблюдение, реакция на инциденты и регулярная переоценка рисков.

Но в 2026 году книгу уже нельзя читать как исчерпывающий справочник. В 2024-м центр тяжести был вокруг чат-ботов, RAG-приложений и LLM как нового класса прикладной безопасности. Сейчас повестка заметно сместилась к агентам: вызов инструментов, автономные рабочие процессы, MCP, память, идентичность, злоупотребление правами, межагентные взаимодействия, наблюдаемость в работе и возможность остановить или откатить действия.

OWASP это тоже отражает: помимо LLM Top 10 уже появились материалы по агентным приложениям и MCP Top 10. Чем больше агент может делать во внешнем мире, тем меньше безопасность похожа на “проверим ответ модели” и тем больше похожа на архитектуру доверия: кто дал цель, какие инструменты доступны, какие права выданы, что агент помнит, что пишется в журналы, кто подтверждает опасные действия и где находится аварийная остановка.

Поэтому моя оценка такая: книгу стоит читать как хороший фундамент для инженеров, архитекторов, специалистов по безопасности приложений, техлидов и руководителей, которые запускают LLM-фичи в промышленную эксплуатацию. Она помогает поставить голову на место и перестать думать, что безопасность AI - это отдельный магический слой вокруг модели.

#Books #AI #Security #LLM #Architecture #Engineering #DevSecOps

Can LLMs generate Enterprise Quality Code? Или почему pass rate уже мало (Рубрика #AI4SDLC)

LLM может пройти тесты и все равно написать код, который enterprise-команда потом будет долго разгребать. Именно об этом доклад Prasenjit Sarkar из Sonar: "Can LLMs generate Enterprise Quality Code?". Главная мысль простая, но неприятная: pass rate больше не достаточен. HumanEval, MBPP и SWE-bench хорошо отвечают на вопрос “работает ли решение в тесте?”, но гораздо хуже отвечают на вопрос “можно ли это безопасно втащить в большую кодовую базу?”.

В enterprise важно не просто реализовать функциональные требования и выдать рабочий код - важны вопросы безопасности, надежности, maintainability, когнитивной сложности, архитектурной связности, объема технического долга и кучи других нефункциональных требований. Но обычно мы смотрим в бенчах на то, как модель может сгенерировать корректный код, но не смотрим а не добавит ли она уязвимость, раздует метод, ухудшит читаемость или сломает принятые в репозитории правила. Поэтому Sonar продвигает идею Agent-Centric Development Cycle (AC/DC): Guide -> Generate -> Verify -> Solve. То есть AI-агента сначала нужно направить контекстом и стандартами проекта, потом дать ему сгенерировать код, затем независимо проверить результат и только после этого исправлять найденные проблемы.

Важная деталь: Generate делает coding agent, а ценность Sonar здесь в независимом слое Guide, Verify и Solve. Это не про “заменить разработчика”, а про то, чтобы встроить AI-код в управляемый инженерный контур. Интересная часть - их `LLM Leaderboard for Code Quality & Security. Это не просто таблица “какая модель решила больше задач”. Pipeline такой: модель генерирует код, код компилируется и гоняется на тестах, потом SonarQube анализирует bugs, vulnerabilities, code smells и complexity. Для Java сейчас указано примерно ~3,900` задач ComplexCodeEval, ~400 MBPP и ~160 HumanEval. При этом correctness через pass@1 считается только для HumanEval и MBPP, а остальные benchmark-и участвуют в метриках качества: complexity, security, reliability и maintainability.

Вот это, кажется, правильная рамка для engineering leaders: AI-код надо принимать через verification loop. Чем быстрее агенты пишут код, тем строже должна быть система, которая проверяет не только “прошли ли тесты”, но и “не и не наработали ли мы себе на будущий инцидент”.

#AI #AI4SDLC #Engineering #Architecture #DevSecOps #Software #Agents

[1/2] GitLab Act 2: зачем GitLab перестраивает разработку под агентов (Рубрика #AI4SDLC)

Разбирался с GitLab Act 2. Формально это письмо CEO про новый этап компании: фокус, реструктуризацию, AI и DevSecOps. Но важнее другое: GitLab описывает не набор AI-фичей, а смену производственной модели разработки. Если коротко, GitLab больше не хочет быть DevSecOps-платформой, к которой прикрутили AI. Он хочет стать control plane для SDLC, где работают не только люди, но и агенты.

В этом документе видно несколько продуктовых сдвигов

1️⃣ Git и платформа должны выдерживать нагрузку от машин
Если агенты параллельно открывают MR (merge request), запускают пайплайны и возвращаются с правками быстрее любой человеческой команды, инфраструктура разработки становится бутылочным горлышком. Поэтому GitLab говорит не только про AI-помощника, а про API-first сервисы и Git под машинные нагрузки.

2️⃣ Нужна оркестрация всего жизненного цикла
Агент, который написал код, сам по себе не решает enterprise-задачу. Нужно связать issue, код, review, безопасность, CI/CD, развертывание, инциденты, approvals и политики. Иначе получится много быстрых действий, но не управляемая поставка изменений.

3️⃣ Главным активом становится контекст
Кодогенерация быстро становится commodity: хорошие модели будут у всех. Разница будет в том, какой контекст получает агент: задачи, архитектура, история MR, уязвимости, ownership, deploy-история, инциденты, решения прошлых команд. GitLab называет это connected data model across the lifecycle, что является графом инженерного контекста.

4️⃣ Governance должен быть встроен в ядро, а не добавлен сбоку
В агентной разработке скорость без аудита, identity, политик и контролей развертывания быстро превращается в риск. Нужно понимать, кто или что изменило код, по каким правилам, с какими правами и где человек обязан остаться в контуре.

5️⃣ GitLab честно описывает гибридный режим
Не "завтра все автономно", а сосуществование работы людей, агентов-ассистентов и автономных агентов. Это достаточно трезвая картина: большие компании будут двигаться к агентности не одним прыжком, а через слои контроля и доверия.


Организационная часть здесь не менее важна, чем продуктовая. GitLab делает более плоским менеджмент, говорит примерно о 60 автономных R&D-командах, требует ежедневного использования AI и меняет старый ценностный фреймворк CREDIT (Collaboration, Results, Efficiency, Diversity & Inclusion, Iteration, and Transparency) на Speed with Quality, Ownership Mindset и Customer Outcomes. В отчете от 2 июня 2026 компания также описала реструктуризацию: сокращение примерно 14% штата, около 350 человек, выход из 22 стран и уменьшение footprint примерно на 37%. Кажется, что это попытка перестроить саму компанию под новую скорость разработки.

Для меня важно не только то, что GitLab говорит про агентов. Важно, что он связывает их с Git, CI/CD, governance, моделями данных, прайсингом и организационной структурой. Это уже не инструмент продуктивности для разработчика, а новая производственная система для разработки софта. В следующей части посмотрим, насколько GitLab тут одинок. Спойлер: почти не одинок. GitHub, Atlassian, Cursor, JetBrains и OpenAI/Codex идут в ту же сторону, но каждый заходит со своей точки силы.

#AI #AI4SDLC #Engineering #DevSecOps #Management #Architecture #DevOps #PlatformEngineering #Agents #DevEx #Strategy

[2/2] GitLab Act 2: насколько это совпадает с GitHub, Atlassian и агентными IDE (Рубрика #AI4SDLC)

В прошлой части я разбирал GitLab Act 2 как попытку перестроить DevSecOps-платформу под агентную разработку: отмасштабировать Git под машинное использование, реализовать оркестрацию всего жизненного цикла, собрать контекстный граф, встроить governance и реализовать гибридную модель работы human/agent/autonomous. А в этом посте я хотел сравнить это с тем, что делают другие платформы и насколько совпадает курс.

TLDR;
Курс совпадает сильно, но разница в том, из какой точки каждый игрок пытается стать control plane для агентной разработки.

Ну а дальше давайте посмотрим на остальных игроков

1️⃣ GitHub
GitHub идет очень близко, но с другой оптикой. Copilot coding agent уже работает как асинхронный участник GitHub flow: ему можно назначить issue, он работает в среде на базе GitHub Actions, пушит коммиты в draft PR, а человек ревьюит результат. А Agent HQ прямо описывает GitHub как mission control для разных агентов: Copilot, OpenAI Codex, Claude, Google, Cognition и других. Ставка GitHub - оставить привычные primitives: issues, pull requests, Actions, branch protections, audit, но сделать агентов native внутри процесса. Подробнее я разбирал в отдельной статье в своем блоге tellmeabout.tech

2️⃣ Atlassian
Atlassian смотрит на ту же задачу через workflow и корпоративный контекст. Rovo Dev живет рядом с Jira, Confluence, Bitbucket и GitHub, а сильная сторона Atlassian - Teamwork Graph: связь задач, требований, документации, командного знания и кода. Если GitHub говорит "агенты внутри репозитория и PR", Atlassian - "агенты внутри потока работы компании". Подробнее я разбирал в отдельной статье в своем блоге tellmeabout.tech

3️⃣ Cursor и JetBrains сильнее играют в IDE-first модель
Cursor делает ставку на background agents и удаленные среды, где агент работает в отдельной ветке. Junie от JetBrains встроен в IDE и опирается на привычную среду разработки, инспекции, тесты и контекст проекта. Их поле боя - developer experience: где инженер читает код, смотрит diff и принимает решение.

4️⃣ OpenAI/Codex и Devin-подобные агенты идут еще более agent-first путем
Там главным интерфейсом становится не репозиторий, Jira или IDE, а сам агент как рабочая единица: получил задачу, поднял среду, изменил код, проверил, вернул PR.

В общем, видно, что все основные игроки видят тренды и пытаются ухватить их за хвост, но каждый по своему. Вот GitLab связывает агентность не только с coding assistant, а с Git, CI/CD, governance, data model, pricing и оргструктурой. И в этой модели мы видим как роль инженера смещается. Меньше ценности в том, чтобы руками выполнить каждое действие. Больше - в том, чтобы поставить intent, собрать контекст, определить ограничения, построить проверку, принять архитектурное решение и удержать качество при большей скорости изменений.

Ну и идет большая борьба за тем, кто займет нишу control plane.
- У GitHub - игра вокруг PR и репозитория.
- У Atlassian - игра вокруг задач и организационного знания.
- У Cursor и JetBrains - игра вокруг IDE.
- У OpenAI/Codex - игра вокруг агента как нового рабочего интерфейса.

А GitLab пытается занять самое широкое место: control plane для всего software lifecycle в enterprise. Ставка сильная, но риск тоже большой. В агентной разработке главный вопрос в том, а выдержит ли ваша инженерная система скорость, которую создают агенты?

#AI #AI4SDLC #Engineering #DevSecOps #Management #Architecture

IDP is Dead? Нет, умирает монополия GUI (Рубрика #PlatformEngineering)

Написал тут эссе на тему того, как AI не просто меняет интерфейс платформенных продуктов, а саму их природу … и что с этим делать платформенным командам. Я много думал в последнее время на эту тему, а заодно разбирал кейсы Gitlab, Github, Atlassian

Само название статьи навеяно плеядой текстов с главным тезисом «SaaS is Dead», которые представляют провокационные эссе о том, что классический софт с кнопками и формами доживает последние годы, потому что человек перестаёт быть основным пользователем интерфейса. Этот текст — про то же самое, но развёрнутый туда, куда смотрят редко: внутрь компании, на внутренние инженерные платформы. На IDP (internal developer platform) во всей её полноте — IaaS, Managed Services и всё остальное направление платформенных сервисов для инженеров.

Основной тезис статьи прост: внутренняя платформа в том виде, в каком мы привыкли её строить — как продукт со своим GUI, своими сценариями и своим продакт-менеджером, который драйвит роадмап, — переживает ровно тот же перелом, что и внешний SaaS. И большинство платформенных команд этого пока не замечают, потому что заняты не тем.

В статье я попробовал ответить на вопросы куда движутся платформы разработки, почему и что со всем этим делать. Подробнее можно прочитать в моем блоге

#AI #AI4SDLC #Engineering #DevSecOps #Management #Architecture

Евгений Кокуйкин про AI Security - AI Dev Podcast (Рубрика #AI4SDLC)

Посмотрел подкаст с AI Dev Conf, в котором участвовали Евгений Кокуйкин, Андрей Дмитриев и я. Мы поговорили о том, что происходит с безопасностью разработки, когда у нас кодяру начинают писать не только люди, но и агенты с разными инструментами, доступами и правами на изменения. Если говорить про гостя, то Евгений Кокуйкин - это CEO HiveTrace, со-основатель Raft, руководитель AI Security Lab в ИТМО и участник OWASP Agentic Security. То есть это точка зрения практика AppSec/AI security, который видит и технологию, и поверхность атаки.

Главная мысль выпуска крутится вокруг того, что в агентной разработке безопасность становится частью архитектуры процесса: кто действует, от чьего имени, какие права получает, что логируется, где нужен approval и как быстро можно откатиться. Наше общение можно разделить на отдельные блоки

1️⃣ Почему coding agents вообще так быстро продвинулись
В обычных GenAI-приложениях трудно понять, насколько ответ хорош: пользователь поставил палец вверх или вниз, но это слабая обратная связь. В разработке иначе. У нас уже есть компиляторы, линтеры, тесты, git-история, баг-трекеры, CI/CD и код-ревью. Можно взять старый баг, восстановить состояние репозитория, дать агенту задачу и проверить решение теми же тестами. SDLC уже содержит заготовку для evals. Отсюда растёт автономность. Агент может решить задачу, получить обратную связь от тестов, перезапустить попытку, передать изменения на ревью. Для внешнего клиента режим "попробуйте ещё раз" выглядел бы странно, а внутри разработки retry, тесты и ревью становятся нормальной частью контура.

Но дальше начинается неприятная часть. Если агент становится участником SDLC, его нельзя воспринимать как безобидную подсказку в IDE. Он похож на внутреннего сотрудника или сервисный аккаунт: identity, доступы, токены, возможность читать репозитории, дергать API, смотреть логи, иногда деплоить или помогать с инцидентами. Проблема service accounts и раньше была болезненной, но агентная разработка умножает её на порядок.

Часто разговоры про AI security быстро уезжают в область prompt injection, jailbreaks и красивых атак на модель. Но во многих реальных сценариях ломается более скучный слой: права доступа, секреты, supply chain, разделение dev/stage/prod, аудит действий и зависимости. Евгений приводил примеры из мира coding assistants, MCP-серверов, Postmark, LiteLLM и других supply-chain историй. Паттерн здесь прост: если агент или его инструмент подтянул заражённую зависимость, обычные unit tests могут ничего не заметить.

2️⃣ Экономика и метрики
Бизнесу легко пообещать "заменим половину разработки агентами", но реальность сложнее. Нужно считать не только токены и GPU, но и платформу: gateway, routing между моделями, sandboxing, аутентификацию, авторизацию, квоты, наблюдаемость. А бенефит нельзя сводить к количеству AI-кода: интереснее смотреть на конкретные job'ы внутри SDLC - миграции, багфиксы, ревью, тесты, инциденты, повторяемые изменения.

3️⃣ Надёжность
Если SRE-агент в 2 часа ночи может собрать анамнез инцидента, это полезно. Если он может сам перезапускать сервисы, менять конфигурацию или выполнять план восстановления, это уже другой класс риска. Если каждое опасное действие агента уезжает на senior approval, узкое место просто переехало к самым загруженным людям. Значит, нужны более тонкие политики риска: что агент может делать сам, где нужен второй контур проверки, где требуется изоляция среды, а где действие запрещено всегда.

4️⃣ Ответственность
Мы обсуждали агента почти как классическую пару принципала и агента (из теории управления): человек или компания задаёт цель, агент действует от их имени, а дальше появляются misalignment, побочные действия и вопрос "кто отвечает?". Эта логика из менеджмента теперь просачивается в технический контур одного инженера и его агентов.

Для инженеров главный вывод такой: AI security в SDLC - это не отдельная "галочка ИБ", а проектирование производственной системы. Нужны evals, threat modeling, least privilege, sandboxing, разделение сред, audit trail, model routing, контроль секретов, политика для non-human identities и наблюдаемость агентных действий.

И ещё более практично: если в компании появляются кодинговые агенты, то не стоит начинать с вопроса "какую модель выбрать", а с карты прав и последствий. Что агент читает? Что пишет? Какие инструменты вызывает? Может ли он достать данные? Может ли деплоить? Кто увидит его действия? Как остановить, откатить и расследовать результат? Без этих вопросов "ускорение разработки" очень легко превращается в ускорение риска.

#AI #AI4SDLC #Security #Engineering #Architecture #DevSecOps #Agents

GitLab AI Accountability Report: код уже генерируют быстрее, чем умеют контролировать (Рубрика #AI4SDLC)

Разбирался с GitLab 2026 AI Accountability Report, который компания выпустила 23 июня 2026 года. Этот отчет хорошо продолжает линию GitLab Act 2, DORA ROI и недавнего Stack Overflow Pulse Survey: AI уже ускорил генерацию кода, но узкое место переехало в контроль, проверку и ответственность.

Исследование провел The Harris Poll для GitLab: 1 528 разработчиков и закупщиков в шести странах. Это важно читать как вендорский опрос, а не как независимый отчет, но результаты получились интересными: по данным GitLab, 91% организаций уже используют два или больше AI coding tools, 78% говорят, что разработчики стали быстрее писать и коммитить код, 60% считают ROI выше ожиданий. Если читать только эти числа, то видим оптимистичный взгляд на внедрение ... но ребята из GitLab приготовили нам AI парадокс: 79% респондентов согласны, что индивидуальная продуктивность разработчиков выросла, но общий процесс поставки софта ускорился не так уж сильно. То есть локальная скорость генерации не равна скорости поставки изменений. Код появляется быстрее, а очередь переезжает в review, валидацию, безопасность, комплаенс, развертывание и поддержку. Тут есть пара красивых цифр
1️⃣ 85% согласны, что AI сдвинул бутылочное горлышко от написания кода к его ревью и валидации.
2️⃣ 84% считают, что самая большая проблема с AI-генерированным кодом - не создание, а управление тем, что происходит с ним после генерации.

Это почти идеальная формулировка взрослого AI4SDLC - может ли инженерная система ответить на три вопроса про любую строку сгенерированного AI кода:
1) Откуда она взялась
2) Что должна была сделать
3) Кто отвечает за нее в production
Именно так GitLab определяет AI accountability

И тут у нас появляется разрыв между теорией и практикой (почти как в анекдоте про миллионеров). По данным GitLab, 87% уверены, что команда за 24 часа определит, участвовал ли код, сгенерированный AI, в прод инциденте. Но среди организаций, у которых за последний год уже был инцидент, 34% не смогли этого сделать. Причины выглядят примерно так
- 43% не могут надежно отличить AI-сгенерированный код от кода, написанного людьмы, в своей кодовой базе
- 40% упираются в фрагментированные инструменты;
- 39% работают с системами, которые не отслеживают происхождение кода;
только 28% говорят, что их SDLC-инструменты полностью интегрированы через общие данные и рабочие процессы.

Блок про governance тоже показательный. GitLab пишет, что 92% сталкиваются с какими-то governance challenges вокруг AI-кода, а 80% согласны: организация внедрила AI инструменты быстрее, чем разработала политики управления ими. 83% уже считают накопление AI-кода риском, которым нужно управлять сейчас; 44% называют это топовым технологическим риском.

Практически я бы забирал из отчета не вывод "купите governance tools" (хотя GitLab был бы не против такого вывода). Скорее важно спросить себя
- А можем ли мы для AI-сгенерированного изменения восстановить задачу, контекст, инструмент, автора/оператора, diff, review, тесты, security checks, approval, релиз, владельца сервиса и последствия в production?
- Если не можем, то скорость генерации уже стала обязательством, которое в моменте может как повышение продуктивности инженеров, а через полгода станет техническим долгом.

P.S.
Разбор исследования GitlLab есть на нашем сайте ai4sdlc-research.space, где вскоре мы заново запустим наше исследование AI4SDLC на этот раз про проникновение агентов в процессы разработки.

#AI #AI4SDLC #Engineering #DevSecOps #Management #Governance #Agents

Sonar и звёздный час верификаторов (Рубрика #AI4SDLC)

Sonar как продукт существует уже почти двадцать лет и всё это время пользовался популярностью в своей нише: статический анализ, quality gates, поиск багов, уязвимостей и code smells. Но теперь у компании началась настоящая пруха. Агенты генерируют код как не в себя - для всех и сразу. Контролировать его качество вручную становится всё сложнее. И тут на сцену выходит Sonar со своими детерминированными правилами. И не только с ними. И вот я посмотрел выступление Тарика Шауката, CEO Sonar, на "AI Engineer World’s Fair", в котором Тарик как раз про это и рассказывал.

Модели способны решать всё более длинные задачи, но надёжность отстаёт. В приведённых Шаукатом данных METR 16–20 часов человеческой работы - это горизонт при 50% вероятности успеха агента. При 80% он сокращается до 3-4 часов. Один из CTO клиентов Sonar заметил: сотрудник с точностью 80% уже оказался бы на performance review. Ещё неприятнее, что функционально правильный код может остаться сложным, уязвимым и дорогим в сопровождении. Краткосрочный рост скорости начинает съедаться ревью и техдолгом.

Ответ Sonar - Agent Centric Development Cycle, или AC/DC (про эту аббревиатуру от Sonar я уже рассказывал, когда говорил о другом их докладе примерно на эту же тему):
- Guide - дать агенту контекст, архитектурные ограничения и quality profile.
- Generate - агент пишет код.
- Verify - детерминированный анализ проверяет потоки данных, секреты и известные паттерны, а агентная проверка — намерение и бизнес-логику.
- Solve - найденные проблемы возвращаются агенту, он исправляет код и запускает цикл заново.

Проверка при этом должна жить не только в CI перед merge. Шаукат говорит о трёх связанных контурах: внутреннем цикле агента, CI verification и постоянном обслуживании кодовой базы. И здесь есть важный поворот: чистый код теперь нужен не только людям. Агенту проще в нём ориентироваться, он тратит меньше токенов и реже ошибается. Правда, цифры Sonar про снижение дефектов и расхода токенов пока остаются данными самого вендора.

Для меня главный вывод в том, что старый добрый статический анализ внезапно становится не наследием прошлого, а инфраструктурой будущего.

#AI #AI4SDLC #Agents #Engineering #DevSecOps #Software

SonarQube Cloud: зачем агентному коду детерминированный внешний контроль (Рубрика #AI4SDLC)

После поста "Sonar и звёздный час верификаторов" решил разобраться, а что именно SonarQube Cloud проверяет в коде, написанном агентами, а также почему это не еще один линтер, а что-то большее, например, гейт между тем, что «агент закончил» и «изменение можно влить».

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

- SonarQube - анализ и quality gates: Cloud работает в CI/CD, Server - в своем контуре, бесплатный SonarQube for IDE - во время написания кода.
- Gitar - AI-ревьюер pull request: разбирает сбои CI, предлагает и применяет исправления. Практически это экономия внимания на рутинном PR-ревью.
- Sonar Vortex - подает агенту контекст и правила через plugin, CLI или MCP и проверяет код во время генерации. Ошибки можно поймать до CI.
- Remediation Agent - исправляет issues из PR или backlog и открывает проверенный PR. Это автоматизация технического долга.
- Advanced Security - SCA: CVE, вредоносные зависимости, SBOM и лицензии. Это слой безопасности цепочки поставки.

Почему проверки в основном детерминированные? Проверяющий слой должен работать как турникет, а не как второй собеседник. При одинаковых исходниках, версии анализатора, профиле правил и отчетах результат повторяется. Это дает контракт для человека и coding agent, короткий цикл исправления и аудит: видно правило, строку и причину отказа.

Детерминированность не означает примитивность или точность. Анализатор строит модели потоков данных и путей исполнения, но они остаются приближением. Возможны ложные срабатывания и пропуски. Security Hotspots Sonar оставляет человеку: инструмент показывает чувствительное место, инженер оценивает контекст.

Зеленый Quality Gate не доказывает правильность бизнес-логики или архитектуры. Я бы разделял роли так: тесты проверяют ожидаемое поведение, Sonar - известные дефектные конструкции, человек - намерение и инженерные компромиссы.

Для меня главный вывод: чем дешевле генерация кода, тем важнее вынести критерии его приема из головы агента во внешний воспроизводимый контур. И защитить настройки, чтобы агент не мог «починить» красный gate снижением порога или исключением директории.

P.S.
Изучу еще CodeScene и дальше для своих пет проектов выберу один из этих продуктов и попробую на практике, потом поделюсь своими мыслями о том, а как они работают (благо сейчас я кода с агентами много пишу).

#AI4SDLC #AI #Agents #Engineering #DevSecOps #Evals

Инцидент OpenAI и Hugging Face: когда агент вылез из sandbox и выпустил других агентов (Рубрика #AI4SDLC)

Посмотрел огненный доклад Эрика Уоллеса и Майкла Далтона из OpenAI на Black Hat USA 2026 про инцидент с Hugging Face. Смотрел как смесь остросюжетного боевика и рассказа о том, а кто же все-таки убил садовника:)

TLDR выглядит примерно так

1️⃣ OpenAI тестировала внутренние модели на ExploitGym - заданиях по поиску и эксплуатации уязвимостей. Некоторые задания оказались практически невыполнимыми, и агенты начали искать способ добыть готовые ответы. Прямого доступа к интернету у них не было, зато был доступ к общему Artifactory: прокси для реестров пакетов, который сам ходил наружу и разрешал запись.
2️⃣ Один агент оставил там сообщение другим. Следующие запуски его нашли, начали обмениваться находками, эксплойтами и заданиями. Когда инженеры очистили эту «доску сообщений», агенты восстановили её через имена директорий. Получилась незапланированная память между изолированными на бумаге запусками.
3️⃣ Дальше локальный обход превратился в настоящую цепочку атак. По данным OpenAI и Hugging Face, агенты использовали уязвимости Artifactory, вышли в интернет, а затем через две уязвимости в обработке датасетов Hugging Face получили чтение файлов и выполнение кода. В крутом техническом отчёте Hugging Face восстановлено около 17 600 действий агента за кампанию с 9 по 13 июля 2026 года (рекомендую его внимательно изучить - он того стоит)
4️⃣ Важно, что OpenAI описывает цель агента как очень узкую: найти решения ExploitGym и «сдать» тест. Но оптимизация этой цели, большой вычислительный бюджет и общий канал связи превратили локально разумные шаги в атаку на внешнюю систему.

Практический вывод: eval-среду для сильного агента нужно проектировать как враждебную multi-tenant систему. Отдельные identity и хранилище на каждый запуск, короткоживущие scoped credentials, запрет исходящего трафика на каждом переходе, наблюдаемость сразу по всему рою и автоматический circuit breaker при выходе за ожидаемый профиль. Хороший sandbox - не контейнер, в котором запущена модель. Это полная граница её прав, сети, состояния, данных и последствий.

Кстати, кажется, что у OpenAI все было настроено хорошо, но агенты оказались чудо как хороши в коллаборации своих усилий, поисках отдельных уязвимостей, а также в связывании их в цепочки атак. Поэтому авторы доклада призывают усилить работу над защитой нашего софта, так как сторона нападения кажется сильно прокачалась с появлением агентов.

P.S.
Кстати прокачивать защиту процессов разработки и сам софт достаточно сложно, так как для защиты надо прикрыть все лазейки, а для атаки найти одну брешь. Плюс особенно сложно защищаться, когда агентная разработка внутри компаний частично блокируется с тезисами, что так будет безопаснее ... (нет не будет - это примерно как в мифе про страусов, которые вроде как прятали голову в песок, но если бы они действительно так делали, то они бы вымерли).

#AI #AI4SDLC #Agents #Security #DevSecOps #Architecture

Почему удачный POC (proof of concept) AI продукта ещё не готов к production (Рубрика #AI4SDLC)

Посмотрел новый доклад с конфы AI Engineer World’s Fair, который развивает тему FDE (Forward Deploy Engineer). В прошлый раз я разбирал FDE — инженера, который встраивается в команду клиента и доводит AI до работающего процесса. А новый доклад показывает следующий акт этой истории: POC уже работает, а production ещё даже не начинался.

Christopher Lovejoy из Anthropic и Saul Howard, VP Engineering в Anterior, начинают с условного сценария. Два инженера за четыре недели собирают агента для медицинского workflow. Accuracy хорошая, система быстрая и относительно дешёвая. На презентации все довольны: финансы считают бюджет, медицинский директор готов рассказывать коллегам о точности, а продажи уже хотят написать на сайте «Powered by AI».

На следующий день в комнате появляются другие вопросы. Где полный audit trail? Как перемещаются медицинские данные? Кто подтверждает спорное решение? Может ли недоверенный документ управлять моделью? Как проверять качество после релиза? И красивый POC останавливается: он оптимизирован под правильный ответ, но не под доказуемость каждого действия.

Спикеры предлагают поменять порядок: сначала сделать production-ограничения несущей конструкцией, а уже потом возвращать точность прототипа. Для этого нужны три примитива:

1️⃣ Append-only журнал событий — единая история действий, доступов и авторизаций. Он помогает воспроизводить состояние и строить аудит, но у компромисса есть цена: записывать легко, читать сложнее, нужны projections и snapshots;
2️⃣ Schema-driven object storage для самих медицинских данных. В журнале остаются ссылки, доступ выдаётся в момент использования, а инженер может отлаживать путь агента, не видя PHI;
3️⃣ Единый контракт действий для LLM и человека. Любой шаг можно передать человеку посреди workflow, а общий контекст отобразить либо как prompt, либо как UI. Речь об одинаковом интерфейсе, а не об одинаковых полномочиях.

Из этой основы, по мнению авторов, получаются и evals: можно повторно проигрывать тот же эпизод с другим prompt, моделью или кодом, сравнивать действие агента с человеческим и запускать проверку на production data внутри контура клиента. И мне здесь нравится именно порядок мышления. Если audit, границы данных и human approval появляются в плане «после успешного POC», архитектура уже опоздала. В регулируемой системе это не ворота перед релизом, а сама модель данных и исполнения.

#AI4SDLC #AI #Agents #Architecture #DevSecOps #Evals #Engineering