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