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-репозитории проекта.

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

Kunobi: централизованное управление Kubernetes

Всем привет!

Управление кластерами Kubernetes, их ресурсами и GitOps-практиками через единый удобный, быстрый и красивый web-интерфейс.

Примерно так можно описать Kunobi.

Из ключевых особенностей можно отметить:
🍭 Локальная установка. Никаких облаков, никаких «внешних соединений»
🍭 Работа с Flux и ArgoCD через привычный интерфейс
🍭 Возможность анализа Helm Releases для идентификации изменений
Создание кластеров через UI
🍭 Поддержка нужного ПО «из коробки» (Cert Manager, Prometheus, External Secrets и т.д.) и не только

Посмотреть на то, как это выглядит можно по ссылке. Представлены ролики по таким областям, как: Explore/Debug, GitOps, Flux, Workspaces/Presets.

Подробности про функциональные возможности можно узнать из документации на Kunobi.

И остался вопрос – «Сколько стоит?». Пока что ответ такой: «Free for everyone today. When we launch paid plans, you keep your free tier — no surprises, no credit card required».

Напишите своё мнение, если вам уже удалось воспользоваться инструментом: насколько он удобен и полезен?

Управление (утекшими) секретами при работе с VCS

Всем привет!

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

Но что делать и как быть? Начало ответа на этот вопрос можно найти в статье.

Автор рассматривает полный жизненный цикл того, что (не) надо делать при работе с git-репозиториями и чувствительной информацией.

Например:
🍭 Stop Hardcoding Credentials in Your Code (кто бы мог подумать). Про переменные окружения и работу с .*-ignore-файлами
🍭 Managing Secrets in Collaborative Environments. Использование Vault и его аналогов
🍭 Detecting Secrets Already in Your Git History. Сканирование репозиториев для выявления секретов
🍭 Review Findings and Remove False Positives. Оценка того, насколько сработки, полученные на предыдущем этапе, актуальны
🍭 Rewrite History with git-filter-repo. Инвалидация секретов, устранение секретов из кодовой базы

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

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

Kubernetes: что меняется от Dev до Production?

Всем привет!

Есть известная фраза, что «Kubernetes – это просто 5 бинарей».

С этим сложно спорить. Но это может породить некоторую иллюзию простоты.

Поначалу не задумываешься о то, насколько сильно один и тот же Kubernetes-кластер может преобразиться от Development-инсталляции до Production.

Именно этому и посвящена статья. В ней Автор описывает про что нужно знать/помнить, чтобы было не очень «больно» в процессе перехода между этими состояниями.

Он выделил 7 ключевых возможностей/потребностей:
🍭 Make Infrastructure Repeatable
🍭 Integrate The Product End-To-End
🍭 Move Delivery To GitOps
🍭 Restructure The Repository For Environments
🍭 Add Validation And Policy Guardrails и не только

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

И, получается, что у нас не просто «5 бинарей», а набор инструментов, процессов и специалистов, которые это всё поддерживают.

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

Читается легко и непринуждённо, рекомендуем!

БеКон 2026: вкуснейшие ингредиенты и лучшие рецепты!

Всем привет!

Кто-то ждёт лето, кто-то тёплую погоду, кто-то – долгожданный отпуск, а кто-то…

Конечно же единственную конференцию по безопасности контейнеров и контейнерных сред – БеКон!

В этом году команда Luntry уже в 4-ый раз собирает всех неравнодушных к тематике защиты контейнеров в Москве, 2-ого июня 2026 года!

На этот раз нас ждут сразу несколько направлений – Ингредиенты (про технологии) и Рецепты (про людей и процессы).

Спикеры из Axiom JDK, ГК АСТРА, Т-Банка, Альфа-Банка, Luntry, Инфосистемы Джет и не только будут делиться своим опытом.

Помимо этого, посетителям будет доступна выставочная зона, в которой производители ИБ и ИТ-решений будут рады пообщаться: Штурвал, Deckhouse, Orion Soft, Hexway, Axel PRO и многие другие!

И, конечно же, будет ещё один «Секретный доклад». Кто помнит, что было представлено в том году и насколько оно вам понравилось – пишите в комментариях!

Детальную информацию о мероприятии, включая описание программы, можно найти на официальном сайте.

До встречи на БеКоне! ❤️❤️❤️

Cgroups: что это такое и зачем они нужны?

Всем привет!

Если упростить, то cgroups - механизм ядра Linux, который позволяет управлять вычислительными ресурсами.

Казалось бы, всё просто! Но это не совсем так.

Если вам хочется более подробно ознакомиться с тем, что это такое и как это устроено, то рекомендуем ознакомиться со статьей (она достаточно объёмная).

В ней Автор рассказывает о:
🍭 Том, что такое cgroups и как они устроены
🍭 Том, как происходит управление cgoup’ами, что такое controllers
🍭 Наследовании cgroups и их иерархической структуре
🍭 Недостатках первой версии (cgroups) и причинах появлении второй (cgroupsv2)
🍭 Сравнительном анализе разных версий cgroups и не только

Помимо теории в статье есть практические примеры: создание собственной cgroup’ы, блокирование frok-bomb и т.д..

А ещё – немного истории о том, как этот механизм развивался со временем!

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

Git-pkgs proxy: защита от атак на цепочку поставок

Всем привет!

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

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

Но это случается не сразу и может занимать дни, а то и недели. В текущих реалиях, когда time-to-exploit радикально сокращается благодаря ИИ, это может быть очень критичным.

Для того, чтобы хоть как-то систематизировать и контролировать процесс обновлений, можно обратить своё внимание на проект git-pkgs proxy.

Суть крайне простая: он представляет из себя proxy, который не даёт обновиться на новую версию пакета в течение X дней.

Например, если lodash обновилась до версии 4.18.0, то в вашей сборке всё ещё будет использоваться версия 4.17.21 в течение 3-х дней.

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

Утилита работает более чем с 20-ю индексами, среди которых npm, PyPi, Conda, Maven, Debian, Helm и не только.

Да, не все они «полностью» готовы, но Автор собирается развивать проект.

А как вы работаете с проблемой отсутствия контроля обновления зависимостей?

Kubernetes: CPU Req/Lim на практике!

Всем привет!

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

Однако, спустя годы, всё равно появляются вопросы и разногласия о том, как это делать и что лучше (не) использовать.

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

В ней Автор описывает:
🍭 Как работает распределение ресурсов CPU (дада, те самые cgroups, про которые мы писали недавно)
🍭 Как работает CPU Sharing в Kubernetes
🍭 Что «скрывают» за собой CPU Requests и Limits
🍭 Как, когда и почему появляется CPU Throttling

И в завершении Автор ещё раз рассуждает на тему – нужны ли (и, если да, то когда) CPU Limits или же без них лучше?

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

А что вы думаете по этому поводу?

MCP Hardening Guide

Всем привет!

Сегодня хотим предложить вам чтение на выходной! Статью, в которой собраны рекомендации о настройках безопасности при использовании MCP (~ 16 минут).

Авторы рассматривают 6 основных разделов:
🍭 Network Isolation
🍭 Dependency and Supply Chain Security
🍭 Secrets Management at Runtime
🍭 TLS Configuration Hardening
🍭 Runtime Behavioral Monitoring
🍭 Pre-deployment Security Gate

Для каждого раздела приводится краткое описание, небольшие примеры и перечень требований, по которым можно сделать самопроверку (verification checklist).

Kubernetes RBAC Generator

Всем привет!

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

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

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

При помощи неё можно:
🍭 Генерировать роли с минимальными правами, необходимыми ресурсу
🍭 Делать это постоянно, т.к. она работает в качестве operator’a, который присутствует в кластере
🍭 Использовать GitOps-подходы за счет использования сгенерированных CRD
🍭 Выявлять drift в настройках RBAC и не только

Сама по себе Audicia ничего не меняет в кластере, а только генерирует манифесты для ролей. Не требует доступа к секретам и иной чувствительной информации.

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

Prempti: Falco для AI Coding Agents

Всем привет!

Falco – крайне известный инструмент в мире защиты сред контейнеризации. Он позволяет анализировать поведение контейнеров.

Теперь с его помощью можно узнать больше о том, какие действия на самом деле реализуют AI Coding Agents.

Именно это и делает Prempti, использующая Falco «под капотом».

Она позволяет:
🍭 Перехватывать запросы к инструментам в режиме реального времени (shell-команды, работа с файлами, анализ вызова MCP)
🍭 Принимать решения о том, что делать – разрешить, запретить, уточнить
🍭 Получать полный audit trail о том, что происходило при работе агента
🍭 Добавлять собственные правила для анализа (аналогичные правилам Falco)

Работает она просто: в случае, когда coding agent пытается использовать tool, Prempti перехватывает вызов перед его выполнением, анализирует и выдаёт вердикт.

Кстати, она может работать как в enforce, так и в monitor режимах. Подробнее об утилите можно прочесть в GitHub-репозитории.

Важно(!): проект находится в стадии активной разработки, поэтому что-то может (не) работать, а что-то может сильно меняться от релиза к релизу.