Superuser Gateway: опыт Uber

Всем привет!

Управление привилегированным доступом – задача крайне важная. Одна ошибка и ты ошибся. При этом, результаты могут быть достаточно «неприятные».

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

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

Чтобы сократить вероятность того, что «что-то пойдет не так», команда Uber сделала Superuser Gateway.

С его использованием процесс стал иным:
🍭 Инженер запрашивает выполнение команды с использованием CLI
🍭 Вместо «прямого выполнения» создается PR в определённом репозитории
🍭 Осуществляются проверки, включая review со стороны другого инженера
🍭 Как только PR согласован, он выполняется с использованием средств автоматизации

Superuser Gateway состоит из нескольких компонентов: CLI-утилиты, git-репозитория, набора CI-jobs и сервиса, который имеет «право» выполнять команды.

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

Gateway API Benchmarks

Всем привет!

Вопрос замены Ingress NGINX на нечто иное становится важнее день ото дня. Недавно был выпущен его финальный релиз, а в скором времени проект перейдёт в статус Archive.

Одной из возможных замен является Gateway API. Но какую реализацию выбрать?

Возможно, что вот это сравнение сможет вам помочь.

В нем Авторы сравнивают реализации:
🍭 Agentgateway
🍭 Envoy Gateway
🍭 Istio
🍭 Kong
🍭 Traefik
🍭 Nginx (да, он все еще попал в сравнение)

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

Тесты, цифры, графики, информация о потреблении ресурсов, данные о производительности и не только – всё это можно найти в сравнении.

P.S. По прямой ссылке доступна первая версия. К результатам второй версии можно попасть через ссылку, доступную в репозитории.

SecScore: оценка безопасности сборки

Всем привет!

SecScore – open-source утилита, которая позволяет описать правила (не) прохождения сборки, основываясь на критериях.

Да, по факту это некий аналог Security/Quality Gate.

Работает это примерно так:
🍭 Вы определяется «оценку», по достижении которой сборка считается «неудачной» (например, 100)
🍭 Для разных уровней критичности определяются свои веса (например, High – 20, Medium – 7 и т.д.)
🍭 Кроме этого, можно указать «Hard Fails» - т.е. нечто, чего попросту не должно быть. Да, даже если «оценка» не достигнута
🍭 Дополнительно можно указать условия. Например, реагировать только на новые ИБ-дефекты

По результатам работы, в том числе, создается комментарий в PR. В нём отображается информация о «принятом решении» и причины, на основании которых оно было сделано.

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

Безопасное использование пакетных менеджеров

Всем привет!

В марте 2026 года ENISA выпустила руководство «Technical Advisory for Secure Use of Package Managers», (~ 28 страниц), которое можно найти в приложении.

В нём приводятся практики, позволяющие повысить уровень информационной безопасности при работе с пакетными менеджерами.

Материал структурирован по разделам:
🍭 Solution architecture and data flows. Общее описание принципов работы пакетных менеджеров
🍭 Security risks in package consumption. Основная проблематика, с которой можно столкнуться (уязвимости, атаки на цепочку поставок и т.д.)
🍭 Best practices – secure package consumption. Рекомендации по безопасному использованию пакетных менеджеров

Материал описывает общие рекомендации (т.е. отдельных рекомендаций для «конкретного» пакетного менеджера нет).

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

Останется только понять «как именно» это можно сделать. Но здесь уникального ответа нет – каждый найдет свой собственный путь.

Trajan: анализ безопасности CI/CD

Всем привет!

Trajan – open-source утилита от Praetorian, которая позволяет анализировать настройки CI/CD и идентифицировать в них ИБ-дефекты.

«Из коробки» доступна следующая функциональность:
🍭 32 плагина для идентификации небезопасных настроек
🍭 24 плагина для идентификации атак
🍭 Несколько «режимов работы»: enumerate, scan и attack
🍭 Наличие графического web-интерфейса

На текущий момент поддерживается GitHub Actions, GitLab CI, Azure DevOps и Jenkins.

Количество плагинов для идентификации небезопасных настроек и атак варьируется в зависимости от рассматриваемой CI-системы.

Больше подробностей про проект можно найти в GitHub-репозитории или вот в этой статье от Авторов Trajan.

Поиск вредоносных contributors в open-source: опыт DataDog

Всем привет!

DataDog – компания, которая много сил вкладывает в развитие open-source. Включая собственные разработки, которые ребята дают миру.

Когда «идешь в public» - будь готов к тому, что тебя могут «исследовать» и пытаться атаковать. DataDog – не исключение.

Supply chain атаки особенно популярны в наше время: от «воздействия» на название PR до различного вида инъекций, в результате чего может быть украдена информация, подменён артефакт и т.д.

Недавно мы писали о BewAIre – наработке Компании, которая позволяет определить, является ли PR вредоносным или нет.

Ребята пошли дальше и теперь направляют результаты работы BewAIre в свой SIEM для последующего реагирования со стороны их SIRT-команды.

И именно это помогло им найти несколько атак на их open-source проекты.

Случилось примерно следующее:
🍭 BewAIre указал на то, что один из PR в IaC Scanner (который, кстати, open-source) может быть вредоносным
🍭 Команда отреагировала и выяснила, что злоумышленник пытался внедрить вредоносный код в название файла
🍭 Инъекция заключалась в том, чтобы скачать подконтрольный злоумышленнику файл и выполнить его
🍭 На этом приключение не закончилось. Спустя несколько часов было открыто несколько issues, в описании которых содержался prompt injection

Хорошие новости в том, что подход DataDog показал свою результативность на практике и действия злоумышленника удалось предотвратить.

Что было в том prompt injection и что за файл надо было скачать и запустить – обо всём этом и не только можно прочесть в статье.

Timeline, анализ действий злоумышленника, используемые им подходы, рекомендации по повышению уровня безопасности – всё на месте!

Рекомендуем!

Изучаем Istio: the Hard Way

Всем привет!

Если вы хотели притронуться к технологии Service Mesh и руки всё никак не могли дойти, то, возможно, эта статья сможет вам помочь.

В ней Автор на примере Istio разбирает что это такое, как это работает и как настраивается.

Статья содержит разделы
🍭 Описание «лаборатории» (все материалы можно найти в этом репозитории)
🍭 Краткое описание логики работы Istio
Управление трафиком (VirtualServices, DestinationRules, Subsets)
🍭 Реализация ZeroTrust-концепта с использованием mTLS
🍭 Балансировка нагрузки и не только

Краткое описание того, что происходит приводится в статье.

Если нужно больше информации (например, для самостоятельного воспроизведения), то её можно найти в GitHub-репозитории.

The Agentic Coding Security Report

Всем привет!

В приложении можно найти небольшой отчёт (~ 14 страниц) от DryRun Security – The Agentic Coding Security Report.

В нём отражена точка зрения на вопрос: «AI-агенты всё чаще и чаще используются для разработки ПО. Но как это влияет на уровень информационной безопасности?».

Для этого команда «поставила задачу» трём агентам – Claude, Codex и Gemini – по разработке ПО с последующей его «доработкой» через PR.

По завершению «работы» итоговые варианты программного обеспечения были проанализированы на наличие ИБ-дефектов.

Если кратко, то:
🍭 87% PR содержали ИБ-дефекты
🍭 Большинство ИБ-дефектов были «Высокого» уровня критичности
🍭 Разные агенты допускали идентичные ошибки (Broken Access Control, TOCTOU, XSS, User Enumeration и т.д.)
🍭 Codex показал лучшие результаты ☺️

Больше деталей, включая описание подхода к реализации поставленной задачи и описание итоговых результатов, можно найти в отчёте.

Атака на цепочку поставки: LiteLLM

Всем привет!

Атака на Trivy – вероятно самая обсуждаемая тема нескольких последних недель.

Но не ей единой. Компрометации подверглась и LiteLLM.

47 000 скачиваний уязвимых версий (1.82.7, 1.82.8) за 46 минут.

Вредоносное ПО делает следующее:
🍭 Сбор чувствительных данных (SSH-ключи, информация из конфигурационных файлов, shell-история и т.д.)
🍭 Собранные данные зашифровываются и передаются на https://models.litellm.cloud
🍭 Кроме этого, если присутствует Kubernetes Service Account Token, то вредоносное ПО пытается получить доступ о всех секретах кластера и создать pod и сделать некоторый mount на узел кластера

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

Kubelet: зачем он нужен и как устроен

Всем привет!

Kubelet – основной «агент» узлов кластера, который отвечает за жизненный цикл запускаемых на нём pod’ов.

Поэтому понимание принципов его работы крайне важно. Особенно, если pod постоянно находится в состояниях Pending или ContainerCreating.

Помочь в этом сможет статья, в которой Автор сделал очень неплохой «обзор» на Kubelet.

Материал содержит разделы:
🍭 Архитектура Kubelet
🍭 Основные (core) компоненты Kubelet
🍭 Описание процесса создания pod
Механизм синхронизации
🍭 Описание основных причин «падения» контейнеров и не только

Очень много различных схем, диаграмм последовательностей, примеров команд, позволяющих разобраться в происходящем.

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

Infralens: анализ service-to-service взаимодействия

Всем привет!

Infralens – open-source проект, который использует eBPF для автоматического обнаружения и визуализации взаимодействия service-to-service в кластерах Kubernetes.

Из ключевых функций можно отметить:
🍭 Отсутствие инструментации: никаких sidecars, изменения кодовой базы
🍭 Отображение топологии в режиме реального времени
🍭 Поддержка IPv4 и IPv6
🍭 Аналитика потребляемых ресурсов (CPU, RAM) узлами кластера
🍭 Интерактивная визуализация и не только

Кроме этого, Infralens позволяет генерировать автоматическое описание используемых сервисов при помощи AI.

Такая документация включает в себя: что делает сервис, какие используются технологии для его создания, описание сетевого поведения и т.д.

Подробности про возможности Infralens, его архитектуру, способы установки и настройки можно найти в GitHub-репозитории проекта.

Безопасная работа с npm

Всем привет!

В GitHub-репозитории собраны лучшие практики, позволяющие повысить уровень информационной безопасности при работе с npm.

Глобально материал «разбит» на разделы:
🍭 npm Security Best Practices
🍭 Secure Local Development Best Practices
🍭 npm Maintainer Security Best Practices
🍭 npm Package Health Best Practices

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

Для каждой рекомендации приводятся некоторые советы и набор команд, в которых указано как её можно реализовать на практике.

Кратко, по делу и ничего лишнего. Рекомендуем!

GitHub Actions: Security Roadmap

Всем привет!

События последних недель ясно дали понять, что безопасность цепочки поставки ПО – вещь достаточно важная и значимая.

Команда GitHub это понимает и ведёт работы в этом направлении. Недавно они опубликовали перечень нововведений, которые будут реализованы для повышения уровня информационной безопасности.

Ознакомиться с получившимся Security Roadmap можно по ссылке.

Если говорить в общем, то работа ведётся в трёх направлениях:
🍭 Ecosystem. Явное определение зависимостей и безопасная публикация
🍭 Attack Surface. Управление политиками, настройками по умолчанию и ограничение области действий учётных данных
🍭 Infrastructure. Контроль действий в реальном времени, ограничение сетевого взаимодействия runner’ов

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

Или же создание политик, которые явно определяет кто именно/какое событие может запускать сборку.

И, конечно же, какой Roadmap без сроков – информацию о доступности нововведений можно найти в статье.

Безопасность CI/CD: рекомендации Latio

Всем привет!

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

Особенно, когда речь касается безопасности процесса сборки. Причина проста – поверхность атаки гораздо больше.

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

Ребята собрали набор практик по следующим разделам:
🍭 Third-Party Packages
🍭 Container Images
🍭 GitHub Actions
🍭 Infrastructure-as-Code Modules
🍭 AI/ML Modules
🍭 IDE Extensions and Developer Tools

Для каждого раздела приведен checklist, состоящий из двух разделов.

Первый – Immediate Actions – описывает высокоприоритетные задачи, которые помогут значительно «сократить» поверхность атаки.

Второй – Long-term Initiatives – предлагает набор практик для развития и дальнейшего улучшения.

В завершении статьи можно найти примеры атак по рассмотренным выше областям.

Кстати, проверки всех checklist’ов можно автоматизировать с использованием Claude Code Plugin, ссылку на который можно найти в статье.

Self-Deployment: работа с ИТ-инфраструктурой

Всем привет!

В приложении можно найти полноценную книгу (~ 774 страницы), в которой собрана информация, которая может помочь погрузить в тематику работы с ИТ-инфраструктурой и Kubernetes в частности.

Автор написал её для разработчиков, чтобы они понимали не только «свою часть», но и «всю картину» в общем.

Книга содержит главы:
🍭 Introduction to Linux
🍭 Basics of the Shell Environment
🍭 Basic Linux Commands
🍭 Containerization and Docker
🍭 Kubernetes и не только

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

Примеры, пояснения, немного истории, ссылки на полезные материалы по рассматриваемой теме – всё внутри!

P.S. Если кто-то хочет материально отблагодарить Автора, то сделать это можно по ссылке