DevSecOps Talks
الذهاب إلى القناة على Telegram
Рассказываем об актуальном в мире DevSecOps. Канал DevSecOps-команды "Инфосистемы Джет"
إظهار المزيد8 047
المشتركون
+224 ساعات
+47 أيام
+3330 أيام
جاري تحميل البيانات...
القنوات المماثلة
سحابة العلامات
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
أكتوبر '26أكتوبر '26
أكتوبر '26
+16
في 1 قنوات
سبتمبر '26
+107
في 2 قنوات
Get PRO
أغسطس '26
+116
في 5 قنوات
Get PRO
يوليو '26
+121
في 1 قنوات
Get PRO
يونيو '26
+203
في 2 قنوات
Get PRO
مايو '26
+118
في 1 قنوات
Get PRO
أبريل '26
+108
في 3 قنوات
Get PRO
مارس '26
+166
في 5 قنوات
Get PRO
فبراير '26
+142
في 3 قنوات
Get PRO
يناير '26
+109
في 3 قنوات
Get PRO
ديسمبر '25
+76
في 2 قنوات
Get PRO
نوفمبر '25
+118
في 1 قنوات
Get PRO
أكتوبر '25
+115
في 3 قنوات
Get PRO
سبتمبر '25
+80
في 2 قنوات
Get PRO
أغسطس '25
+131
في 2 قنوات
Get PRO
يوليو '25
+139
في 4 قنوات
Get PRO
يونيو '25
+108
في 1 قنوات
Get PRO
مايو '25
+106
في 1 قنوات
Get PRO
أبريل '25
+135
في 1 قنوات
Get PRO
مارس '25
+136
في 2 قنوات
Get PRO
فبراير '25
+197
في 4 قنوات
Get PRO
يناير '25
+156
في 3 قنوات
Get PRO
ديسمبر '24
+101
في 2 قنوات
Get PRO
نوفمبر '24
+134
في 1 قنوات
Get PRO
أكتوبر '24
+133
في 3 قنوات
Get PRO
سبتمبر '24
+150
في 1 قنوات
Get PRO
أغسطس '24
+157
في 1 قنوات
Get PRO
يوليو '24
+119
في 1 قنوات
Get PRO
يونيو '24
+84
في 1 قنوات
Get PRO
مايو '24
+209
في 2 قنوات
Get PRO
أبريل '24
+120
في 4 قنوات
Get PRO
مارس '24
+127
في 3 قنوات
Get PRO
فبراير '24
+693
في 10 قنوات
Get PRO
يناير '24
+1 087
في 8 قنوات
Get PRO
ديسمبر '23
+1 119
في 9 قنوات
Get PRO
نوفمبر '23
+648
في 3 قنوات
Get PRO
أكتوبر '23
+79
في 2 قنوات
Get PRO
سبتمبر '23
+97
في 0 قنوات
Get PRO
أغسطس '23
+158
في 0 قنوات
Get PRO
يوليو '23
+79
في 0 قنوات
Get PRO
يونيو '23
+72
في 0 قنوات
Get PRO
مايو '23
+136
في 0 قنوات
Get PRO
أبريل '23
+90
في 0 قنوات
Get PRO
مارس '23
+128
في 0 قنوات
Get PRO
فبراير '23
+44
في 0 قنوات
Get PRO
يناير '23
+65
في 0 قنوات
Get PRO
ديسمبر '22
+72
في 0 قنوات
Get PRO
نوفمبر '22
+95
في 0 قنوات
Get PRO
أكتوبر '22
+55
في 0 قنوات
Get PRO
سبتمبر '22
+68
في 0 قنوات
Get PRO
أغسطس '22
+171
في 0 قنوات
Get PRO
يوليو '22
+61
في 0 قنوات
Get PRO
يونيو '22
+39
في 0 قنوات
Get PRO
مايو '22
+98
في 0 قنوات
Get PRO
أبريل '22
+96
في 0 قنوات
Get PRO
مارس '22
+118
في 0 قنوات
Get PRO
فبراير '22
+31
في 0 قنوات
Get PRO
يناير '22
+33
في 0 قنوات
Get PRO
ديسمبر '21
+127
في 0 قنوات
Get PRO
نوفمبر '21
+27
في 0 قنوات
Get PRO
أكتوبر '21
+28
في 0 قنوات
Get PRO
سبتمبر '21
+71
في 0 قنوات
Get PRO
أغسطس '21
+52
في 0 قنوات
Get PRO
يوليو '21
+70
في 0 قنوات
Get PRO
يونيو '21
+52
في 0 قنوات
Get PRO
مايو '21
+34
في 0 قنوات
Get PRO
أبريل '21
+31
في 0 قنوات
Get PRO
مارس '21
+33
في 0 قنوات
Get PRO
فبراير '21
+59
في 0 قنوات
Get PRO
يناير '21
+39
في 0 قنوات
Get PRO
ديسمبر '20
+549
في 0 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 06 أكتوبر | +5 | |||
| 05 أكتوبر | +2 | |||
| 04 أكتوبر | +5 | |||
| 03 أكتوبر | 0 | |||
| 02 أكتوبر | +2 | |||
| 01 أكتوبر | +2 |
منشورات القناة
Генерация подозрительных событий
Всем привет!
По ссылке можно найти репозиторий с утилитой, которая позволяет генерировать подозрительные события.
Цель проста – проверять то, насколько используемые средства защиты смогут их идентифицировать.
Репозиторий создан для Falco, но это не мешает использовать его и для других систем.
Глобально события делятся на:
🍭 Syscals. Изменений привилегий, создание файлов, запуск процессов, чтение данных и т.д.
🍭 Kubernetes. Создание привилегированных ролей, создание
pod с небезопасными mounts, создание ServiceAccount и т.д.
Можно запускать генерацию как для всех событий, так и для выбранного «набора».
Подробнее о возможностях утилиты можно прочесть в GitHub-репозитории.
Важно (!): event-generator рекомендуется запускать в изолированной среде, т.к. некоторые команды могут изменить настройки системы (например, изменение файлов в /bin, /etc, /dev и т.д.)| 2 | Удаление чувствительных данных из журналов событий
Всем привет!
Утечки конфиденциальных данных при разработке ПО не редкость. Данные могут попасть в исходные коды, конфигурационные файлы, сообщения commit и не только.
Не стоит забывать о том, что конфиденциальные данные могут быть разглашены и во время эксплуатации ПО.
Например, через журналы событий: либо так настроен уровень сбора данных, либо просто «забыли это поправить».
Чтобы удалить все «ненужные данные» можно воспользоваться PII-Shield. Эта утилита помогает решить проблему при работе с Kubernetes.
Работает достаточно просто: sidecar, который «перехватывает» stdout/stderr, анализирует записи на наличие чувствительных данных и удаляет их.
PII-Shield может найти секреты (API-ключи, сертификаты, логины/пароли), телефонные номера.
При необходимости можно добавлять собственные regex-правила.
Помимо поиска «по шаблонам» добавлена возможность идентификации чувствительных данных через анализ энтропии.
Подробнее об утилите (установка, настройка, интеграция с различными системами, описание возможностей) можно прочесть в GitHub-репозитории или на официальном сайте. | 1 009 |
| 3 | AI Coding Agent Security Benchmark
Всем привет!
Команда Endor Labs задалась вопросом насколько хорошо AI пишет безопасный код.
Для этого они провели анализ 13 агентов и моделей с использованием SusVibes Benchmark.
200 задач из 108 open-source проектов, написанных на Python. При этом измерялась не только безопасность, но и корректное (ожидаемое) функционирование результата.
Из ключевых результатов можно отметить:
🍭 Существует «разрыв» между корректным функционированием и безопасностью
🍭 Модели стали сильно лучше писать код с точки зрения работоспособности, но не безопасности
🍭 Агенты «жульничают» 😅 Да, бывало так, что они просто находили подходящее решение вместо reasoning
🍭 Одна и та же модель может вести себя по-разному при работе с разными агентами
🍭 Та модель, что лучше всех справляется с функциональной частью может быть не самой лучшей с точки зрения ИБ
И это далеко не всё, что есть в исследовании. Рассматривались следующие модели: Claude Sonnet, Kimi, Gemini, GPT.
Кто и в чём победил? Ответы есть в статье, как и множество деталей о проведённой работе.
Рекомендуем к ознакомлению!
P.S. Материал опубликован в апреле и уточнён в мае 2026 года. Это важно учитывать, ведь, увы, подобные исследования «устаревают» достаточно быстро.
Но! Это не делает их менее интересными ☺️ | 1 420 |
| 4 | Platform Skills
Всем привет!
По ссылке доступен GitHub-репозиторий, в котором можно найти внушительный набор skills для работы с элементами ИТ-инфраструктуры и безопасности.
Поддерживаются такие системы как: Kubernetes, Argo CD, Flux CD, Terraform, Kyverno, Trivy, Kingfisher и многие другие.
Для каждой из поддерживаемых систем определён набор skills и возможностей.
Например, можно создавать, тестировать и проводить аудит политик Kyverno. Или мигрировать их на новый CEL-синтаксис.
Запускать сканирования Trivy, осуществлять поиск проблем и их причин в кластере Kubernetes, создавать роли т.д.
Полный перечень доступных команд можно найти в файле COMMANDS.md.
Указанный набор skills доступен для GitHub Copilot, Claude Code, Codex, Cursor.
Больше информации о возможностях skills, их устройстве, запуске и результатах работы можно найти в GitHub-репозитории проекта. | 1 413 |
| 5 | Vaikora LLM Gateway
Всем привет!
С повсеместным использованием AI-агентов всё чаще встречается вопрос, связанный с информационной безопасностью.
Это породило создание отдельной группы инструментов, задача которых – контролировать происходящее.
Vaikora LLM Gateway является представителем этой группы.
Если просто, то он «находится» между AI-агентами и «конечными системами» (LLM, базы данных, MCP, API и т.д.).
Его задача состоит в перехвате каждого действия, которое хочет совершить агент и анализе его на соответствие определённому набору политик.
Каждому действию присваивается статус: ALLOW, ALLOW_LOG, CONSTRAIN или BLOCK.
На текущий момент Vaikora LLM Gateway работает со следующими LLM: OpenAI, Anthropic, Google Gemini и OpenRouter.
Политики позволяют обнаруживать разные активности: утечку конфиденциальной информации, jailbreak, prompt injection и не только.
Сам по себе «движок правил» является детерминированным и не использует нейронные сети, что позволяет получать идентичные результаты на одни и те же действия.
Подробнее о возможностях утилиты можно прочесть в GitHub-репозитории проекта. | 1 443 |
| 6 | Анализ зависимостей и инструментария разработки ПО
Всем привет!
Анализ ПО начинается не с запуска сканеров, а с понимания того, что это такое, как это устроено, как собирается, как тестируется и т.д.
Т.е. с некоторой метаинформации о проекте. Собирать её можно разными способами. Можно «в ручном режиме», а можно с использованием средств автоматизации.
Несколько полезных утилит, которые помогут решить задачу сделал Andrew Nesbitt (мы писали про его статью, посвященную модели угроз пакетных менеджеров).
Первая – brief – используется для получения информации об используемых языках, пакетных менеджерах, тестах, сборке, количестве строк и т.д.
Вторая – git-pkgs – позволяет анализировать используемые зависимости, в том числе по всей git-истории.
Основными её командами являются list, history, blame, diff и т.д. Они позволяют быстро получить ответ на вопрос «откуда эта зависимость появилась в проекте».
Обе утилиты ничего не «додумывают». Фактически, они собирают информацию, которую могут получить за счёт анализа репозитория.
Подробности, параметры установки/запуска и примеры содержания генерируемых отчётов можно найти в GitHub-репозиториях или в документации. | 1 463 |
| 7 |  Композиционный анализ C/C++ проектов
Всем привет!
Разрешить зависимости, сформировать SBoM, проанализировать его на наличие уязвимостей и обработать их в соответствии с процессами, принятыми в компании.
Казалось бы, всё просто! Но дьявол, как и всегда, кроется в деталях. Особенно для C/C++ проектов, где (как правило) нет удобного пакетного менеджера/перечня зависимостей, который может послужить отправной точкой для исследования.
Как быть в этом случае? Ответ можно найти в статье от CodeScoring!
Ребята рассматривают:
🍭 Как можно выяснить название и версию библиотеки, с какими нюансами можно столкнуться
🍭 Как определить те зависимости, которые попали в конечный артефакт/поставку
🍭 Почему для одного ПО может быть 2 разных SBoM
🍭 Где взять дополнительную информацию о библиотеке перед включением её в SBoM
🍭 Как связать найденные пакеты с уязвимостями, если PURL (не всегда) присутствует и не только
Каждый вопрос раскрывается достаточно подробно, с примерами и рекомендациями.
Помимо этого, рассматривается очень много различного рода нюансов, с которыми можно столкнуться при композиционном анализе C/C++ проектов.
Однозначно к прочтению! | 1 504 |
| 8 | Метрики масштабирования в Kubernetes
Всем привет!
(Автоматическое) масштабирование – крайне интересная тема. На первый взгляд она кажется достаточно простой. Но лишь на первый, пока не начнутся вопросы.
Масштабироваться реактивно? Проактивно? Как долго оставлять «неиспользуемые» ресурсы? Как контролировать масштабирование, чтобы оно не вышло из-под контроля?..
Автор статьи предлагает рассмотреть 5 метрик, которые могут помочь сделать процесс контролируемым.
Среди них:
🍭 Committed capacity percentage. То, насколько используются существующие мощности
🍭 Error rates. Что происходит в момент масштабирования?
🍭 Mean Time to First Byte (MTFB). Как много проходит времени с момента принятия решения о масштабировании до выполнения полезной работы сервисом, ресурсы которого масштабируются?
🍭 Application disruption. Влияет ли масштабирование на нарушение работоспособности запущенных приложений
🍭 Application churn. Что происходит, если средство масштабирования определяет потребность в 2,5 реплики, но такого быть не может?
По мнению Автора, отслеживание этих метрик может помочь оптимизировать процесс (автоматического) масштабирования.
Увы, статья детально не раскрывает каждую метрику в отдельности… Но! Автор собирается сделать это в отдельных статьях.
Помимо самих метрик в материале очень много интересных рассуждений на тему оптимального использования ресурсов.
Рекомендуем! | 1 691 |
| 9 | Pluto AI: анализ безопасности кода
Всем привет!
Сегодня хотим рассказать про ещё один сканер безопасности, использующий возможности AI – Pluto AI.
Он был разработан в качестве курсовой работы группой энтузиастов.
Процесс работы с ним достаточно простой:
🍭 Загрузка исходного кода напрямую или через ссылку на репозиторий
🍭 Анализ с использованием AI
🍭 Классификация сработок: критичность, CWE и т.д.
🍭 Вычисление уровня риска от 0 до 100
🍭 Генерация отчёта для предоставления всем заинтересованным
Его «AI-движок» позволяет находить 12 типов ИБ-дефектов: SQLi, XSS, использование жёстко закодированных паролей и т.д.
В качестве основной модели используется Gemini 1.5.
Помимо этого, Pluto AI генерирует рекомендации по устранению ИБ-дефектов и может «общаться» с пользователем через встроенный чат.
Вряд ли стоит ожидать от него чего-то сверхъестественного, но для ознакомления и изучения «внутренностей» может подойти. | 1 670 |
| 10 |  🔄Поздравляем победителей розыгрыша!
Спасибо всем, кто принял участие в наших исследованиях DevSecOps, средств контейнеризации и MLSecOps. Среди участников мы случайным образом выбрали по три победителя:
S.kovalenko@e****b.ru
@Otopy
Dmitry S
@AlixThunder
@Realmagnum
@rlukashenko
I.piga***zin@gmail.com
+79*****4549
@tempa042
⚡️Поздравляем!
В ближайшие дни свяжемся с победителями и расскажем, как получить призы.
А всем участникам спасибо за ответы — благодаря вам мы сможем увидеть реальную картину рынка и понять, куда движутся DevSecOps и MLSecOps. | 1 595 |
| 11 | Kubernetes Architecture in Financial Services
Всем привет!
В приложении можно найти электронную книгу (~ 169 страниц) от Авторов небезызвестного ресурса LearnKube.
Она посвящена нюансам, с которыми можно столкнуться при работе с Kubernetes в компаниях финансового сектора (да и не только, просто примеры из «того мира»).
Книга состоит из 7 глав:
🍭 Where Does the Tenant Boundary Belong?
🍭 One Delivery Path, Many Applications
🍭 Make Policy Enforceable and Exceptions Visible
🍭 Trust Across Service Boundaries
🍭 Healthy Components, Failing Requests
🍭 Reconstruct the Service's Dependencies
🍭 Replace the Runtime, Preserve the Service
Каждая глава описывает некоторую проблематику (например, как именно управлять разграничением доступа, управлением ресурсами и т.д.) и возможные пути решения.
Самое интересное – что это не просто синтетические данные или теоретические размышления на тему, а реальные проблемы реальных компаний финансового сектора. | 1 646 |
| 12 | KubeBuddy: анализ ресурсов Kubernetes
Всем привет!
KubeBuddy – CLI-утилита, которая анализирует общее состояние кластера как со стороны ИТ, так и со стороны ИБ.
Реализованы проверки для:
🍭 Статусов узлов, потребления ресурсов, состояния pod
🍭 Идентификации pod с ошибками, перезапусками
🍭 Выявления небезопасных привилегий в RBAC
🍭 Хранилищ, сервисов, сетевых политик и не только
В результате работы KubeBuddy генерирует отчёт в одном из форматов на выбор: HTML, Text, CSV.
А если вы используете Headlamp, то у KubeBuddy есть плагин, который позволяет отображать результаты его работы непосредственно в UI.
Больше информации о возможностях утилиты, способах отображения информации, запуске, настройке и проверках можно найти в GitHub-репозитории проекта или в официальной документации. | 1 591 |
| 13 | Patch The Planet
Всем привет!
В интернете можно найти много статей, в которых описано, что «классический» подход к управлению уязвимостями перестаёт работать.
В том числе это связано с развитием ИИ.
Уязвимостей находят больше, быстрее, формирование exploit’ов сократилось с месяцев/недель до часов.
Чтобы хоть как-то изменить/улучшить ситуацию OpenAI объединили усилия с Trail of Bits и реализовали инициативу Patch The Planet.
Её суть в том, чтобы, используя передовые AI модели и экспертный опыт людей, находить уязвимости и создавать обновления в ПО для их устранения.
Т.е. maintainer’ы не просто получают «У вас уязвимость, вот так воспроизвести», а полноценные рекомендации по устранению. Команда Patch The Planet активно работает с проектами и помогает тем, кто их разрабатывает.
В статье можно прочесть о том, как это примерно работает, какие проекты уже вошли в инициативу, какие ИБ-практики применяются.
А если вам хочется посмотреть на результаты, то рекомендуем обратить внимание на Patch The Planet Dashboard, в котором всё наглядно видно. | 1 838 |
| 14 | Claude Code: Security Best Practices
Всем привет!
Небольшой пятничный пост!
В приложении можно найти документ (~ 7 страниц), подготовленный Wiz и посвященный вопросам безопасности при работе с Claude Code.
Cheat Sheet содержит разделы:
🍭 Prompt Hygiene and Data Handling. Что (не) надо писать в prompt
🍭 Secure Code Generation. Рекомендации о том, как получить более безопасный код при его генерации
🍭 Supply Chain Attacks. Проверки на slopsquatting, работа с lockfile
🍭 Access Control. Ограничение возможностей агента, его полномочий и доступа к чувствительным данным
Каждый раздел содержит Action Item, в котором даются вполне конкретные советы и примеры того, как можно и нужно делать.
В завершение приводится небольшой перечень лучших практик по работе с агентами, MCP, встраиванию проверок в CI.
Ёмко, лаконично и по делу ☺️ | 2 292 |
| 15 | Конфигурация сети в Linux: практика
Всем привет!
По ссылке доступна лабораторная работа от Iximiuz Labs(Ivan Velichko), в которой придётся поработать с настройкой сети Linux-хостов.
Условия простые: есть 2 сервера в одной сети. На одном – Ubuntu, на втором Rocky Linux. Надо проанализировать их конфигурацию и ответить на вопросы.
Примеры вопросов:
🍭 Какие названия у основных сетевых интерфейсов
🍭 IPv4/MAC-адреса рабочих станций
🍭 IPv4 адрес шлюза по умолчанию
🍭 Через какой интерфейс пакеты отправляются на указанный адрес и т.д.
Да, задания достаточно базовые, но! Это те знания, которые точно пригодятся, ведь без понимания работы сетей – никуда. И если вы начинаете с этим работать, то лабораторные – то, что надо.
Для запуска не требуется ничего устанавливать, всё доступно непосредственно на сайте в интерактивной «площадке».
P.S. Помимо этой лабораторной, на labs.iximiuz.com можно найти ещё очень много всего интересного – рекомендуем! | 2 089 |
| 16 | State of DevSecOps 2026
Всем привет!
В приложении можно скачать отчёт от Datadog (~23 страницы), посвященный состоянию DevSecOps.
Для подготовки отчёта команда проанализировала результаты, генерируемые Datadog Code Security’s Software Composition Analysis.
В итоге получилось следующее:
🍭 87% организаций «обладают» хотя бы одной эксплуатируемой уязвимостью
🍭 Обновления библиотек занимают длительное время (медиана – «отставание» на 278 дней от самой новой major-версии)
🍭 Только 18% критичных уязвимостей остаются такими после уточнения базовой CVSS-оценки
🍭 32% организаций использовали публичные Docker образы через день после выхода новой версии
🍭 Аналогичное характерно и для JS и Python – 55%
Ничего революционного, ещё одно подтверждение того, что атаки на цепочку поставок сейчас занимают крайне объёмное место и важно уметь с ними работать.
В завершении отчёта можно найти набор общих рекомендаций о том, как можно повысить уровень защищенности при работе с open-source компонентами, цепочкой поставки и т.д. | 2 078 |
| 17 | Насколько хорошо ИИ анализирует код, написанный им же?
Всем привет!
Автор статьи работает в Greptile, которая занимается разработкой агента для AI Code Review.
В процессе работы ему стало интересно, влияет ли используемая модель на то, сколько недостатков находится?
Или, если проще, насколько хороши модели в анализе кода, который написан ими же?
Для этого он подготовил данные и методологию:
🍭 Собрал данные из 500 PR, которые были написаны с использованием Claude Code и Codex
🍭 «Авторство» модели определялось через данные, получаемые из commit, названий PR и/или веток
🍭 Подготовил перечень дефектов, которые были в этих 500 PR
🍭 Запустил Codex и Claude Code в
/review
3 раза
🍭 «Почистил» результаты от комментариев, которые относились к «стилистике» и не являлись дефектами
Что получилось? Оказалось, что модели лучше ищут ошибки в коде, который написан другими моделями.
Разрыв не очень большой, но всё же присутствует.
Ещё одним интересным наблюдением оказалось то, что модель скорее всего допустит ошибку при разработке, которую она скорее всего пропустит в review.
Помимо этого, в статье есть ещё много интересного. Включая дефекты, которые находились при «рассуждениях», но пропадали из «финального вердикта». | 2 282 |
| 18 | Contextual Security Analysis
Всем привет!
В приложении можно найти небольшой документ (~ 18 страниц) от DryRun Security, в котором представлена их модель контекстного анализа безопасности ПО.
Начинается всё с небольшого вступления, описывающего проблематику и «слепые» зоны детерминированных подходов, а также нюансы, связанные с генерацией кода.
Чтобы это преодолеть, по мнению команды DryRun, необходимо получать контекст, который позволит понять, что важно, а что - нет.
Но что такое этот самый «контекст»? Именно это и раскрывается в статье, а именно – SLIDE.
Он содержит параметры:
🍭 Surface. Как поверхность атаки меняется от commit к commit
🍭 Language. Какие языки программирования, framework’и, зависимости и т.д. участвуют в изменении
🍭 Intent. Информация об Авторе изменения, частоте изменений, ИБ-компетенциям
🍭 Detection. Данные о сканировании, получаемые из SAST, DAST, SCA и т.д.
🍭 Environment. Данные, с которыми работает ПО, наличие регуляторных требований и т.д.
Для каждого параметра кратко описывается почему он важен для расстановки приоритетов, а также где (потенциально) эти данные можно получить.
В итоге имеем набор данных, который позволяет понять, насколько то или иное изменение критично и стоит ли обращать на него внимание.
Несколько примеров использования предлагаемого подхода можно найти непосредственно в материале. | 1 930 |
| 19 | MCP Configuration Poisoning
Всем привет!
Ёмкая статья от Checkmarx, посвященная тому, как можно выполнять произвольный код на рабочей станции жертвы через воздействие на конфигурационные MCP-файлы.
Эти файлы содержат информацию о возможных для использования MCP-серверах: наименование, выполняемая команда, аргументы, переменные окружения и т.д.
Сама атака состоит в том, чтобы подменить «выполняемую команду» на ту, что нужна атакующему и с большой вероятностью она выполнится.
Из плохого – запуск в большинстве случаев может произойти автоматически, без запроса подтверждения пользователем. В некоторых сценариях даже Human-In-The-Loop (HITL) можно обойти.
Из хорошего – реализовать это может быть не так просто, т.к. потребует некоторого доступа к данным проекта.
В качестве примера реализации Автор приводит Snyk, snyk-agent-scan которых как раз мог «реализовать» MCP Configuration Poisoning(кстати, Snyk сперва не согласился с тем, что это недостаток ☺️).
Подобное трудно найти с использованием сканеров. «Ограничивать» команды тоже не всегда представляется возможным.
Поэтому в качестве рекомендации Автор предлагает использование «песочниц», мониторинг и контроль выполняемых программ и подтверждение действий пользователем. | 2 386 |
| 20 | The Definitive Guide to AI for DevOps / Agentic DevOps
Всем привет!
В приложении можно найти whitepaper (~ 43 страницы): The Definitive Guide to AI for DevOps / Agentic DevOps.
Материал подготовлен небезызвестным специалистом в мире Kubernetes и DevOps – Mumshad Mannambeth совместно с Jennifer Riggins.
Согласно материалу, в 2026 году из-за массового внедрения ИИ в «основную жизнь» «основной вопрос» изменился с «Насколько быстро мы можем писать код?» на «Как мы можем безопасно доставлять его в промышленное окружение?».
Но ИИ – таже самая технология, помощник. И всё очень сильно зависит от того, как с ним работать.
Бездумное использование принесёт больше проблем. Продуманное – может помочь. Но как быть и что делать?
Именно этому и посвящён whitepaper.
Он содержит разделы:
🍭 Where we are today. Нюансы, порождаемые повсеместным использованием ИИ
🍭 Where we need now. Использование guardrails, использование мульти-агентских систем, безопасность и observability
🍭 Measurement that matter. О том, какие метрики можно использовать для оценки эффективности использования ИИ в DevOps
Явных ответов и детальных планов, содержащих пошаговые инструкции не представлено.
Однако, внутри много интересных мыслей, которые помогут сориентироваться в том, что делать.
P.S. Поблагодарить Mumshad Mannambeth и команду, которая делала whitepaper можно вот тут! ☺️ | 2 328 |
