Доверие к зависимостям в контейнерах
Всем привет!
Использование зависимостей может как ускорить разработку, так и расширить поверхность атаки.
Ведь используемый пакет может запускать код во время установки, сборки, тестов или во время работы приложения.
И примеров подобных случаев сейчас очень и очень много. Есть разные способы контроля – контроль сетевого доступа, использование доверенных реестров, композиционный анализ и т.д.
Однако, Автора статьи заинтересовал другой вопрос. «А можно ли что-то сделать силами обычного контейнера?».
Без использования Sidecar, без использования CNI или ServiceMesh и иных способов защиты.
Ответом стал nono – «песочница», которая может контролировать (не) допустимые действия внутри контейнера.
Для проверки Автор реализовал сценарий:
🍭 Создал небольшое JS-приложение
🍭 Добавил туда «вредоносную» зависимость, которая эмулировала эксфильтрацию секретов
🍭 Подготовил nono-profile, в котором определил допустимые сетевые взаимодействия
🍭 Проверил то, что получилось с «обычным» образом и с «nono-образом»
Получилось так, что разрешённое поведение отработало «как надо», а попытка доступа к недоверенному ресурсу была заблокирована.
И это лишь небольшой пример того, что может сделать nono для контроля безопасности контейнеров или агентов, которые в них запускаются.
Нюансом подхода может быть масштабирование – создание разных профилей, их распространение и применение.
Однако, это может быть вполне полезно в качестве «ещё одного слоя защиты» в дополнение к используемым средствам.
Всем привет!
Использование зависимостей может как ускорить разработку, так и расширить поверхность атаки.
Ведь используемый пакет может запускать код во время установки, сборки, тестов или во время работы приложения.
И примеров подобных случаев сейчас очень и очень много. Есть разные способы контроля – контроль сетевого доступа, использование доверенных реестров, композиционный анализ и т.д.
Однако, Автора статьи заинтересовал другой вопрос. «А можно ли что-то сделать силами обычного контейнера?».
Без использования Sidecar, без использования CNI или ServiceMesh и иных способов защиты.
Ответом стал nono – «песочница», которая может контролировать (не) допустимые действия внутри контейнера.
Для проверки Автор реализовал сценарий:
🍭 Создал небольшое JS-приложение
🍭 Добавил туда «вредоносную» зависимость, которая эмулировала эксфильтрацию секретов
🍭 Подготовил nono-profile, в котором определил допустимые сетевые взаимодействия
🍭 Проверил то, что получилось с «обычным» образом и с «nono-образом»
Получилось так, что разрешённое поведение отработало «как надо», а попытка доступа к недоверенному ресурсу была заблокирована.
И это лишь небольшой пример того, что может сделать nono для контроля безопасности контейнеров или агентов, которые в них запускаются.
Нюансом подхода может быть масштабирование – создание разных профилей, их распространение и применение.
Однако, это может быть вполне полезно в качестве «ещё одного слоя защиты» в дополнение к используемым средствам.
Medium
Zero-Day Runtime Isolation for Containers: Rethinking Dependency Trust
Package managers accelerated software development, but also expanded the attack surface. Runtime isolation reduces execution risks.
❤2
KuBeer Talks #4: все московское (и не только) сообщество кубера будет там
5 ноября в 19:00 K8s-комьюнити проведет юбилейный KuBeer Talks. Место встречи — бар Spaten Haus в Москве.
Формат предполагает короткие технические доклады о наболевшем, живые обсуждения и нетворкинг с единомышленниками. А еще в честь важной даты организаторы готовят сюрпризы для участников)
В программе:
🍭 Екатерина Низовцева — «Опыт работы с VTEP-схемой в Cilium»
🍭 Артём Горячев — «Закон Гудхарта для бекапов K8s»
🍭 Алексей Свиридкин — «Ревью кода в эпоху нейрослопа»
🍭 Открытый микрофон — для всех, кому есть чем поделиться
Количество мест ограничено. Вход по предварительной регистрации.
5 ноября в 19:00 K8s-комьюнити проведет юбилейный KuBeer Talks. Место встречи — бар Spaten Haus в Москве.
Формат предполагает короткие технические доклады о наболевшем, живые обсуждения и нетворкинг с единомышленниками. А еще в честь важной даты организаторы готовят сюрпризы для участников)
В программе:
🍭 Екатерина Низовцева — «Опыт работы с VTEP-схемой в Cilium»
🍭 Артём Горячев — «Закон Гудхарта для бекапов K8s»
🍭 Алексей Свиридкин — «Ревью кода в эпоху нейрослопа»
🍭 Открытый микрофон — для всех, кому есть чем поделиться
Количество мест ограничено. Вход по предварительной регистрации.
🔥5🥰4❤3❤🔥1👎1
DockLog: просмотр логов контейнеров и не только
Всем привет!
DockLog – простая утилита, которая позволяет удобно выполнять повседневные операции с контейнерами. Работает как с Docker, так и с Kubernetes.
Притом что можно выбирать – Docker, Kubernetes или сразу оба варианта.
Всё взаимодействие реализовано через графический web-интерфейс.
При помощи DockLog можно:
🍭 Получать сводную информацию о запущенных контейнерах
🍭 Смотреть логи контейнеров
🍭 Управлять контейнерами (запускать, останавливать, удалять и т.д.)
🍭 Получать информацию по используемым вычислительным мощностям
🍭 Отправлять уведомления
Дополнительно реализовано управление доступом с использованием ролевой модели.
Подробнее про DockLog можно прочесть в GitHub-репозитории или в документации на официальном сайте.
Всем привет!
DockLog – простая утилита, которая позволяет удобно выполнять повседневные операции с контейнерами. Работает как с Docker, так и с Kubernetes.
Притом что можно выбирать – Docker, Kubernetes или сразу оба варианта.
Всё взаимодействие реализовано через графический web-интерфейс.
При помощи DockLog можно:
🍭 Получать сводную информацию о запущенных контейнерах
🍭 Смотреть логи контейнеров
🍭 Управлять контейнерами (запускать, останавливать, удалять и т.д.)
🍭 Получать информацию по используемым вычислительным мощностям
🍭 Отправлять уведомления
Дополнительно реализовано управление доступом с использованием ролевой модели.
Подробнее про DockLog можно прочесть в GitHub-репозитории или в документации на официальном сайте.
GitHub
GitHub - dockloghq/docklog: DockLog - Real-time Docker log viewer with RBAC, WebSocket streaming, and advanced filtering.
DockLog - Real-time Docker log viewer with RBAC, WebSocket streaming, and advanced filtering. - dockloghq/docklog
От ноутбука DevOps до прода: как атакуют инфраструктуру разработки
Всем привет!
За последние пару дней произошло сразу два интересных инцидента, связанных с безопасностью инфраструктуры разработки:
🚨 Binance сообщила об атаке, которая, предположительно, началась с компрометации ноутбука DevOps-инженера. Злоумышленники получили доступ к сервисному контейнеру и инициировали несанкционированные транзакции. Предварительная оценка масштаба инцидента - $6,3 млрд (не подтверждённая сумма потерь).
🚨 Claude Code - в маркетплейсе расширений Cursor обнаружили вредоносную версию 2.1.313, которая пыталась установить SSH-бэкдор, добавить ключ злоумышленника и обеспечить постоянный доступ к рабочей станции разработчика.
Казалось бы, разные истории. Но обе заставляют задуматься насколько защищена инфраструктура, через которую создаётся и поставляется ПО.
GitLab, Jenkins, CI/CD-раннеры, Registry, Kubernetes - всё это связано между собой через токены, сервисные учётные записи и доверенные интеграции.
А значит, компрометация одного компонента потенциально может стать отправной точкой для атаки на всю цепочку поставки. И даже идеально настроенные SAST, DAST и SCA здесь не помогут.
10 ноября проведём вебинар «От ноутбука DevOps до прода: как атакуют инфраструктуру разработки».
На нём вместе с экспертами «Инфосистемы Джет» разберём:
🔍 Как злоумышленник может пройти путь от рабочего места разработчика до production
🔍 Какие ошибки в настройках VCS, CI/CD и Registry позволяют развивать атаку
🔍 Почему безопасность кода ≠ безопасность инфраструктуры разработки
🔍 Как искать, проверять и устранять потенциальные цепочки атак
Будет технический разбор сценариев, практические подходы к аудиту и рекомендации по защите. Без абстрактных страшилок и общих рассуждений!
📅 Когда: 10 ноября 2026 года
⏱️ Продолжительность: 60 минут
💻 Формат: онлайн
👉 Регистрация на вебинар
Присоединяйтесь! Будет интересно
Всем привет!
За последние пару дней произошло сразу два интересных инцидента, связанных с безопасностью инфраструктуры разработки:
🚨 Binance сообщила об атаке, которая, предположительно, началась с компрометации ноутбука DevOps-инженера. Злоумышленники получили доступ к сервисному контейнеру и инициировали несанкционированные транзакции. Предварительная оценка масштаба инцидента - $6,3 млрд (не подтверждённая сумма потерь).
🚨 Claude Code - в маркетплейсе расширений Cursor обнаружили вредоносную версию 2.1.313, которая пыталась установить SSH-бэкдор, добавить ключ злоумышленника и обеспечить постоянный доступ к рабочей станции разработчика.
Казалось бы, разные истории. Но обе заставляют задуматься насколько защищена инфраструктура, через которую создаётся и поставляется ПО.
GitLab, Jenkins, CI/CD-раннеры, Registry, Kubernetes - всё это связано между собой через токены, сервисные учётные записи и доверенные интеграции.
А значит, компрометация одного компонента потенциально может стать отправной точкой для атаки на всю цепочку поставки. И даже идеально настроенные SAST, DAST и SCA здесь не помогут.
10 ноября проведём вебинар «От ноутбука DevOps до прода: как атакуют инфраструктуру разработки».
На нём вместе с экспертами «Инфосистемы Джет» разберём:
🔍 Как злоумышленник может пройти путь от рабочего места разработчика до production
🔍 Какие ошибки в настройках VCS, CI/CD и Registry позволяют развивать атаку
🔍 Почему безопасность кода ≠ безопасность инфраструктуры разработки
🔍 Как искать, проверять и устранять потенциальные цепочки атак
Будет технический разбор сценариев, практические подходы к аудиту и рекомендации по защите. Без абстрактных страшилок и общих рассуждений!
📅 Когда: 10 ноября 2026 года
⏱️ Продолжительность: 60 минут
💻 Формат: онлайн
👉 Регистрация на вебинар
Присоединяйтесь! Будет интересно
Mts-link.ru
От ноутбука DevOps'a до прода: как атакуют инфраструктуру разработки
Атака на Binance с оценкой ущерба в $6,3 млрд. Вредоносный экземпляр расширения Claude Code с SSH-бэкдором.
Две свежие новости и один важный вопрос - насколько защищена инфраструктура, в которой создаётся и поставляется ваше ПО?
GitLab, Jenkins, CI/CD-раннеры…
Две свежие новости и один важный вопрос - насколько защищена инфраструктура, в которой создаётся и поставляется ваше ПО?
GitLab, Jenkins, CI/CD-раннеры…
10🔥4🥰4❤2🤡1
Infra-Bench: оценка ИИ-агентов
Всем привет!
Infra-Bench – open-source проект, который представляет из себя набор тестов для оценки того, насколько ИИ-агенты пригодны для решения задач, связанных с ИТ-инфраструктурой.
На текущий момент есть тесты для Kubernetes.
22 «легких» задачи, 27 «средних» и 22 «сложных».
Примеры задач:
🍭 Легкая. Восстановить «потерянный»
🍭 Легкая. Изменить конфигурацию роли, добавив в неё необходимые глаголы
🍭 Средняя. Восстановить возможность отображения логов в Grafana
🍭 Средняя. Создать ресурс на узле, который соответствует определённым требованиям
🍭 Сложная. Сделать
🍭 Сложная. Восстановить работоспособность приложения
Для каждой задачи приводится инструкция о том, что надо сделать, ожидаемый результат и набор тестов, подтверждающих выполнение задачи.
С результатами выполнения задач (GPT-5.5, Opus-4.6, Sonnet-4.6, Gemini-3, Kimi-k2-5 и т.д.) можно ознакомиться по ссылке.
На ресурсе представлена общая информация по выполненным задачам, а также детализация по каждой модели, включая среднее время выполнения задач.
Всем привет!
Infra-Bench – open-source проект, который представляет из себя набор тестов для оценки того, насколько ИИ-агенты пригодны для решения задач, связанных с ИТ-инфраструктурой.
На текущий момент есть тесты для Kubernetes.
22 «легких» задачи, 27 «средних» и 22 «сложных».
Примеры задач:
🍭 Легкая. Восстановить «потерянный»
ConfigMap🍭 Легкая. Изменить конфигурацию роли, добавив в неё необходимые глаголы
🍭 Средняя. Восстановить возможность отображения логов в Grafana
🍭 Средняя. Создать ресурс на узле, который соответствует определённым требованиям
🍭 Сложная. Сделать
drain узла, сохранив работоспособность всех ресурсов🍭 Сложная. Восстановить работоспособность приложения
Для каждой задачи приводится инструкция о том, что надо сделать, ожидаемый результат и набор тестов, подтверждающих выполнение задачи.
С результатами выполнения задач (GPT-5.5, Opus-4.6, Sonnet-4.6, Gemini-3, Kimi-k2-5 и т.д.) можно ознакомиться по ссылке.
На ресурсе представлена общая информация по выполненным задачам, а также детализация по каждой модели, включая среднее время выполнения задач.
GitHub
GitHub - kubeply/infra-bench: Real-world infrastructure tasks to evaluate AI agents, starting with Kubernetes.
Real-world infrastructure tasks to evaluate AI agents, starting with Kubernetes. - kubeply/infra-bench
Как реализовать управление секретами ничего не сломав?
Всем привет!
Когда вопрос вступает о правильном управлении секретами, то кажется, что всё очень просто. Рано или поздно появляется Vault (или его аналоги) и кажется, что проблема решена.
Но всё может быть не так однозначно. Ведь «нельзя просто взять и поставить Vault».
Могут возникнуть разные осложнения: один и тот же секрет может использоваться в разных сервисах, нет полной видимости того, какие секреты где используются и т.д. Именно этим нюансам и посвящены статьи.
В первой части Автор рассматривает общую проблематику, которая заключается даже не в том, что секреты не ротируются, а в том, что отсутствует контроль процесса как таковой.
Т.е. нет понимания кто является владельцем секрета, где он точно используется, что произойдёт, если его отозвать и т.д.
Вторая часть рассматривает разницу между секретами и токенами и почему они не «просто элементы конфигурации», а часть самой системы.
Это тоже привносит некоторые «особенности» в задачу управления секретами. Можно рассматривать токены и секреты как некие «зависимости», которые со временем распространяются по всей системе.
Они появляются в разных ресурсах, конвейерах, системах мониторинга и т.д. Некоторые из них являются уникальными, некоторые – дублями. Иногда бывает так, что у секрета есть «потребитель», про которого уже никто и не помнит.
Третья статья описывает подход, который позволяет учесть все нюансы и реализовать переход к процессному управлению секретами.
В ней Автор рассматривает несколько верхнеуровневых этапов: от инвентаризации до использования динамических секретов.
Статьи достаточно объёмные и хорошо раскрывают как проблематику, так и возможное решение.
Рекомендуем к изучению!
Всем привет!
Когда вопрос вступает о правильном управлении секретами, то кажется, что всё очень просто. Рано или поздно появляется Vault (или его аналоги) и кажется, что проблема решена.
Но всё может быть не так однозначно. Ведь «нельзя просто взять и поставить Vault».
Могут возникнуть разные осложнения: один и тот же секрет может использоваться в разных сервисах, нет полной видимости того, какие секреты где используются и т.д. Именно этим нюансам и посвящены статьи.
В первой части Автор рассматривает общую проблематику, которая заключается даже не в том, что секреты не ротируются, а в том, что отсутствует контроль процесса как таковой.
Т.е. нет понимания кто является владельцем секрета, где он точно используется, что произойдёт, если его отозвать и т.д.
Вторая часть рассматривает разницу между секретами и токенами и почему они не «просто элементы конфигурации», а часть самой системы.
Это тоже привносит некоторые «особенности» в задачу управления секретами. Можно рассматривать токены и секреты как некие «зависимости», которые со временем распространяются по всей системе.
Они появляются в разных ресурсах, конвейерах, системах мониторинга и т.д. Некоторые из них являются уникальными, некоторые – дублями. Иногда бывает так, что у секрета есть «потребитель», про которого уже никто и не помнит.
Третья статья описывает подход, который позволяет учесть все нюансы и реализовать переход к процессному управлению секретами.
В ней Автор рассматривает несколько верхнеуровневых этапов: от инвентаризации до использования динамических секретов.
Статьи достаточно объёмные и хорошо раскрывают как проблематику, так и возможное решение.
Рекомендуем к изучению!
Hackernoon
If Rotating Secrets Requires a Ticket, It’s Not a Process — It’s a Problem
A practical look at secrets, tokens, and access in Kubernetes. Why manual rotation is a symptom of a deeper control problem in MLOps platforms.
1❤10
Секреты в образах контейнеров
Всем привет!
Допустим, мы случайно разместили секрет в git-репозитории. Поняли, что сделали и удалили его.
Вроде бы всё в порядке… Но секрет всё равно останется в git-истории и его можно будет найти.
А что, если подобное произойдет при работе с образом контейнера? Например, мы добавляем секрет в один из слоёв, а потом удаляем.
Можно ли будет его найти? Если коротко, то «Да». Если хочется подробностей, то они есть в этой небольшой статье.
В ней Автор делает следующее:
🍭 Добавляет секрет в файл, который находится в образе контейнера
🍭 Удаляет секрет
🍭 Анализирует секрет с помощью
🍭 Уточняет данные путём анализа слоев образа
Статья очень маленькая, но затрагивает интересную тему. Важно помнить, что и у образа есть «своя история», в которой может быть много всего интересного.
Завершает материал набор рекомендаций о том, как лучше работать с секретами при создании образов контейнеров.
Всем привет!
Допустим, мы случайно разместили секрет в git-репозитории. Поняли, что сделали и удалили его.
Вроде бы всё в порядке… Но секрет всё равно останется в git-истории и его можно будет найти.
А что, если подобное произойдет при работе с образом контейнера? Например, мы добавляем секрет в один из слоёв, а потом удаляем.
Можно ли будет его найти? Если коротко, то «Да». Если хочется подробностей, то они есть в этой небольшой статье.
В ней Автор делает следующее:
🍭 Добавляет секрет в файл, который находится в образе контейнера
🍭 Удаляет секрет
🍭 Анализирует секрет с помощью
docker inspect🍭 Уточняет данные путём анализа слоев образа
Статья очень маленькая, но затрагивает интересную тему. Важно помнить, что и у образа есть «своя история», в которой может быть много всего интересного.
Завершает материал набор рекомендаций о том, как лучше работать с секретами при создании образов контейнеров.
Medium
Your Docker Secrets Are Not Gone — They’re Just Hidden
Let me start with a scenario that I have seen happen more than once. A developer writes a Dockerfile, adds a secret to set something up…
❤6
Freelens Pod File Browser
Всем привет!
Если вы используете Freelens в повседневной работе и иногда нужно как-то взаимодействовать с файлами, расположенными в контейнерах, то Freelens Pod File Browser может упростить задачу.
Он представляет из себя плагин, который предоставляет доступ к файлам внутри контейнера через графический интерфейс Freelens.
С его помощью можно:
🍭 Осуществлять навигацию по файловой системе контейнера
🍭 Открывать и редактировать файлы
🍭 Загружать/Скачивать файлы
🍭 «Переключаться» между контейнерами в
Устанавливается очень просто. Подробности (включая скриншоты того, как это выглядит) можно найти в GitHub-репозитории или на сайте плагина.
Всем привет!
Если вы используете Freelens в повседневной работе и иногда нужно как-то взаимодействовать с файлами, расположенными в контейнерах, то Freelens Pod File Browser может упростить задачу.
Он представляет из себя плагин, который предоставляет доступ к файлам внутри контейнера через графический интерфейс Freelens.
С его помощью можно:
🍭 Осуществлять навигацию по файловой системе контейнера
🍭 Открывать и редактировать файлы
🍭 Загружать/Скачивать файлы
🍭 «Переключаться» между контейнерами в
pod и не толькоУстанавливается очень просто. Подробности (включая скриншоты того, как это выглядит) можно найти в GitHub-репозитории или на сайте плагина.
GitHub
GitHub - masoudei/freelens-pod-filebrowser: Freelens Pod Filesystem Browser Extention
Freelens Pod Filesystem Browser Extention. Contribute to masoudei/freelens-pod-filebrowser development by creating an account on GitHub.
👍1
Пакетные менеджеры и контроль целостности
Всем привет!
Кажется, что контроль целостности начал или начинает доминировать над контролем конфиденциальности и доступности.
Особенно это хорошо видно при работе с любыми типами «зависимостей». В том числе и теми, которые используются при разработке ПО.
Автора статьи заинтересовал вопрос: «А что делают различные пакетные менеджеры для того, чтобы убедиться в том, что скачиваемый пакет не был изменён?».
Для этого он выбрал 25 разных пакетных менеджеров, сделал небольшую «лабораторную среду» и решил изучить вопрос.
Он проанализировал такие возможности как: использование hash-значений, применение электронной подписи (на стороне репозитория, на стороне разработчика) и иные возможности.
Что получилось, возможности пакетных менеджеров по контролю целостности – всё это можно найти в статье.
И ещё ряд весьма интересных случаев. Например, когда hash-значение присутствует, но не используется для контроля целостности.
Да, менеджер скачает пакет, уточнит, что hash-значение не совпадает, и… установит пакет! И это документированное поведение по умолчанию.
Рекомендуем всем тем, кому интересна тема защиты цепочки поставок и кто хочет чуть лучше разобраться в механизмах работы пакетных менеджеров.
Всем привет!
Кажется, что контроль целостности начал или начинает доминировать над контролем конфиденциальности и доступности.
Особенно это хорошо видно при работе с любыми типами «зависимостей». В том числе и теми, которые используются при разработке ПО.
Автора статьи заинтересовал вопрос: «А что делают различные пакетные менеджеры для того, чтобы убедиться в том, что скачиваемый пакет не был изменён?».
Для этого он выбрал 25 разных пакетных менеджеров, сделал небольшую «лабораторную среду» и решил изучить вопрос.
Он проанализировал такие возможности как: использование hash-значений, применение электронной подписи (на стороне репозитория, на стороне разработчика) и иные возможности.
Что получилось, возможности пакетных менеджеров по контролю целостности – всё это можно найти в статье.
И ещё ряд весьма интересных случаев. Например, когда hash-значение присутствует, но не используется для контроля целостности.
Да, менеджер скачает пакет, уточнит, что hash-значение не совпадает, и… установит пакет! И это документированное поведение по умолчанию.
Рекомендуем всем тем, кому интересна тема защиты цепочки поставок и кто хочет чуть лучше разобраться в механизмах работы пакетных менеджеров.
The Trail of Bits Blog
Package managers have an integrity problem
I tested 25 of the most popular package managers to check whether they detect a compromised package repository injecting malicious code into legitimate packages. Only two verified the integrity of every package they downloaded.
🔥7👍5
Журналирование в облачных средах: Kubernetes
Всем привет!
Чем больше кластеров Kubernetes вы держите в облаках, тем сложнее понять, как получить целостную картину происходящего в них.
Какие журналы собирать? Что является источником данных? Что надо сделать, чтобы эти данные получить?
Чтобы разобраться в этих вопросах для кластеров Kubernetes, работающих в облаках, можно обратиться к статье.
В ней Автор разбирает следующие «уровни»:
🍭 Audit Logs
🍭 Control Plane Logs
🍭 Node/Container Logs
🍭 Runtime Events
🍭 Network Flows
🍭 Kubernetes Events
Для каждого уровня он кратко описывает какую информацию и как можно получить, на что стоит обращать внимание.
Дополнительно в статье представлено много крайне полезных ссылок, которые позволяют глубже погрузиться в детали.
Всем привет!
Чем больше кластеров Kubernetes вы держите в облаках, тем сложнее понять, как получить целостную картину происходящего в них.
Какие журналы собирать? Что является источником данных? Что надо сделать, чтобы эти данные получить?
Чтобы разобраться в этих вопросах для кластеров Kubernetes, работающих в облаках, можно обратиться к статье.
В ней Автор разбирает следующие «уровни»:
🍭 Audit Logs
🍭 Control Plane Logs
🍭 Node/Container Logs
🍭 Runtime Events
🍭 Network Flows
🍭 Kubernetes Events
Для каждого уровня он кратко описывает какую информацию и как можно получить, на что стоит обращать внимание.
Дополнительно в статье представлено много крайне полезных ссылок, которые позволяют глубже погрузиться в детали.
Marco Lancini's Blog
Security Logging in Cloud Environments - Kubernetes | Marco Lancini's Blog
How to design a state of the art security logging platform for Kubernetes clusters, managed (EKS, GKE) or self-managed.
❤2
DevSecOps Talks
От ноутбука DevOps до прода: как атакуют инфраструктуру разработки Всем привет! За последние пару дней произошло сразу два интересных инцидента, связанных с безопасностью инфраструктуры разработки: 🚨 Binance сообщила об атаке, которая, предположительно,…
Уже завтра: как атакуют инфраструктуру разработки?
Всем привет!
Напоминаем, что уже завтра, 10 ноября, проведём вебинар «От ноутбука DevOps'а до прода: как атакуют инфраструктуру разработки». 🚨
Можно настроить SAST, DAST, SCA и другие проверки безопасности кода. Но что, если злоумышленник атакует не само приложение, а инфраструктуру, через которую оно создаётся и попадает в production?
Именно об этом и поговорим!
📅 Когда: 10 ноября 14:00
⏱️ Продолжительность: 60 минут
💻 Формат: онлайн
👉 Регистрация на вебинар
Если пропустили первый анонс - самое время зарегистрироваться! Присоединяйтесь! 😉
Всем привет!
Напоминаем, что уже завтра, 10 ноября, проведём вебинар «От ноутбука DevOps'а до прода: как атакуют инфраструктуру разработки». 🚨
Можно настроить SAST, DAST, SCA и другие проверки безопасности кода. Но что, если злоумышленник атакует не само приложение, а инфраструктуру, через которую оно создаётся и попадает в production?
Именно об этом и поговорим!
📅 Когда: 10 ноября 14:00
⏱️ Продолжительность: 60 минут
💻 Формат: онлайн
👉 Регистрация на вебинар
Если пропустили первый анонс - самое время зарегистрироваться! Присоединяйтесь! 😉
Mts-link.ru
От ноутбука DevOps'a до прода: как атакуют инфраструктуру разработки
Атака на Binance с оценкой ущерба в $6,3 млрд. Вредоносный экземпляр расширения Claude Code с SSH-бэкдором.
Две свежие новости и один важный вопрос - насколько защищена инфраструктура, в которой создаётся и поставляется ваше ПО?
GitLab, Jenkins, CI/CD-раннеры…
Две свежие новости и один важный вопрос - насколько защищена инфраструктура, в которой создаётся и поставляется ваше ПО?
GitLab, Jenkins, CI/CD-раннеры…
🔥4❤3👏2👎1
Масштабирование Security Review: опыт Postman
Всем привет!
Большинство сталкиваются с очень похожими вопросами.
Например, «Как сделать так, чтобы при большом количестве релизов информационная безопасность не стала бутылочным горлышком?».
Команда Postman – не исключение. Они начинали с того, что Jira-задача для ИБ появлялась тогда, когда новый релиз доходил до staging.
Это было не очень удобно: AppSec-команда не привлекалась во время работы над релизом, многие находки были блокирующими (а релиз ведь «почти готов»!), какого-то единого процесса по обмену информацией между командой разработки и AppSec не было.
Поэтому ребята решили всё переделать. О том, что у них получилось, можно прочесть в статье.
Если кратко, то они перешли на Security Review v2:
🍭 AppSec-команда стала привлекаться гораздо раньше
🍭 Централизация информации по всем задачам, которые имеют отношение к ИБ в релизе (Application Security Review, ASR)
🍭 Опросники, которые помогают AppSec-команде принимать решения. Опросники распространяются как на ASR, так и на отдельные PR
🍭 Наличие общего плана действий по ИБ применительно к релизу (требования, покрытие тестами, сбор свидетельств и т.д.)
🍭 Адаптация подхода в зависимости от значимости сервиса и релиза (не все они идут по «одним рельсам», многое завязано на критичности и значимости изменений)
Вроде бы ничего сверхъестественного, но такой подход значительно помог команде Postman.
Сокращение времени выпуска релизов, оптимизация трудозатрат разработки и AppSec-специалистов и не только.
Больше подробностей о том, что и как ребята реализовали, включая «планы на будущее», можно найти в статье.
Всем привет!
Большинство сталкиваются с очень похожими вопросами.
Например, «Как сделать так, чтобы при большом количестве релизов информационная безопасность не стала бутылочным горлышком?».
Команда Postman – не исключение. Они начинали с того, что Jira-задача для ИБ появлялась тогда, когда новый релиз доходил до staging.
Это было не очень удобно: AppSec-команда не привлекалась во время работы над релизом, многие находки были блокирующими (а релиз ведь «почти готов»!), какого-то единого процесса по обмену информацией между командой разработки и AppSec не было.
Поэтому ребята решили всё переделать. О том, что у них получилось, можно прочесть в статье.
Если кратко, то они перешли на Security Review v2:
🍭 AppSec-команда стала привлекаться гораздо раньше
🍭 Централизация информации по всем задачам, которые имеют отношение к ИБ в релизе (Application Security Review, ASR)
🍭 Опросники, которые помогают AppSec-команде принимать решения. Опросники распространяются как на ASR, так и на отдельные PR
🍭 Наличие общего плана действий по ИБ применительно к релизу (требования, покрытие тестами, сбор свидетельств и т.д.)
🍭 Адаптация подхода в зависимости от значимости сервиса и релиза (не все они идут по «одним рельсам», многое завязано на критичности и значимости изменений)
Вроде бы ничего сверхъестественного, но такой подход значительно помог команде Postman.
Сокращение времени выпуска релизов, оптимизация трудозатрат разработки и AppSec-специалистов и не только.
Больше подробностей о том, что и как ребята реализовали, включая «планы на будущее», можно найти в статье.
Postman Blog
How We Scaled Security Reviews Without Slowing Down Engineering
Learn how Postman scaled its security review process without slowing engineering velocity — moving from manual VAPT-driven reviews to a risk-based, automation-first model that freed up weeks of AppSec capacity and unblocked 1 in 4 releases automatically.
OWASP Xpsd
Всем привет!
Ещё один проект под эгидой OWASP. На этот раз он посвящен анализу достижимости уязвимостей, которые выявляются в рамках композиционного анализа.
Т.е. он даёт ответ на вопрос: «Могут ли входные данные, передаваемые ПО, вызвать уязвимый код в этом репозитории?».
Работает это примерно так:
🍭 На вход Xpsd передаётся одна конкретная CVE или целый отчёт
🍭 Модель вызывает доступные ей MCP для анализа
🍭 Пользователь получает вердикт (информация о достижимости и трасса)
Каждая сработка анализируется своим собственным агентом.
Сама модель сильно ограничена в действиях. Всю информацию, которую она анализирует, она получает только от вызываемых инструментов.
Чтобы сократить количество используемых токенов, Xpsd не «загружает всю кодовую базу».
Вместо этого утилита использует ast-tree и обогащает переданные на вход данные по CVE с использованием OSV.dev.
В качестве источников информации о CVE поддерживаются сканеры: Grype, Trivy, OSV-Scanner и Snyk.
Подробнее о том, как работает Xpsd и о том, как её запустить и настроить, можно прочесть тут и тут соответственно.
А если хочется посмотреть на сам prompt, который она использует, то он лежит вот тут.
Всем привет!
Ещё один проект под эгидой OWASP. На этот раз он посвящен анализу достижимости уязвимостей, которые выявляются в рамках композиционного анализа.
Т.е. он даёт ответ на вопрос: «Могут ли входные данные, передаваемые ПО, вызвать уязвимый код в этом репозитории?».
Работает это примерно так:
🍭 На вход Xpsd передаётся одна конкретная CVE или целый отчёт
🍭 Модель вызывает доступные ей MCP для анализа
🍭 Пользователь получает вердикт (информация о достижимости и трасса)
Каждая сработка анализируется своим собственным агентом.
Сама модель сильно ограничена в действиях. Всю информацию, которую она анализирует, она получает только от вызываемых инструментов.
Чтобы сократить количество используемых токенов, Xpsd не «загружает всю кодовую базу».
Вместо этого утилита использует ast-tree и обогащает переданные на вход данные по CVE с использованием OSV.dev.
В качестве источников информации о CVE поддерживаются сканеры: Grype, Trivy, OSV-Scanner и Snyk.
Подробнее о том, как работает Xpsd и о том, как её запустить и настроить, можно прочесть тут и тут соответственно.
А если хочется посмотреть на сам prompt, который она использует, то он лежит вот тут.
GitHub
GitHub - OWASP/Xpsd: Reachability triage for vulnerability scans. Feeds scanner findings to an LLM agent that reads your source…
Reachability triage for vulnerability scans. Feeds scanner findings to an LLM agent that reads your source and decides which CVEs are actually reachable. - OWASP/Xpsd
🔥10🥴1
Мультиагентные системы, новые угрозы и острые дискуссии о безопасности ИИ — всё это ждёт гостей AI AppSec Night. Встречаемся 17 ноября в ДК Альфа-Кристалл. Что будет:
Можно прийти лично или подключиться онлайн — выбирайте удобный формат и присоединяйтесь бесплатно!
Регистрируйтесь — код доступа уже у вас: 1711.
@alfa_trends
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥4🤝2🤡1🖕1