DevSecOps Talks

Всем привет! Обсудили на подкасте с коллегами из Crosstech Solutions Group безопасную разработку, DevSecOps, безопасность контейнерной инфраструктуры и боли-печали всех тех, кто этим занимается. Приятного просмотра (или прослушивания ☺️) Яндекс Музыка ВК Rutube

Использование LLM для анализа PR Всем привет! Как быть, если надо анализировать около 10,000 PR, создаваемых еженедельно? Вариант ответа на этот вопрос можно найти в статье от DataDog. В ней Авторы описывают свой опыт создания BewAIre – специализированного инструмента, который позволяет определить является ли PR вредоносным. Команда разбила задачу на 3 блока: 🍭 Управление набором данных (dataset, создание, актуализация) 🍭 Работа с «контекстными окнами» и большими размерами данных 🍭 Сокращение ложных срабатываний Каждый из разделов очень хорошо описан в статье, включая перечень подходов, используемых Командой. В результате у них получилось достичь приличных показателей: > 99.3% - точность, 0.03% - FP, 100% - покрытие. Больше подробностей, включая описание «подводных камней» и lessons learned, можно найти в самой статье.

MCP Breach-to-Fix Labs Всем привет! По ссылке доступен набор из 9 лабораторных работ, посвященных вопросам безопасности при работе с MCP. Все сценарии проверены Автором и не являются теоретическими. Они помогут лучше понять «что может пойти не так» при работе с MCP и как сделать лучше. Доступны такие лабораторные, как: 🍭 Hidden Instructions in Tool Responses 🍭 Log Poisoning Incident Response 🍭 Classic SQL Injection (Stored Prompt) 🍭 Git Command Injection 🍭 Tool Description Poisoning и не только У каждого сценария есть 2 «режима»: уязвимый и безопасный (hardened-вариант, который остановит атаку). Запуск – как обычно, через Docker – инструкции можно найти в GitHub-репозитории. Больше информации о проекте можно найти в статье.

SecureCodeChallenges Всем привет! По ссылке доступен репозиторий, в котором находится небольшое уязвимое приложение. Ваша цель – провести его Security Review. Найти все ИБ-дефекты, объяснить насколько они критичны, предложить рекомендации и реализовать «защищенную версию». «Доступен» следующий набор ИБ-дефектов: 🍭 SQL Injection 🍭 Stored XSS 🍭 Insecure Query Building 🍭 Missing Validation and Sanitization 🍭 Poor Handling of User Input 🍭 Lack of Output Encoding Приложение создано с использованием Node.js, React, SQLite, Simple REST API. Соответственно, для установки и запуска потребуется Node.js. Дальше все просто – скачиваем репозиторий, устанавливаем зависимости, запускаем приложение, получаем к нему доступ по порту 3000 и исследуем.

Kubeterm: GUI для Kubernetes Всем привет! Начинаем рабочую неделю с чего-то простого, а именно – Kubeterm. Да, это еще один графический web-интерфейс для Kubernetes. С его помощью можно: 🍭 Аутентифицироваться в кластере Kubernetes 🍭 Просматривать общую информацию о кластере 🍭 Получать данные о созданных ресурсах 🍭 Управлять ресурсами: создавать, редактировать удалять и т.д. В том числе с использованием Helm 🍭 Искать причины возникших проблем (troubleshooting) через ephemeral-контейнеры 🍭 Реализовывать port-forward и не только Устанавливается и настраивается быстро, можно сразу использовать. С «внешним видом» можно ознакомиться по ссылке на GitHub-репозиторий. P.S. Можно установить даже на iOs и Android 😅

Анализ безопасности приложений с Raptor Всем привет! Raptor – open-source проект, использующий Claude Code для проверки безопасности разрабатываемого приложения. И да – это акроним: Recursive Autonomous Penetration Testing and Observation Robot (если кому-то это интересно 😅). Он позволяет: 🍭 Сканировать исходный код с Semgrep и CodeQL 🍭 Проводить fuzzing исполняемых файлов с AFL 🍭 Анализировать идентифицированные ИБ-дефекты с применением LLM 🍭 Генерировать exploits для подтверждения возможности эксплуатации ИБ-дефекта 🍭 Предлагать исправления для устранения ИБ-дефектов 🍭 Создавать отчеты в структурированном формате Есть 2 режима установки – «самостоятельная» и c использованием devcontainer. Подробнее об этом и о возможностях Raptor можно узнать в GitHub-репозитории проекта.

Technology Matrix: альтернативный взгляд на CNCF Landscape Всем привет! Если вы хотя бы раз видели CNCF Landscape, то, вероятно, у вас возникало несколько мыслей: «Как тут много всего!» и «А как с этим работать?». Он развивается, обновляется, решений становится больше и… навигация в нем может быть не самой удобной. Примерно так решил Автор статьи и сделал собственный вариант – Technology Matrix. Задача – сделать работу с невероятным количеством технологий более удобной, наглядной и понятной. Автор разбил все на 7 основных «областей»: 🍭 Skip. Пока не интересует 🍭 Watch. Наблюдение за проектом, чтение release notes и т.д. 🍭 Explore. «Тестирование» - базовая установка и настройка, прохождение различных руководств. Без особого погружения 🍭 Learn. «Продвинутая» версия Explore – более глубокое изучение 🍭 Adopt. Использование в «реальной жизни», готово к промышленной эксплуатации 🍭 Advocate. Евангелизм: не просто использование, но и распространение информации о технологии 🍭 Graveyard. Без комментариев Для некоторых технологий Автор описывает почему он их использует, что именно ему нравится и почему он остановился на этом варианте. Больше информации про Technology Matrix можно найти по ссылке. Возможно, если вы любите структурировать информацию, предложенный подход может вас заинтересовать.

Ingress NGINX -> HAProxy Kubernetes Ingress Controller Всем привет! Недавно мы писали об утилите, которая позволит упростить переход с Ingress NGINX на Gateway API. Это не единственный вариант. Но что, если вы не хотите использовать Gateway API, а хотите остаться на Ingress? В этом случае вам может быть полезен вот этот сайт. Помимо базовой информации о том, как установить новый Ingress Controller, сайт поможет адаптировать существующие Ingress NGINX-конфигурации на HAProxy-вариант. Например, за счет «подсказок» о том, как выглядит та или иная аннотация в обоих вариантах и что нужно изменить. Помимо этого, сервис предоставляет ссылки на документацию, чтобы проще было в ней ориентироваться и сразу получат ответ на интересующий вопрос. «Вишенкой» является набор руководств (tutorial), в которых собраны подобные инструкции о том, как настроить, например, Route HTTP traffic, Load balance traffic, Terminate SSL/TLS и т.д.

Безопасность Supply Chain на примере npm Всем привет! В обновленной версии OWASP Supply Chain сразу попала на 3ье место, Shai-Hulud продолжает уничтожать Атрейдесов и Харконненов атаковать npm – лишь немногие подтверждения того, что вопрос обеспечения цепочки поставки ПО крайне важен. В статье от SNYK можно найти набор рекомендаций о том, что можно сделать, чтобы повысить уровень безопасности при работе с заимствованными компонентами на примере npm. Всего доступно 12 рекомендаций: 🍭 Disable post-install scripts 🍭 Install with cooldown 🍭 Harden installs with npq 🍭 Prevent lockfile injection 🍭 Use deterministic installs и т.д. Для каждой рекомендации приводится краткое описание зачем это нужно и примеры реализации соответствующих настроек. Отличное руководство, в котором содержится много полезной информации. Рекомендуем!

Ingress -> Gateway Всем привет! В марте 2026 закончится развитие и поддержка Ingress NGINX (если вы вдруг пропустили, то мы писали об этом вот тут). Одним из возможных кандидатов для «переезда» является Gateway API. Чтобы немного упростить и автоматизировать процесс можно воспользоваться проектом ingress2gateway. Он создан и поддерживается разработчиками Kubernetes. Если просто, то он делает следующее: 🍭 Использует kubeconfig файл для того, чтобы иметь возможность «общения» с кластером 🍭 Ищет ресурсы Ingress NGINX в указанном namespace 🍭 Конвертирует найденные ресурсы в спецификацию, «понятную» Gateway API (на текущий момент только Gateways и HTTPRoutes) Да, не совсем «полноценный переезд», но может сэкономить некоторое время. Кстати, ingress2gateway поддерживает не только Ingress NGINX, но и другие провайдеры. С установкой, запуском и возможными опциями можно ознакомиться в GitHub-репозитории проекта. А какой Ingress вы выбрали для себя на замену?

Kubernetes Learning Path! Всем привет! По ссылке доступен GitHub-репозиторий, в котором собраны материалы, которые будут полезны при изучении Kubernetes. Отличительной особенностью ресурса является то, что он не сразу «прыгает» в изучение основных сущностей Kubernetes, а смотрит на вопрос немного шире – начиная с фундаментальных основ. Например: 🍭 Understanding Distributed System 🍭 Basics of Key Value Store 🍭 Learn YAML 🍭 Understand Service Discovery 🍭 Network Basics и т.д. После этого Авторы предлагают углубляться в сам Kubernetes – от понимания архитектуры и основных сущностей до создания и эксплуатации своего первого кластера. Много ссылок на курсы, статьи, материалы по теме, а также voucher для получения скидки при оплате экзаменов (CKA, CKS, CKAD и т.д.) Возможно, следующим Kubestronaut станете именно вы! ☺️

Поиск секретов: false positive или false negative? Всем привет! Задача поиска секретов – крайне важная задача при обеспечении безопасности разрабатываемого ПО. Существует множество различных сканеров и подходов, которые позволяют это сделать. Но эти сканеры не лишены недостатков: они могут генерировать большое количество false positive (дада, например, та-самая-длинная-переменная-на-Java). Поэтому разработчики средств анализа секретов используют разные методы для получения более релевантных результатов: от объединения подходов (RegEx и энтропия) до анализа используемости и/или валидности секрета. Однако, это «закручивание гаек» может дать «побочный эффект» - false positive сменятся на false negative и сканер не найдет «обычный секрет». Что с этим можно сделать? Возможный ответ есть в статье от Semgrep. В ней Авторы описывают: 🍭 Общие принципы работы средств анализа секретов 🍭 Техники, которые они используют для сокращения false positive 🍭 Результаты эксперимента команды по анализу репозиториев GitHub с целью поиска секретов 🍭 Рекомендации о том, как улучшить показатели работы сканеров Много наглядных примеров и пояснений, которые позволяют лучше погрузиться в проблематику и возможные способы ее решения. Кроме этого, в статье описаны трудности, с которыми можно столкнуться при оптимизации правил. Например, отсутствие уникальности в префиксах токенов (sk_live_, sk, gsk_ -весьма похожи, но используются разными сервисами). Рекомендуем!

DevEx Engineer: на что обращать внимание при аудитах Всем привет! Работа на новой позиции зачастую связана с ответом на вопрос: «А что здесь вообще происходит и с чем мне придется работать?». DevEx (Developer Experience) – роль, которая должна помочь оптимизировать процессы разработки и доставки ПО – не исключение. В статье можно найти достаточно подробный план на 30 первых дней, в котором указано на что следует обращать внимание при проведении первичного аудита. Материал структурирован по разделам: 🍭 Phase 1: Benchmark Feedback Loops (Days 1–10). Понимание процессов сборки, тестирования, разворачивания 🍭 Phase 2: Reduce Context Switching (Days 11–20). Работа с управлением задачами, базой знаний и передачей компетенций 🍭 Phase 3: Audit Rituals That Impact Velocity (Days 21–30). Поиск ненужных (неоптимальных) «ритуалов» и бутылочных горлышек Для каждой из фаз Автор приводит краткое описание «что это и зачем?», а также набор метрик, которые помогут лучше разобраться в вопросе. Дополнительно описываются рекомендации о том, как и что можно улучшить. В указанный план аудита можно очень удачно встроить часть, связанную с информационной безопасностью, чтобы сделать его более комплексным и полным.

Раскрытие чувствительных данных через GitLab GraphQL API Всем привет! Небольшая история о том, как уязвимость в GitLab API позволила получить доступ к конфиденциальной информации. GraphQL API GitLab’a отключает защиту от CSRF для Queries (которые передаются через GET-запросы) и включает ее для Mutations (которые передаются через POST-запросы). Это построено на допущении, что Queries могут только «читать» данные и ничего больше. Но так ли это на самом деле? Оказалось, что нет. Нашлась Query, которая может делать запросы к внешним сервисам. Соединив все это вместе Автор реализовал сценарий: 🍭 Атакующий настраивает webhook для получения данных 🍭 Создается HTML-файл, который перенаправляет пользователя на специальный URL (используя ту самую «небезопасную» Query) 🍭 Файл направляется аутентифицированному GitLab-пользователю, он нажимает на ссылку… 🍭 Отправляется GET запрос к gitlab.com/api/graph/… 🍭 Готово! Данные отправлены атакующему Если нужно больше деталей о реализации сценария, то найти их можно в статье – там все очень подробно расписано. Помимо этого, в статье есть видеозапись, которая демонстрирует реализацию рассмотренной атаки. Важно (!): информация об уязвимости была сообщена команде GitLab и устранена в версии 18.4 (подробности доступны тут).

Kubernetes Network Tutorial для разработчиков Всем привет! По ссылке можно найти обзорный материал о том, как устроено сетевое взаимодействие в Kubernetes и как с ним можно (нужно) работать. «Предварительные требования» невелики: общее понимание контейнеризации и сетевых терминов, наличие кластера Kubernetes и установленный Helm. Материал структурирован по разделам: 🍭 Introduction to Kubernetes Networking 🍭 Core Concepts in Kubernetes Networking 🍭 Cluster Networking Components 🍭 DNS and Service Discovery 🍭 Pod Networking Deep Dive 🍭 Network Policies and Security 🍭 Common Pitfalls and Troubleshooting 🍭 Summary and Next Steps Получился tutorial, который охватывает сразу несколько тем и написан очень простым и понятным языком. Много примеров и пояснений. В каждом разделе есть какой-то свой сценарий, на котором Автор наглядно демонстрирует происходящее. Хоть в названии и указано «для разработчиков», статья может быть полезна всем, кто хочет разобраться в основах сетевого взаимодействия Kubernetes. Рекомендуем!

Docker Security: лабораторные работы Всем привет! Материал для начинающих. По ссылке можно найти GitHub-репозиторий, в котором собран набор лабораторных работ по безопасности Docker. Всего доступно 6 заданий: 🍭 Lab 01: Security Auditing with Docker Bench 🍭 Lab 02: Secure Container Configurations 🍭 Lab 03: Least Privilege Containers 🍭 Lab 04: Image Signing and Verification 🍭 Lab 05: Seccomp Profile 🍭 Lab 06: AI Model Security Для каждой работы приводится краткое описание в формате *.md о том, что надо сделать и как ее надо запустить. Если возникнут трудности с решением, то можно обратиться к этой статье. В ней Автор описывает как и что он делал для успешного прохождения лабораторных.

Зачем нужен AI SAST и как он работает? Всем привет! Ответ на первую часть вопроса достаточно прост. «Классические» SAST решения в большей степени привыкли искать некие шаблоны (patterns). Они не понимают, как работает приложение. Поэтому они показывают не самые лучшие результаты, например, при анализе бизнес-логики или ИБ-дефектах, связанных с обходом аутентификации. На вторую часть вопроса ответить тяжелее, так как у разных производителей свои подходы. Сегодня хотим поделиться с вами тем, как это делает ZeroPATH. Подход ребят состоит из этапов: 🍭 Trigger Scan. Просто запуск сканирования (ручной, автоматический – не важно) 🍭Application Identification. «Изучение» приложения и получение «базовой» информации о нем 🍭AST Generation & Indexing. Создание AST 🍭Graph Enrichment. Обогащение графа через контекст 🍭Vulnerability Discovery. Идентификация ИБ-дефектов за счет анализа графа 🍭Validation & Verification. Подтверждение возможности эксплуатации, в том числе за счет анализа достижимости 🍭Patch Generation. Генерация рекомендаций по устранению уязвимостей Каждый из этапов очень детально описан в статье. Приводятся схемы, поясняется что же это за «контекст» такой, который нужен для корректной работы. Получился материал, который может дать неплохое представление о том, как AI SAST может работать «под капотом». Рекомендуем!