DevSecOps Talks

Безопасность 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 может работать «под капотом».
Рекомендуем!

(Не)доверие и Supply Chain Security

Всем привет!

«Каждый раз, когда вы запускаете cargo add или pip install, вы совершаете прыжок веры» - именно так начинается статья от Trail Of Bits, посвященная безопасности цепочки поставки.

В ней Авторы сфокусировались на вопросах доверия:
🍭 Тому, что устанавливается именно тот пакет, который вы указали
🍭 Тому, что пакет опубликован теми, кто его поддерживает (maintainers)
🍭 Тому, что пакет был создан из опубликованных исходных кодов
🍭 Доверия тем, кто поддерживает и развивает используемые пакеты

И именно на эксплуатации этого доверия и совершаются различные атаки. От typosquatting до намеренного внедрения вредоносного кода.

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

Завершает статью описание способов защиты, которые позволяют реализовать и контролировать доверие: от генерации SBoM (куда уж без них) до создания аттестаций.

Кстати, если тема вам интересна, то на канале мы много писали про материалы от OpenSSF, которые могут быть очень полезны при обеспечении безопасности цепочки поставки.

Например, тут, тут и тут (и поиском по OpenSSF)

Awesome Annual Security Reports

Всем привет!

Начинаем новую рабочую неделю с чего-то простого и непринужденного!

По ссылке можно найти awesome-подборку, в которой собраны разные отчеты по информационной безопасности.

Подборка сгруппирована по разделам:
🍭 Analysis Reports
🍭 Survey Reports
🍭 Resources

«Внутри» каждого раздела доступны отчеты по различным темам. Application Security и Cloud Security не обошли стороной.

Для каждого отчета приводится небольшое summary о том, что можно найти «внутри», информация об Авторах и годе выпуска.

Из приятного – отчеты доступны в PDF без регистрации и SMS ☺️

Поиск проблем в сети Kubernetes с Songbird

Всем привет!

Songbird – крайне талантливый netrunner open-source утилита, который позволяет идентифицировать проблемы в сетевом взаимодействии Kubernetes.

Она может:
🍭 Проверять сетевую связность/доступность
🍭 Определять проблемы, связанные с DNS (да, это всегда DNS!)
🍭 Анализировать сетевые политики

Кроме этого, она может генерировать сетевые политики. Увы, не в автоматическом режиме, скорее как «обертка» для более простого создания YAML-конфигурации.

Результаты работы команд по анализу сетевого взаимодействия можно отображать в разных форматах – табличка или JSON.

Больше информации (флаги, примеры и сценарии использования) можно найти в GitHub-репозитории проекта.

Вот и все, ребята! Ingress NGINX

Всем привет!

Небольшой, но очень важный пост. Объявлено «завершение поддержки» Ingress NGINX: «Best-effort maintenance will continue until March 2026».

После этой даты не будет релизов, исправления багов, обновлений и т.д.

Рекомендация простая – начать миграцию на «одну из множества» альтернатив. Например, на Gateway API.

Подробнее с новостью можно ознакомиться в блоге Kubernetes.

Metis: AI-Powered Security Code Review

Всем привет!

Metis – open-source утилита, разработанная командой продуктовой безопасности Arm. Его основная задача состоит в том, чтобы упростить процесс code review и улучшить код с точки зрения ИБ.

В отличие от «традиционных» линтеров и SAST-инструментов, Metis работает за счет «понимания кода и того, что происходит».

На текущий момент он поддерживает C, C++, Python, Rust и TypeScript. Конечно же, для его работы нужен LLM provider, в качестве которого выступает OpenAI.

Возможно расширить набор используемых prompts. На текущий момент доступны: security_review, validation_review и security_review_checks.

По результатам работы Metis может сгенерировать отчет (JSON). Также, судя по коду, доступен (или скоро будет доступен) вариант с SARIF.

Больше про утилиту (установка, настройка, запуск и т.д.) можно прочесть в GitHub-репозитории.

OWASP Top 10: 2025

Всем привет!

6 ноября 2025 года был представлен OWASP Top Ten 2025 Release Candidate.

Изменений получилось достаточно и даже появилось кое-что новое.

Сейчас список выглядит следующим образом:
🍭 A01:2025 - Broken Access Control // сюда «переехал» SSRF из OWASP Top 10 2021
🍭 A02:2025 - Security Misconfiguration // ⬆️
🍭 A03:2025 - Software Supply Chain Failures // Новое
🍭 A04:2025 - Cryptographic Failures // ⬇️
🍭 A05:2025 - Injection // ⬇️
🍭 A06:2025 - Insecure Design // ⬇️
🍭 A07:2025 - Authentication Failures
🍭 A08:2025 - Software or Data Integrity Failures
🍭 A09:2025 - Logging & Alerting Failures
🍭 A10:2025 - Mishandling of Exceptional Conditions // Новое

A03:2025 - Software Supply Chain Failures стала «расширением» A06:2021-Vulnerable and Outdated Components, демонстрируя, что безопасность цепочки поставки не ограничивается только управлением версиями используемых компонент.

A10:2025 - Mishandling of Exceptional Conditions – новая категория, «внутри» которой 24 CWE, связанных с некорректной обработкой ошибок, логическими и иными ошибками, которые могут привести к неконтролируемому поведению системы.

Подробнее с изменениями можно ознакомиться по ссылке.

Open Source Malware

Всем привет!

Open Source Malware – общедоступный ресурс, на котором собрана информация по вредоносным пакетам, которые можно найти в NPM и PyPi.

Также на сайте присутствует информация о Malicious Repositories, которые могут содержать криптомайнеры, использоваться для скама и/или фишинга.

Для каждого пакета приводится информация:
🍭 Описание угрозы
🍭 Детали payload’a (доступно только после регистрации через GitHub)
🍭 Информация о пакете и «издателе»
🍭 Ссылки на полезные ресурсы

На текущий момент база содержит информацию о 60к+ NPM пакетах, 9,7k PyPi пакетах и о 14 репозиториях.

Взаимодействовать с ресурсом можно и через API, описание которого представлено на сайте.

Chaos Engineering и MCP

Всем привет!

Цель Chaos Engineering – создание устойчивых систем. Проведение экспериментов с целью понимания скорости - локализации, реагирования и исправления проблемы.

Однако, реализация Chaos Engineering далеко не всегда (если вообще) – простая задача. Начиная от банального «а вдруг я что-то сломаю» и заканчивая технической сложностью реализации.

Именно вторую проблему пытается решить LitmusChaos MCP Server. Он позволяет проводить различные эксперименты.

Например:
🍭 Удаление frontend pod’ов
🍭 Изменение network latency
🍭 Создание http probe, которая проверяет API каждые 5 секунд
🍭 Получение статистики о (не) удавшихся экспериментах и не только

Никакого кода, никаких YAML или иных конфигурационных файлов, только «живое общение на обычном языке».

Больше о том, что может LitmusChaos MCP Server можно узнать в статье или в GitHub-репозитории проекта.

А стали бы вы использовать (доверять) подобную систему? Или все это слишком непонятно, рискованно, неконтролируемо?

IDOR Testing Checklist

Всем привет!

Продолжение темы предыдущего поста про IDOR. На случай, если вы не доверяете LLM и хотите во всем разобраться сами.

По ссылке можно найти checklist, в котором собраны рекомендации о том, что, как и когда стоит проверять для выявления IDOR.

Материал структурирован по разделам:
🍭 Setup & Target Identification
🍭 Direct ID Substitution & Enumeration
🍭 Path and URL Manipulation Bypasses
🍭 Logic & Endpoint Bypasses
🍭 Parameter & Body Abuse и не только

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

Внушительный материал, в котором точно можно найти что-то интересное для себя.

Использование LLM для поиска IDOR

Всем привет!

Команда Semgrep продолжает анализировать возможность использования LLM для поиска ИБ-дефектов в исходном коде.

В «первой части» ребята использовали Claude Code и OpenAI Codex для анализа популярных open-source Python-приложений.

На этот раз они сфокусировались на одном определенном типе – IDOR. Перечень LLM остался без изменений.

Если кратко, то:
🍭 Всего было найдено 15 true positive и 93 false positive
🍭 Claude показал лучшие результаты
🍭 LLM хорошо показали себя в поиске простых ИБ-дефектов и не так хорошо в примерах со сложной логикой (например, когда проверка полномочий осуществлялась в разных файлах)
🍭 Возможно, что prompt engineering сможет улучшить полученные результаты

Больше деталей можно найти в статье. Включая информацию о том, почему для LLM поиск IDOR не такая тривиальная задача.

В результате имеем очень хорошее исследование, с которым мы рекомендуем вам ознакомиться ☺️

Forkspacer: создание fork’ов ресурсов и данных Kubernetes

Всем привет!

Forkspacer – open-source решение, которое позволяет создавать fork для окружения разработки. При этом «копируется» не только конфигурация, но и данные.

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

Помимо этого, Forkspacer позволяет реализовать гибернацию используемых ресурсов. Например, на случай, когда они не используются.

Настраивается достаточно просто – необходимо создать ресурс Workspace, в котором указать какой namespace мы хотим «скопировать» и указать что именно нужно копировать (ресурсы, данные и т.д.).

После этого Forkspacer создаст нужное окружение, с которым можно работать не опасаясь, что в исходном «что-то сломается».

Подробнее об архитектуре, установке, настройке, сценариях использования и примерах можно узнать в GitHub-репозитории проекта или в официальной документации.