Cilium Policy Generator

Всем привет!

Если вам нужны Network Policy, но вы не хотите их писать самостоятельно, а вместо этого использовать средства автоматизации, то проект cpg может вам помочь.

Работает он по следующему принципу: соединяется с Hubble Relay, анализирует dropped-соединения и генерирует CiliumNetworkPolicy, которые их разрешают.

Предполагается, что всё начинается с правила default-deny-all, что позволяет «открывать» только нужные каналы взаимодействия на основании анализа трафика.

Сам по себе он ничего не применяет, а лишь генерирует YAML-файлы для дальнейшей проверки и применения, если всё соответствует действительности.

Не все dropped-соединения попадают в политику. Часть из них «отбрасываются» cfg с указанием причины принятого решения.

Из ключевых ограничений можно выделить: работа только с L4-трафиком, создание только CiliumNetworkPolicy (а не CLusterWide).

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

GitHub Actions: угрозы, атаки и защита

Всем привет!

По ссылке можно ознакомиться со статьёй от Wiz, посвященной моделированию угроз, атакам и способам защиты для GitHub Actions.

В начале статьи рассматривается, где проходит грань между (не) доверенным зонам: от владельцев репозиториев до ботов и приложений, которые могут создавать pull request.

Это позволяет лучше понять проблематику и как именно могут совершаться атаки на GitHub Actions.

Далее Авторы детально рассматривают несколько примеров:
🍭 Ошибки при работе с pull_request_target (который похож на pull_request_trigger, но всё-таки отличается)
🍭 Script Injection («расширение» возможностей запускаемого workflow)
🍭 Compromised 3rd-party Action (компрометация популярного action)

Для каждого из вышеописанных пунктов приводится его описание, примеры атак и возможные способы защиты.

Дополняет этот материал обилие ссылок на полезные ресурсы по теме и примеры реальных атак.

Изменения в NVD, обновление подхода к управлению уязвимостями

Всем привет!

Количество уязвимостей растёт год от года. И сама скорость роста тоже возрастает. В связи с этим недавно NVD объявила о том, что подход к обогащению данными по CVE будет изменён.

Раньше было примерно так: кто-то публиковал CVE, её ID, иногда – CPE, набор ссылок и CVSS, который считался Автором CVE.

NVD, в свою очередь, всё это обрабатывала и стандартизировала: корректный CPE, уточнение CVSS, добавление CWE, группировка ссылок-референсов.

Это позволяло сделать процесс более системным и нормализованным.

Однако, 15 апреля 2026 года подход изменился. Описанная выше работа NVD будет не для всех уязвимостей, а только для части из них.

Например, если CVE есть в KEV. Но таких всего 0,5%. Получается, что в долгосрочной перспективе мы будем получать меньше информации или она будет не так структурирована и информативна.

Что с этим делать и как быть? Мнение на этот счёт есть у Автора статьи.

Он считает, что пора уходить от подхода, где ИБ расставляет приоритеты исходя из характеристик определенной CVE (критичность, CVSS и т.д.).

Получать дополнительную информацию: тот же KEV, информация из EPSS, использование альтернативных источников данных по уязвимостям (GHSA, бюллетени, OSV и т.д.), понимание контекста актива, в котором найдена уязвимость.

Это позволит самостоятельно определить те значимые параметры, которые раньше (пусть и не очень точные) можно было получить от NVD.

И, конечно, не стоит забывать и о runtime-защите, которая позволит поставить «временный патч» и выиграть время для устранения уязвимости в коде.

А что вы думаете по этому поводу? Насколько для вас значимо то, что NVD, со временем, сократит количество предоставляемой информации по CVE?

k9sight: TUI для работы с Kubernetes

Всем привет!
k9sight – open-source проект, представляющий из себя текстовый интерфейс для работы с ресурсами Kubernetes.

Он позволяет:
🍭 Получать информацию о Deployments, StatefulSet, DaemonSet, Job, CronJob и не только
🍭 Просматривать логи pod, осуществлять поиск и фильтрацию
🍭 Делать exec и port-forward
🍭 Перезапускать ресурсы, изменять количество реплик
🍭 Получать информацию об events, метриках и не только

И самое интересное! Vim-style навигация! Для всех фанатов этого редактора или просто для тех, кто так и не смог из него выйти ☺️

Подробности о возможностях, способах установки – всё в GitHub-репозитории проекта.

А вместе с этим – небольшая (но наглядная) демонстрация его возможностей.

wachd: поиск причин проблем с помощью ИИ

Всем привет!

Ещё один вариант использовании ИИ для облегчения задач поиска ошибок.

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

Работает она по следующему алгоритму:
🍭 Получает webhook от Grafana, Datadog, Splunk или любого иного подходящего источника
🍭 Дополучает контекст: логи сообщений, историю потребления ресурсов и т.д. Контекст берётся из промежутка времени, в котором произошел инцидент
🍭 Удаляет всю конфиденциальную информацию перед анализом
🍭 Пытается понять, что именно стало причиной проблемы
🍭 Уведомляет ответственного об инциденте и его возможной причине

Установка, настройка, описание API, инструкции – всё это доступно в GitHub-репозитории проекта.

Open-source версия wachd имеет ограничения в использовании: 1 команда, 5 пользователей, 1000 уведомлений в месяц и возможность использования только Ollama.

DefenseClaw: защита агентских AI

Всем привет!

Недавно Cisco выпустила DefenseClaw – open-source проект, задача которого – повысить уровень ИБ при использовании агентских AI.

Он «состоит» из CLI-, написанной на Python, Gateway Sidecar на Golang и TS-плагина для OpenClaw.

Если обобщить, то DefenseClaw позволяет:
🍭 Сканировать skills, MCP-серверы, плагины и код перед тем, как они будут запущены
🍭 Анализировать prompts, вызовы, которые будут реализованы инструментами
🍭 Искать секреты, опасные функции, небезопасную десериализацию, паттерны инъекций
🍭 Возможность запускаться в «песочнице»
🍭 Получать полную информацию о том, что происходило

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

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

100 Kubernetes Assignments

Всем привет!

Скоро майские и самое время придаться чтению. А чтению чего-нибудь полезного – ещё лучше!

В приложении можно найти электронную книгу «100 Kubernetes Assignments» (~ 106 страниц).

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

Задания разделены на 3 группы: Beginner (1 – 30), Intermediate (31 – 70) и Advanced (71 – 100). Уровень «сложности» заданий и рассматриваемых тем растёт от группы к группе.

Каждое задание включает в себя:
🍭 Понятное и лаконичное описание
🍭 Перечень того, что нужно иметь или сделать для его выполнения
🍭 Пошаговый набор команд для реализации, если у вас не получилось самостоятельно
🍭 Заключение, в котором подводится итог пройденному заданию

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

Важно: никакой теории в материале нет. Поэтому сперва рекомендуем ознакомиться с основными концептами Kubernetes. Например, через официальную документацию.

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

P.S. Желаем вам отличного настроения, тёплой погоды, вкусных шашлыков и отличного времяпрепровождения на майских праздниках! 😊

Безопасен ли код, генерируемый ИИ?

Всем привет!

Кода, который генерируется ИИ становится всё больше. И его явно будет становиться больше.

Но безопасен ли этот код? Можно ли доверять ему «вслепую»?

Если вам интересны ответы на эти вопросы, то рекомендуем обратить внимание на вот эту статью.

В ней Автор берёт собственный проект, созданный LLM, подключает SonarCloud и получает 234 проблемы на первом же скане.

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

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

А что вы думаете по этому поводу? Проводили ли подобные эксперименты?

Trailmark: представление кода в виде графа

Всем привет!

Trail of Bits продолжают радовать интересными open-source проектами. В этот раз команда отдала в сообщество свою разработку – Trailmark.

Утилита позволяет превратить исходный код в графовое представление (обогащенный граф вызовов и структуры приложения), к которому можно делать вызовы.

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

Основной задачей, которую хотели решить ребята, был поиск ответа на вопрос: «Могут ли эти недоверенные входные данные достичь этого участка кода?». Не без использования ИИ, конечно же.

У Trailmark есть 3 основные «фазы» работы:
🍭 Parse. Задача фазы – получить информацию о функциях, методах, классах, структурах, интерфейсах и т.д.
🍭 Index. Реализация возможности быстрой работы с графом
🍭 Query. Верхнеуровневый API для взаимодействия с полученным графом

На текущий момент реализована поддержка 17 языков, среди которых Python, JS, TS, PHP, Ruby, C, C++, C#, Java, Golang и не только.

Установка, настройка, запуск, примеры результатов – всё это можно найти в GitHub-репозитории проекта.

Больше информации, включая сценарии использования (да-да, не обошлось без LLM) и skills от Trail of Bits, которые используют Trailmark, можно найти в статье.

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

MOAK: мать всех KEV

Всем привет!

Mean-time-to-Exploit изменялось от года году. Если раньше для генерации PoC на какую-либо CVE и её успешную эксплуатацию могли потребоваться месяцы, то сегодня время сократилось радикально.

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

Для наглядной демонстрации этой гипотезы был создан MOAK.

Он представляет из себя агентский workflow, который успешно эксплуатирует 98% CVE, которые есть в базе Known Exploited Vulnerabilities (KEV).

Без участия человека. Вообще.

Состоит он из следующих агентов:
🍭 Collector. От человека требуется лишь указать номер CVE, а дальше Collector соберёт нужную информацию
🍭 Researcher. Изучает CVE на основании данных, полученных от Collector. Анализирует патчи, идентифицирует уязвимые функции и т.д.
🍭 Environment Builder. Его задача – создание окружения, которое будет подходить под «условия» эксплуатации, определенные его «коллегами»
🍭 Exploiter. «Разработчик» необходимого для эксплуатации ПО и последующая эксплуатация с подтверждением
🍭 Judge. Проверяет, что все остальные агенты «качественно» провели свою работу

С «примерами» работы MOAK можно ознакомиться в разделе «CVE Dashboard» на сайте.

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

И ещё там есть много интересных статей по теме, на которые стоит обратить внимание.

100 DevOps Projects

Всем привет!

Скоро вторые майские и это значит, что самое время изучить что-то новое. На предыдущей неделе мы писали про 100 Kubernetes Assignments.

На этот раз предлагаем обратить ваше внимание на второй проект Автора – «100 DevOps Projects», который находится в приложении (~ 75 страниц).

В материале можно найти задания по таким темам, как:
🍭 CI/CD Pipelines, GitHub Actions, Jenkins, GitLab CI, ArgoCD и т.д.
🍭 Kubernetes & Container Orchestration. HPA/VPA, настройка кластера с kubeadm, сетевые политики и т.д.
🍭 Infrastructure as Code. Terraform, Ansible, AWS Cloud Formation и т.д.
🍭 Monitoring & Observability. Prometheus/Grafana, ELK Stack, Loki, Jaeger и т.д.
🍭 DevSecOps & Security. Управление секретами, использование SAST/DAST, защита цепочки поставки ПО и т.д.

И это далеко не всё, что предлагает Автор!

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

Как и в предыдущем материале – никакой воды, только задания, задания, задания и ещё раз задания.

Теории, кстати, тоже нет. Поэтому рекомендуем держать «под рукой» документацию на изучаемую технологию.

Поддержать Автора и сказать ему спасибо можно через вот этот вот пост.

P.S. А также желаем вам приятной погоды, солнечного света, попутного ветра и хорошо отдохнуть на грядущих выходных. С Праздником!!!

HPA, VPA или KEDA: что выбрать?

Всем привет!

Среднестатистический кластер Kubernetes утилизирует 13% CPU и 20% RAM (согласно данным отчёта CNCF 2024 Kubernetes Benchmark Report). 87% остаются «простаивать».

Чтобы устранить этот «недостаток» есть 3 autoscaler'a: HPA, VPA и KEDA. Каждый из них решает свою задачу или делает это чуть иначе, чем «сосед».

И тут встаёт вопрос: а какой из них выбрать? Как сделать потребление ресурсов максимально эффективным?

Чтобы найти свой ответ на этот вопрос можно обратиться к статье.

В ней Автор рассматривает:
🍭 Общие принципы работы каждого из представленных autoscaler’ов
🍭 Проводит небольшой сравнительный анализ
🍭 Приводит рекомендации о том, когда можно/нельзя их комбинировать
🍭 Предлагает алгоритм того, как выбрать то, что в большей степени подойдет вам

В статье много интересной статистики, примеров и пояснений того, что происходит «внутри». Да, не супер-технически-детально.

Но! Для базового погружения – в самый раз!

Practical Package Security: The Unofficial Guide

Всем привет!

По ссылке доступен материал от Wiz, в котором ребята рассматривают вопросы обеспечения ИБ при работе с пакетами и пакетными менеджерами.

Статья структурирована по разделам:
🍭 Easy(ier) Wins for Package Security. Не обновляться сразу, использовать lockfiles, анализировать пакеты в момент загрузки и т.д.
🍭 Protecting the Execution Environment. Использование эфемерной ИТ-инфраструктуры, соблюдение принципов Zero Trust
🍭 Controlling What Gets Installed. Использование proxy для загрузки пакетов, периодический анализ того, что хранится локально

Материал является «общим» и найти конкретных шагов по «безопасной настройке npm» не получится.

Однако! В статье собраны основные идеи, из которых можно сделать собственные наборы требований, адаптированные под конкретных технологии.

SmokedMeat: CI/CD Red Team Framework

Всем привет!

SmokedMeat – open-source проект, который представляет из себя CI/CD Red Team Framework. Сами Авторы описывают его так: «Like Metasploit, but for CI/CD pipelines».

Основная задача SmokedMeat – поиск уязвимостей (и их подтверждение) в конфигурациях конвейеров сборки.

Можно сказать, что он поддерживает «полный цикл»:
🍭 Analyze. Поиск уязвимостей в настройках конвейера сборки
🍭 Exploit. Эксплуатация найденных на предыдущем этапе уязвимостей
🍭 Post-exploit. Эксфильтрация данных
🍭 Pivot. Попытки расширения области своего присутствия

В текущей редакции поддерживается 6 CI/CD решений: GitHub Actions, GitLab CI, Azure DevOps, CircleCI, Jenkins, Bitbucket.

Для эксплуатации SmokedMeat может использовать следующие техники: PR, issue, comment, LOTP, workflow dispatch.

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

Важно(!): это не «пассивный» инструмент. Если вдруг захотите его использовать – лучше делать это с умом и всё перепроверить 😊