Trail of Bits: Fuzzing!

Всем привет!

Trail of Bits продолжает развивать свой Testing Handbook. Теперь в нем можно найти информацию по одной из самых «пугающих» и сложных тем в Application Security, а именно – Fuzzing.

Команда собрала подборку для:
🍭 C/C++ (libFuzzer, AFL++, LibAFL)
🍭Rust (cargo-fuzz)
🍭Python (Atheris)
🍭Ruby (Ruzzy)
🍭OSS-Fuzz

Для каждого предлагаемого инструмента приводится небольшая инструкция по использованию: от установки до запуска и настройки.

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

Помимо этого в Testing Handbook можно найти информацию о статическом анализе на примере Semgrep и материалы по тестированию Web-приложений. Об этом мы писали тут и тут.

SecDim: теория и практика по безопасной разработке!

Всем привет!

Еще один сайт, на котором можно найти (местами бесплатную) теорию и практику по разработке безопасного ПО.

На сайте можно найти:
🍭 Теорию по принципам Secure Design
🍭 Основы безопасной разработки
🍭 Разборы реальных случаев (например, Stack Overflow Outage в 2016)
🍭 Безопасная работа с GitHub Actions
🍭 Безопасное программирование на Java, Golang, Python, JS и т.д.

Понравилась, как реализована практика: есть небольшое видео, в котором объясняется концепт уязвимости. Далее нужно поправить существующий код и пройти тесты. И тут есть нюанс – важно не только исправить дефект, но и сохранить работоспособность приложения.

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

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

CPU Limits и throttling в Kubernetes

Всем привет!

Еще один отличный материал, посвященный управлению ресурсами в Kubernetes. А именно – когда (не) надо использовать CPU Limits при работе с контейнерами.

Сперва Автор описывает общий концепт: что такое CPU Requests и CPU Limits, для чего они используются и как все это связано с cgroups v2.
Если упростить, то CPU Limits определяют максимальное время использования процессора в
рамках «окна», равного 100 ms.

Грубо говоря, если установлен CPU Limit, равный 0.4, то на реализацию задачи, которой требуется 200 ms процессорного времени уйдет… 440 ms.
Причина проста – в первые 100 ms было использовано лишь 40 ms времени процессора, остальные 60 ms – простой и ожидание нового «окна».

Для некоторых приложений это не столь значимо, для некоторых – достаточно критично. Например, могут не сработать liveness probes, могут быть пропущены heartbeat-события и многое другое.

В завершении статьи Автор дает рекомендации о том, когда (не) нужно использовать CPU Limits и о том, как можно идентифицировать throttling.

Кстати, статья – это лишь некоторое summary доклада, презентация которого доступна по ссылке в статье (~ 100 слайдов, посвященных тематики).

Много графиков, пояснений и формул, что позволят лучше разобраться в вопросе и решить для себя – а стоит ли использовать CPU Limits.

CyberCamp 2025: call for papers!

Всем привет!

CyberCamp возвращается! Мероприятие, посвященное развитию как теоретических, так и практических навыков по информационной безопасности ищет спикеров!

В этом году CyberCamp будет длиться целую неделю (ну почти): с 20 по 25 октября 2025 года, дни докладов – 21,22 и 23 октября.

Темы по безопасной разработке и DevSecOps в наличии:
🐾 Безопасность приложений (исходный код, компоненты и т.д.)
🐾 Защита цепочки поставки ПО
🐾 Управление секретами
🐾 Защита API
🐾 Управление приоритетами при устранении ИБ-дефектов в безопасной разработке
🐾 Защита окружения разработки (VCS, CI/CD, Registry и т.д.)
🐾 Защита контейнеров: от Docker до Kubernetes

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

Что делать, если «вашей темы» нет в списке? Все равно заполнять форму и подаваться с докладом!

Важную информацию о датах можно найти на сайте мероприятия. Ждем ваших заявок и до встречи на CyberCamp 2025!

P.S. CFP открыт до 15-ого июня 2025 года 🟢

Snyk: Greybeard!

Всем привет!

🚨 Исключительно пятничный пост 🚨

Ребята из Snyk решили, что стандартные описания уязвимостей достаточно скучные и хочется их как-то персонализировать и сделать более «понятными».

Для этого они выпустили новую CLI утилиту – Greybeard!

Работает все просто:
🍭 Качаем Greybeard
🍭 Указываем OpenAI API Key
🍭 Используем Greybeard для анализа «чего-либо» (например, образов контейнеров)

В качестве результата получаем не обычное описание в стиле «Пакет XYZ содержит уязвимость в каком-то методе», а нечто вроде «Listen up, youngster! I see you've got a critical RCE vulnerability in that package. Back in my day, we'd have been fired for leaving something this obvious in production. You better fix this ASAP unless you want your servers to become someone else's bitcoin miner...»

Подробности, как обычно, в repo проекта. А мы желаем вам отличной пятницы и прекрасной Пасхи! ☺️

Slopsquatting: еще одна supply chain уязвимость

Всем привет!

Typosquatting давно известная и понятная уязвимость, обусловленная самым слабым звеном в любой системе безопасности – человеком.

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

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

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

Однако и AI может ошибаться. Например, предлагать к использованию пакеты, которые не существуют. Этим тоже могут воспользоваться злоумышленники – например, собрать статистику о том, какие пакеты из несуществующих чаще рекомендуют LLM и зарегистрировать их. Но уже «с другим содержанием».

Согласно статье около 20% из 205 000 рекомендуемых LLM пакетов были несуществующими. Процент галлюцинаций меняется от модели к модели: DeepSeek и WizardCoder – 21,7%, GPT 4 – 5,2%.

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

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

Основы работы с REGO

Всем привет!

REGO может показаться не самым простым языком, особенно если до этого вы работали с «более привычными» Python, Golang, Java и т.д.

Чтобы упростить начало работы с ним и немного снизить порог входа, команда SNYK подготовила обширный материал – Getting started with Practical Rego.

Статья (~ 28 минут чтения) включает в себя сведения о:
🍭 Общую информацию про REGO и его декларативность
🍭 Сравнения, работа с правилами и функциями
🍭 Управление потоком выполнения, работы с циклами
🍭 Поиск ошибок, отладка и т.д.

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

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

Pentesting Everything!

Всем привет!

В repo собрана отличная подборка, посвященная тому, как и что можно «ломать». Казалось бы, при чем тут DevSecOps и Application Security?

Ответ прост! Внутри этой подборки также есть материалы по Source Code Review, DevSecOps, CI/CD Security, Web Security, API Security, Mobile Security и т.д.

Например, раздел по DevSecOps содержит:
🍭 Краткий перечень практик (SAST, SCA, Container Security и т.д.) с указанием средств автоматизации
🍭 Отсылки на лабораторные работы по теме (Juice Shop, Hack The Box, VulnHub)
🍭 Checklist по разным аспектам DevSecOps

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

Особенно это касается checklist, которые есть практически в каждом разделе репозитория.

Rogue: Web Vulnerability Scanner

Всем привет!

По ссылке можно найти Rogue – open source проект, представляющий из себя web-сканер, «под капотом» которого используется LLM.

Он умеет:
🍭 Анализировать web-трафик за счет встроенного proxy
🍭 Понимать контекст приложения и «адаптироваться» в зависимости от получаемых результатов
🍭 Генерировать payloads, «подходящие» для конкретного приложения
🍭 Подтверждать наличие уязвимостей, что снижает количество false positive
🍭 Генерировать отчетность и не только

В качестве LLM используется OpenAI и Anthropic Claude, поэтому для того, чтобы опробовать Rogue «в деле», потребуется указать соответствующие API-ключи.

Больше про утилиту можно узнать в repo проекта.

Важно(!): со слов Автора, это больше PoC, который он планирует дорабатывать, а не законченное решение.

Так ли хороша EPSS на самом деле?

Всем привет!

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

CVSS хоть и удобна, но не сильно упрощает жизнь: все-равно количество Critical и High уязвимостей просто колоссально. Не говоря уже о том, что и «Medium может выстрелить».

Поэтому специалисты продолжают искать пути как правильно с этим работать. Например, анализ достижимости (reachability analysis) может сильно упростить жизнь для отсева ложных срабатываний.

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

Еще одним инструментом является Exploit Prediction Scoring System (EPSS). Если просто, то она позволяет предсказывать вероятность того, что та или иная уязвимость будет проэксплуатирована в течение некоторого временного промежутка.

И вроде бы все отлично и ее хочется использовать при анализе уязвимостей, но есть вопрос: а хорошо ли она работает на самом деле?

Для ответа на него рекомендуем ознакомиться с исследованием в приложении (~ 13 страниц).

В нем содержится информация:
🍭 Общие сведения о CVE, CVSS, EPSS, базе CISA KEV и о том, как связаны эти понятия
🍭 Верхнеуровневый взгляд на модель EPSS v3
🍭 Аналитика того, насколько точны предсказания EPSS на примере нескольких CVE
🍭 Общие выводы

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

Второй заключается в том, что по мнению Автора EPSS больше походит не на модель «предсказания», а на «историческую» модель, в которой отражена информация об эксплуатации уязвимости.

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

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

P.S. В статье проанализирована EPSS v3. 17 марта 2025 года была выпущена EPSS v4

Proactive Software Supply Chain Risk Management Framework

Всем привет!

В приложении можно скачать P-SSCRM (~ 17 страниц) – framework, посвященный обеспечению безопасности при работе с цепочкой поставок ПО.

P-SCCRM был разработан с учетом данных, собранных на основании результатов анализа атак на цепочки поставки, реализованных в 2022, 2023 годах.

Framework разделен на домены:
🍭 Governance. Организация процесса защиты и оценка его эффективности
🍭 Product. Выпуск продукта с минимальным количеством ИБ-дефектов
🍭 Environment. Защита исходного кода, компонентов, инфраструктуры сборки и т.д.
🍭 Deployment. Идентификация и анализ ИБ-дефектов в продукте

Для каждого домена определены задачи (tasks) в общем количестве 73 штуки. Описание задач, а также соотношение практик P-SSCRM с BSIMM, NIST, SALSA и иными стандартами можно найти в документе.

Wiz Vulnerability Database

Всем привет!

По ссылке доступен еще один источник получения информации по уязвимостям – Wiz Vulnerability Database.

В целом все достаточно «стандартно», но собрано очень и очень удачно. Можно искать как определенную CVE, так и использовать фильтры: has exploit, high profile vulnerabilities, CVE with an exploit from the last 60 days и т.д.

По каждой уязвимости предоставляется информация:
🍭 Ссылка на NVD и иные ресурсы
🍭 Информация о наличие эксплойта (public, CISA KEV)
🍭 Сведения о EPSS
🍭 Информация о векторах CVSS
🍭 Описание уязвимости, потенциальный ущерб и рекомендации по устранению

Возможно, что кому-то пригодится для получения «еще одного источника» для процесса управления уязвимостями. На текущий момент в базе содержится порядка 133к записей.

Из того, что не удалось найти – есть ли некий API или сама база в «отчуждаемом» формате, чтобы можно было ее забрать «к себе». Если знаете, как и что – пишите в комментариях ☺️

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

Всем привет!

Контролировать потоки сетевого трафика – дело хорошее. В Kubernetes для этого есть сетевые политики (опустим, что они могут различаться у разных CNI).

Создать простые политики для тестов достаточно легко. Но как поддерживать их в актуальном состоянии? Как сделать так, чтобы ваши политики не сломали все «соседу» (в случае использование некоего общего ресурса). И, конечно же, как это делать автоматизировано?

Если вам интересны ответы на эти вопросы, то очень и очень рекомендуем прочесть вот эту статью. В ней Автор рассказывает о автоматизации процесса управления сетевыми политиками с использованием Otterize, Kyverno и ArgoCD.

Статья содержит в себе:
🍭 Погружение в проблематику
🍭 Нюансы, с которыми придется столкнуться при решении задачи «в лоб»
🍭 Как Otterize может упростить и оптимизировать процесс конфигурации политик (про утилиту мы писали тут и тут)
🍭 Варианты автоматизации процесса управления сетевыми политиками и при чем тут Kyverno

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

Схемы, конфигурации, комментарии, размышления, варианты решения разных задач – все на месте!

Мы на DevOps Conf 7-8 апреля: все активности в одном посте 👍

Уже в понедельник стартует юбилейная конференция DevOps Conf, и мы, конечно, там будем. А вы?)

📍 Где нас можно найти: стенд №6, рядом с конгресс-холом.

🎤 Где нас можно послушать: 7 апреля в 10:00 в зале «Пекин» будет выступать Саша Краснов, СТО платформы «Штурвал». Тема доклада: «Как я перестал страдать и полюбил CoreDNS».

🎁 Как можно побороться за крутой мерч: все просто — поучаствовать в наших активностях. А их очень много: и шоковая викторина, и бой «ванильного» кубера против «Штурвала», и игра по миру Kubernetes. Призы достойные, мы ими очень гордимся.

Приходите!

Проверка подписей образов контейнеров в Docker

Всем привет!

Периодически возникает задача по проверке электронных подписей образов контейнеров в Docker и Docker Compose.

Несмотря на то, что Docker-Compose по-прежнему повсеместно используется для работы многих критичных приложенний,
в стандартном наборе Docker (а также Podman и других аналогов) отсутствуют инструменты, которые позволяют проверять цифровую подпись образа контейнера и запрещать его запуск в случае наличия несоответствия.

Существует механизм Docker Content Trust, но он является всего лишь функцией клиента Docker (не работает на уровне daemon) и Docker-compose с ним полноценно не работает.

Доработанный и оттестированный нами плагин позволяет решить данные задачи - https://github.com/Jet-Security-Team/img-authz-plugin

Данный Auth-Z плагин позволяет:
🍭 Проверять цифровую подпись образов контейнеров с использованием внешнего сервиса Notary
🍭 Запрещать запуск контейнера в случае отсутствия корректной электронной подписи как в случае с клиентом Docker, так и Docker-compose

Ingress Nightmare: hands-on lab

Всем привет!

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

Если вам не хватило множества описаний и хочется посмотреть, как оно работает «на деле», то в этом repo собрана необходима информация.

Внутри можно найти алгоритм действий и необходимые скрипты для того, чтобы проэксплуатировать CVE-2025-1974.

Кстати, помимо этого, в repo есть и другие лабораторные работы по безопасности Kubernetes. Подробнее про него мы писали тут.

Идентификация вредоносного кода

Всем привет!

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

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

Чтобы немного упростить задачу рекомендуем ознакомиться со статьей от Apiiro, в которой они рассказывают про то, как идентифицируют вредоносный код.

Не только словом! Команда предоставила в общий доступ несколько своих наработок.

Это:
🍭 Набор правил для Semgrep (Opengrep) для идентификации вредоносного кода
🍭 PRevent – анализ PR GitHub на наличие чего-то подозрительного

Инструменты можно использовать для анализа различных языков: Java, PHP, Ruby, Golang и т.д. А о том, чем именно руководствовались Авторы при разработке правил и утилит, можно узнать в статье.

В завершении (Appendix A) приведена статистика о True/False Positive при использовании наработок Apiiro применительно к Malicious Software Packages Dataset, подготовленного DataDog

API Pentesting Tools

Всем привет!

Давно не было awesome-подборок, решили это поправить ☺️ По ссылке доступны наборы open source инструментов, которые могут пригодиться при ИБ-анализе API.

Материал структурирован по разделам:
🍭 Reconnaisance
🍭 AuthN, AuthZ Testing
🍭 Input Validation Testing
🍭 Security Headers, CORS Testing и не только

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

А вы пользуетесь такими подборками или не видите в них смысла?

Container Security Site

Всем привет!

Rory McCune – личность достаточно известная в мире информационной безопасности контейнеров и сред контейнеризации.

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

Внутри можно найти:
🍭 Attackers: Compromised Container Checklist
🍭 Attackers: Compromised User Credentials Checklist
🍭 Container Breakout Vulnerabilities
🍭 Defenders: Container Image Hardening
🍭 Reading List и многое другое

Крайне полезный ресурс, если вам интересна тема защиты контейнеров. Однозначно рекомендуем к изучению!

DNS resolution в Linux и Kubernetes

Всем привет!

«It’s always DNS!» Да, все так. Нет, не баян, а классика ☺️ Для получения представления или усиления существующего рекомендуем вам ознакомиться со статьей.

Все началось с того, что Автор получил сообщение об ошибке: Nameserver limits were exceeded, some nameservers have been omitted.

Это послужило началом приключения, которое описано в статье. Автор делится своими знаниями о том, как устроен DNS resolution в Linux и Kubernetes.

В статье можно найти информацию о:
🍭 Общая теория DNS в Kubernetes
🍭 DNS в Linux: resolv.conf и nssswitch.conf
🍭 Что изменится при использовании, например, Alpine?
🍭 DNS в Kubernetes: kube-dns, настройки и модификации, dnsPolicy

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

А в завершении, конечно же, ответ на вопрос – «А почему же Автор получил такое сообщение об ошибке». Рекомендуем к прочтению!

Моделирование угроз: опыт Trail of Bits!

Всем привет!

По ссылкам доступны статьи, посвященные моделированию угроз (раз, два) и тому, как этот процесс реализован в Trail of Bits.

История стара, как мир: есть очень много всего интересного и полезного. Однако, нам ничего не подошло, и мы сделали свое – TRAIL.

За основу TRAIL был взят Rapid Risk Assessment и дополнен материалами из NIST (SP 800-154, 800-53).

Первая статья посвящена тому, зачем нужна TRAIL и как она работает. Команда использует разный уровень детализации – Lightweight и Comprehensive Threat Model. Разница в уровне детализации, примеры приведены в статье.

Вторая статья посвящена тому, как сделать процесс моделирования угроз непрерывным. Грубо говоря, что делать дальше, когда модель угроз уже есть, а ПО продолжает развиваться?

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

Единственный «нюанс» статей, что они достаточно поверхностные, хочется больше деталей и примеров того, как это работает ☺️

P.S. А еще у Trail of Bits есть Testing Handbook, в котором собрана часть их опыта по AppSec и DevSecOps. О нем мы писали тут

Обогащение информацией об уязвимостях

Всем привет!

При работе с уязвимостями многие (по крайней мере по началу) используют метрики, получаемые при использовании методологии Comon Vulnerability Scoring System (CVSS).

Такие данные, например, доступны в National Vulnerability Database (NVD) – CVSSv2, CVSSv3, CVSSv4 (крайне редко, если вообще).

Нюанс заключается в том, что в NVD указаны результаты расчета Base Metric Group в соответствии с методологией. Temporal и Environmental «части» не участвуют в оценке. Хотя они могут сильно влиять на итоговый результат.

Чтобы как-то это исправить, рекомендуем обратить внимание на проект cvss-bt, который частично решает эту проблему и добавляет Temporal/Threat Metrics.

Работает это примерно так:
🍭 Каждое утро осуществляется синхронизация EPSS
🍭 При изменении EPSS Score обновляются данные по CVSS из NVD
🍭 Рассчитывается новая оценка с учетом Temporal/Threats. Данные берутся из CISA KEV, VulnCheck KEV, Metasploit и не только)
🍭 Новая оценка (вместе с исходной) устанавливается для CVE

В итоге получается CSV-табличка, которую можно скачать из repo. В ней содержится обогащенная информация по CVE согласно вышеописанному алгоритму.

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

P.S. Кстати, если вы никогда не задумывались как именно это считается, но очень хочется узнать – в repo есть ссылки на спецификации CVSSv2, v3, v3.1 и v4.

Kubernetes Security Hardening CLI

Всем привет!

Kube-Sec – еще одна утилита, которая позволяет анализировать конфигурации Kubernetes-кластеров для идентификации ИБ-дефектов.

При помощи нее можно найти:
🍭 Privileged Containers
🍭 RBAC Misconfigurations
🍭 Publicly Accessible Services
🍭 Pods Running as Root и не только

Проверки можно настраивать (включать/отключать), результаты предоставляются в качестве JSON/CSV.

В ближайшее время Автор собирается добавить регулярные сканирования (ежедневные/еженедельные)

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

Важно: проект пока что не является production ready со слов Автора и все еще находится в стадии разработки.

The State of Secrets Sprawl 2025

Всем привет!

В приложении можно найти отчет (~46 страниц) от GitGuardian, посвященный утечкам конфиденциальной информации, а именно – секретов.

Казалось бы, одна из самых базовых рекомендаций – не «храните» секреты в исходном коде и конфигурационных файлах – однако, год от года количество компрометированных секретов растет.

В отчете много статистической информации:
🍭 58% всех секретов – Generic (обычные строки для подключения к чему-либо)
🍭 35% просканированных private repo содержали хотя бы 1 секрет в открытом виде
🍭 Наиболее «популярный» секрет в private repo – ODBC connection string
🍭 Если говорить об образа контейнеров, то самое популярное место для поиска секретов – да, конечно, ENV (65% найденных секретов)
🍭 Большинство секретов остается «активными» после того, как их нашли
🍭 И многое другое

Отчет получился очень интересным, информативным и насыщенным.

Читается легко, «воды» практически нет, зато есть много данных для размышления. Рекомендуем! ☺️

Bearer: open source SAST

Всем привет!

Bearer – open source SAST от команды Cycode. Как и многие другие SAST-решения он может искать как ИБ-дефекты в исходном коде, так и секреты.

Поддерживается следующий набор языков: Golang, Java, JavaScript, TypeScript, PHP, Python и Ruby.

Количество правил варьируется – от 66 для PHP до 88 для Python. Ознакомиться с ними можно вот тут (само правило, описание, рекомендации, полезные ссылки и соотношение с CWE).

Отличительной особенностью Bearer является то, что он может анализировать использование чувствительной информации, например, имена, номера телефонов и т.д. С полным перечнем можно ознакомиться тут.

По завершению работы можно получить несколько отчетов – Security Report, Privacy Report и Data Types Report.

Если вам интересно как работает Bearer внутри, то можно обратиться к этому разделу документации.

Кстати, она достаточно емкая, удобная и информативная – рекомендуем к изучению для лучшего знакомства со сканером ☺️

Сравнение LLM для моделирования угроз

Всем привет!

По ссылке можно найти результаты сравнения возможностей LLM по моделированию угроз.

В выборку попали: gemma, Phi, DeepSeek, llama и не только.

Сравнение проводилось по группам критериев:
🍭 STRIDE Coverage & Accuracy: насколько модель покрывает все группы угроз в соответствии с методологией STRIDE
🍭Threat Completeness: показывает количество угроз, качество описания
🍭Technical Validity: насколько описание является технически корректным и релевантным
🍭JSON Structure Compliance: проверка корректности заполнения и формата данных в итоговых результатах

Все результаты представлены в виде интерактивных графиков – общие результаты, результаты по приведенным выше группам и т.д.

Больше подробностей про саму методологию можно найти в соответствующем разделе сайта.

P.S. Кстати, это сравнением сделал Matt Adams – Автор STRIDE GPT, о которой мы писали тут.

Введение в OCI

Всем привет!

При работе с образами контейнеров вы, вероятно, слышали про то, что они создаются в соответствии со спецификацией Open Container Initiative, OCI.

Но что это значит? Если вас интересует ответ на этот вопрос, то рекомендуем прочесть статью.

В ней Автор разбирает несколько типов OCI-спецификаций:
🍭 OCI Image-spec: структура образов контейнеров
🍭OCI Distribution-spec: способы распространения образов контейнеров
🍭OCI Runtime-spec: реализация жизненного цикла контейнеров

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

В завершении приведены ссылки на полное описание спецификаций, если вам интересно разобраться более подробно

Finalizers в Kubernetes: что это и зачем?

Всем привет!

Наверное, при работе с Kubernetes вы встречались с тем, что после kubectl delete … удаляемый ресурс «подвисал» в состоянии terminating.

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

Просто и понятно о них описано в статье:
🍭 Автор делает собственный finalizer и пытается удалить ресурс
🍭Поясняет что делать, если terminating все-таки висит
🍭 Рассказывает о том, что есть finalizer и как они устроены

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

Bomber: анализ BoM-файлов

Всем привет!

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

Он может работать с разными форматами BoM-файлов: SPDX, CycloneDX, Syft. В качестве источников данных об уязвимостях используются индексы (providers): OSV, GHSA, OSS Index (Sonatype) и Snyk.

По результатам анализа Bomber предоставляем информацию:
🍭 Пакетный менеджер
🍭 Зависимость, ее версия
🍭 Уязвимость (CVE), ее критичность
🍭 EPSS

Помимо этого, он также анализирует информацию об используемых лицензиях.

Сами отчеты можно получить, как в stdout, так и в JSON и HTML-форматах.

Больше о возможностях утилиты можно прочесть в repo проекта.

P.S. Еще одной интересной особенностью Bomber является сканирование целой папки, внутри которой находятся BoM-файлы ☺️

Как TruffleHog ускорил поиск секретов за счет алгоритмических оптимизаций

Всем привет!

Отличная статья о том как TruffleHog обновил алгоритмы сканирования, ускорив поиск утекших секретов. Теперь сканирование быстрее без потери точности – за счет оптимизации переходов при построении автомата Aho-Corasick.

Что изменилось?
🎯 Один проход по коду: ~800 ключевых слов от всех детекторов проверяются за раз, без повторных циклов
🎯 Aho-Corasick + предвычисления: заранее просчитаны переходы состояний, что сократило CPU-нагрузку
🎯 Быстрее на 11–17%: особенно заметно на больших репозиториях
🎯 Масштабируемость: добавление новых детекторов больше не замедляет анализ. Применение Aho-Corasick обеспечивает линейную масштабируемость по объему данных
🎯 Следующий шаг — оптимизация памяти и ускорение сканирования до 22–40%

Подробнее – в разборе алгоритма

Используете TruffleHog? 🐽

Компрометация данных через session tokens…

Всем привет!

… или еще одна история о том, как заработать 15 000$ на bug bounty. Все начиналось как обычно, bug hunter взял «заказ» на Hackerone на уже знакомую ему систему.

События начали стремительно развиваться после того, как он заполнил данные на странице регистрации – имя, email, прочую информацию.

Оказывается, что сервер вернул сессионный token, но не простой, а без… expiration date. Это заинтересовало исследователя и он решил продолжить изучение.

После завершения регистрации и создания учетной записи приложение перенаправило его на страницу вида https://somesite.com/apply/information/?s=success&token=… Все так, там был «тот самый token без срока действия».

Следующий шаг вполне логичен – попробовать поискать аналогичные token в сети. Google Dorks в помощь и да, token был получен, как и доступ к конфиденциальной информации его владельца.

В завершении статьи описываются дополнительные исследования Автора относительно того, сколько по времени подобная уязвимость была в приложении. Рассказывать не будем, рекомендуем прочесть статью 😊

Анализ угроз для ArgoCD

Всем привет!

Команда Exness написала отличную статью, посвященную идентификации ИБ-угроз, характерных в случае использования GitOps подхода и ArgoCD в частности.

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

Рассматриваются угрозы из «ArgoCD End User Threat Model», например:
🍭 Initial admin password compromise
🍭 Abuse of Argo CD local users
🍭 External cluster credentials compromise
🍭 Abuse of unrestricted default project и не только

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

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

🔍 TruffleHog Analyzer – анализ утекших API-ключей

Всем привет!

Обнаружение секретов в коде – уже стандарт, но что делать, если ключ утек? TruffleHog предлагает новый подход: trufflehog analyze позволяет провести глубокий анализ ключа, выяснив, какие у него разрешения и какие ресурсы он затрагивает. Теперь можно не только находить ключи, но и сразу понимать их влияние.

🎯 Проверяет активность ключа – действующий он или нет
🎯 Определяет владельца – чей именно ключ
🎯 Анализирует доступ – какие ресурсы доступны по ключу (доступно до 20 источников)
🎯 Выявляет привилегии – что можно делать с этими ресурсами
🎯 Помогает в отзыве – инструкция как отозвать секрет

Если хотите разобраться глубже – вебинар по теме.

Как вы проверяете утекшие ключи? Пользуетесь ли авто-валидацией? Делитесь в комментариях! 💁‍♂️

OWASP DevSecOps Guideline

Всем привет!

Как-то так получилось, что мы ни разу не писали про материалы по DevSecOps от OWASP, а именно про OWASP DevSecOps Guideline.

В нем собрана информация о:
🍭 Моделировании угроз
🍭 Статическом и динамическом анализе
🍭 Композиционном анализе
🍭 Анализе образов и контейнеров и т.д.

Для каждого раздела описано что это такое и какими open source инструментами можно пользоваться для реализации практики.

Кроме этого, есть ссылки на полезные материалы по теме.

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

Централизованное управление уязвимостями

Всем привет!

Когда сканеров становится много, а уязвимостей еще больше, неплохо бы иметь единое место для их сбора, фильтрации и приоритизации. SecObserve (open-source) – может стать новым отличным решением на замену DefectDojo:

Платформе меньше двух лет, но уже доступно множество фич:
🎯 Интегрируется в CI/CD, поддерживает SARIF и парсеры на множество инструментов
🎯 Удобное управление проектами – поддержка веток и версий
🎯 Отслеживает лицензии – импорт информации из SBOM (CycloneDX и SPDX)
🎯 Обогащает данные с помощью Exploit Prediction Scoring System (EPSS)
🎯 Дает метрики как по всем продуктам так и по отдельным
🎯 Экспортирует уязвимости в трекеры (Jira, GitLab, GitHub), отправляет уведомления в Slack, Teams, email
🎯 REST API для автоматизации
🎯 Хорошая документация

Из минусов:
🤷‍♂️ Нет поддержки LDAP, что часто важно
🤷‍♂️ Не понятно как поведет себя с большим кол-вом данных

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

CyberCamp: форензика для контейнеров и контейнерных инфраструктур!

Всем привет!

Открытие нового сезона CyberCamp, да еще какое! Первый MeetUp 2025 года будет посвящен цифровой криминалистике (Digital Forensics and Incident Response, DFIR).

Одним из спикеров будет Дима Евдокимов, который не нуждается в представлении 💪💪💪 Он расскажет про расследование инцидентов в среде, где практически всё временно и эфемерно.

Приглашаем вас посетить мероприятие (14 марта, начиная с 13:30)! Для этого надо лишь зарегистрироваться по ссылке.

🚨🚨🚨 Но и это еще не все! 🚨🚨🚨

Команда CyberCamp решила запустить собственное сообщество, в котором собраны практические задания, рекомендации для изучения, календарь мероприятий по ИБ и многое другое!

Какой-то «определенной тематики» у сообщества нет. Поэтому, если вы неравнодушны к ИБ, вам хочется изучать новое, общаться, решать задачки и развивать свои навыки, то вам точно туда 🐾

Тут еще проще – надо просто перейти по ссылке и вступить в канал! Ждем вас! Спасем Компота вместе!!! 🤩🤩🤩

Анализ достижимости и приоритизация уязвимостей

Всем привет!

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

Главный вопрос, на который надо найти ответ звучит примерно так: «А можно ли как-то исполнить уязвимый код во время работы (исполнения) ПО?». Именно для этого и используется анализ достижимости.

В статье Авторы раскрывают такие темы, как:
🍭 Что такое анализ достижимости и какие подвиды у него бывают
🍭 Почему этот анализ так важен для процесса управления уязвимостями в open source компонентах
🍭 Использование достижимости при расстановке приоритетов по устранению уязвимостей
🍭 Значимость анализа достижимости (небольшая статистическая справка)

Все указанные темы раскрываются достаточно подробно, с примерами и пояснениями.

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

Как работает scheduling в Kubernetes?

Всем привет!

«Как именно Kubernetes «размещает» создаваемые `pod` на узлах кластера?» - если вам интересен этот вопрос, то статья может быть полезна.

В ней описывается весь процесс:
🍭 Попадание pod в Scheduling Queue
🍭 Фильтрация (Filtering) – «отбрасываются» узлы, на которых нельзя разместить pod (например, у узла статус Unreachable)
🍭 Выбор оптимального узла (Scoring) – выбор осуществляется из узлов, которые «прошли» предыдущий этап
🍭 «Назначение» pod определенному узлу (Binding)

Автор описывает все эти этапы достаточно детально, чтобы в голове сформировалось представление о том, что происходит «под капотом».

Затрагиваются такие темы, как Priority Class, Taints, Tolerations, (Anti) Affinity, Selectors и многое другое.

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

Работа с контейнерами Docker: разбор популярных утилит

Всем привет!

Иногда нам приходится возвращаться к Docker, чтобы протестировать и быстро оценить функционал нового приложения, инструмента, сканера. На помощь приходят удобные утилиты:
🎯 lazydocker – интерактивный терминальный UI для мониторинга контейнеров, образов, логов и ресурсов.
🎯 ctop – аналог htop, но для Docker: показывает загрузку CPU, RAM, диски, сети контейнеров.
🎯 cdebug – удобный инструмент для дебага контейнеров (позволяет пробрасывать в контейнер link до бинарников хоста).
🎯 dive – анализ слоев Docker-образов, помогает оптимизировать их размер и выявлять неэффективные сборки.
🎯 layeremove – пример скрипта на Python для удаления слоев из Docker-образов.

Если чего-то не хватает, можно использовать простые запросы к Docker, для вывода JSON — добавляй --format '{{json .}}'.
Например, чтобы получить данные об использовании ресурсов:

# Использование ресурсов
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
# Информация о контейнерах в json
docker ps --format '{{json .}}' | jq .

А какими утилитами пользуетесь вы? Делитесь в комментариях!

Автоматическое устранение ИБ-дефектов в коде

Всем привет!

Сегодня предлагаем вам легкое пятничное чтиво, в котором Автор рассуждает о том, насколько можно/нужно/целесообразно полагаться на различные технологии, предоставляющие функционал по автоматическому устранению ИБ-дефектов в исходном коде.

В качестве примера он берет то, «что показывают все производители на всех демонстрациях» (ведь это круто работает!) – работа с SQL-инъекциями.

Дальше он делает аналогичное для:
🍭 Cross-Site Scripting
🍭 Weak Cryptography
🍭 Hardcoded Secrets

И вроде бы все хорошо, но есть некоторые нюансы. Например, с теми же секретами – да, убрали из исходного кода, но как тогда будет работать приложение?

А что вы думаете по этому поводу? Надо/Не надо/Надо, но аккуратно/Иное – пишите свое мнение в комментариях ☺️

Securing Kubernetes using Policy-as-Code

Всем привет!

В приложении можно скачать электронную книгу (~ 36 страниц), посвященную Policy-as-Code от Nirmata (дада, те самые разработчики Kyverno).

После вводной части, посвященной тому, что такое Policy-as-Code и основам безопасности Kubernetes, начинается самое интересное!

Авторы описывают:
🍭 Kyverno: основы, написание политик
🍭 Защита образов и реестров
🍭 Использование Kyverno в CI-конвейере
🍭 Использованием Kyverno для нужд compliance и не только

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

Autogrep!

Всем привет!

Да, вам не кажется! Это то, о чем вы подумали! Автоматическое создание правил для Semgrep с использованием нейронных сетей.

Если кратко, то его возможности заключаются в:
🍭 Создании правил для Semgrep на основе информации из патчей с исправленными уязвимостями
🍭 Анализе качество создаваемых правил
🍭 Поддержке различных языков программирования, для которых создаются правила.

В использовании тоже нет ничего сложного: скачиваем утилиту, создаем правила, используем их вместе с Semgrep для анализа интересующего проекта.

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

Docker Init

Всем привет!

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

Чтобы упростить задачу можно использовать docker init. С его помощью можно создать dockerfile, compose.yaml и .dockerignore автоматически.

Работает это примерно так:
🍭 Вы запускаете docker init и попадаете в интерактивную сессию
🍭 Потребуется указать используемую технологию (Node, Go, Python и т.д.)
🍭 Определиться с командой, которая должна быть запущена в контейнере
🍭 Написать порт, по которому можно обращаться к ПО
🍭 Готово!

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

AppSec метрики от SNYK

Всем привет!

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

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

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

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

Ребята разделили их на 4 блока:
🍭 Risk reduction metrics
🍭 Team coverage and engagement
🍭 Application security posture trends
🍭 Vulnerability management efficiency

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

mTLS в Kubernetes

Всем привет!

Mutual TLS очень полезная функция, особенно когда дело касается информационной безопасности.

Для начала погружения в тему очень может подойти вот эта статья.

В ней Автор разбирает:
🍭 Краткое описание того, что такое mTLS и зачем он нужен
🍭 «Сделай сам!»-реализация с изменением логики работы приложения
🍭 Использование Service Mesh для достижения цели
🍭 Реализация mTLS на основе Ambient Mesh
🍭 Общие рекомендации о том, как это можно сделать

Статья небольшая, дает общение понимание что и зачем и как это можно реализовать. Самое «то» для пятницы ☺️

Графический генератор Audit Policy для Kubernetes

Всем привет!

Команда «Штурвала» сделала «Генератор политик аудита» для Kubernetes. С его помощью можно создавать требуемые политики в удобном web-интерфейсе!

Для этого потребуется
🍭 Перейти по ссылке выше
🍭 Создать правило, на которое будет срабатывать политика
🍭 Указать необходимые параметры (уровень логирования, ресурсы, глаголы и т.д.)
🍭 Повторить до желаемого результата

Ресурс пока что находится в стадии beta-тестирования.

Если вдруг вы найдете что-то, что не работает или у вас есть мысли по развитию функционала, то можете смело их адресовать в Telegram-чат «Сообщества Штурвал» 😊

Управление уязвимостями от Phoenix Security

Всем привет!

В приложении электронная книга от Phoenix Security (~ 120 страниц) с весьма претенциозным названием: «Building resilient application and cloud security programs to manage vulnerabilities».

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

В книге собрана информация о:
🍭 «Источниках данных» ИБ-дефектов и их «месте» в жизненном цикле ПО
🍭 CVE, CVSS – много аналитики и аргументов о том, почему этого крайне мало для принятия решения
🍭 Базах данных с exploits (например, CISA KEV) и EPSS, их роли в оптимизации управления ИБ-дефектами
🍭 Подходах к расстановке приоритетов для устранения ИБ-дефектов, важности роли «контекста»
🍭 Уровнях зрелости процесса и том, что надо делать, чтобы его повысить
🍭 Сравнительных затратах при ручной и (полу) автоматизированной разметке

В книге очень много статистики, рекомендаций и отсылок на разные методологические материалы.

Единственный нюанс – кажется, что все тоже самое можно было рассказать на чуть меньше, чем 120 страниц 😊

Поиск проблем в Kubernetes с использованием AI

Всем привет!

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

Таким помощником может быть и искусственный интеллект. В статье Автор описывает свои изыскания при работе с GPTScript и Kubernetes.

Статья состоит из следующих разделов:
🍭 Краткая вводная в использование GPTScript
🍭 Разницу между Tool и Agent (это потребуется в дальнейшем)
🍭 Создание простейших Tool и Agent, которые будет отвечать на вопрос о состоянии кластера
🍭 Развитие предыдущей идеи – не только отображать статус, но и вносить изменения
🍭 Deploy наработок в кластер в виде Job

Попутно Автор объясняет, как влияют вносимые им изменения на работу модели и результаты, которые она генерирует.

Да, у такого подхода множество вопросов – «А что, если он не сможет найти причину?», «А что, если он поправит так, что сделает только хуже?», «А как можно доверять такой конструкции?» и т.д. Однако, как концепт – это достаточно интересно на наш взгляд.

Кстати, есть еще один занятный способ использования AI для нужд поиска ошибок – «человеческое общение» с журналами событий (прочитать и посмотреть можно тут).

Вероятно, что со временем подобное станет распространённой практикой и сократит время на обслуживание систем.

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

Управление секретами: ArgoCD, HashiCorp Vault и External Secrets Operator

Всем привет!

В статье можно найти очень неплохое руководство о том, как можно реализовать процесс управления секретами в кластерах Kubernetes с использованием ArgoCD (в целом – опционально, без нее ничего не поменяется), HashiCorp Vault и External Secrets Operator (ESO).

Автор фокусируются на двух основных вопросах:
🍭 Как избежать сохранения каких-либо секретов в git (включая аутентификационных токены для Vault)
🍭 Как реализовать синхронизацию секретов без перезапуска приложений

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

Весь процесс отлично описан (за исключением установки используемых решений): шаги, конфигурационные параметры, комментарии и то, что происходит «под капотом». Рекомендуем! ☺️

Запись вебинара "Фреймворк безопасности контейнеров JCSF"

А вот и запись прошедшего вебинара про безопасность контейнеров и фреймворк JCSF, в котором мы принимали участие. Приятного просмотра!

На нашем сайте стали доступны материалы с вебинара "Фреймворк безопасности контейнеров JCSF" (слайды и видео на VK,YT). Это почти 2 часа полезного материала про то как смотреть и делать безопасность в Kubernetes.

OpenClarity: сканирование контейнеров и кластеров

Всем привет!

OpenClarity – open source проект, который позволяет сканировать кластеры Kubernetes и не только для идентификации ИБ-дефектов.

Он содержит сканеры, позволяющие выявлять:
🍭 Уязвимости
🍭 Вредоносное ПО
🍭 Секреты
🍭 Ошибки в конфигурациях
🍭 Эксплойты

Для этого используется целый набор сканеров и источников данных: Syft, Trivy, Grype, Go Exploit DB, KICS, ClamAV и не только.

Подробнее о решении можно узнать в repo или из его документации.

The Complete Guide to Kubernetes Security

Всем привет!

Астрологи объявили неделю электронных книг. В приложении можно найти электронную книгу (~ 33 страницы) от CrowdStrike, посвященную Kubernetes Security.

Материал разбит на 4 основные главы:
🍭 Общая информация о Kubernetes и его «месте» в Cloud Native мире
🍭 Основные векторы компрометации кластеров Kubernetes, разложенные по MITRE
🍭 Рекомендации по защите кластеров Kubernetes (Develop and Distribute, Deploy and Runtime)
🍭 Создание программы (плана) по защите среды контейнерной оркестрации

Конечно, не обошлось и без рекламы решений CrowdStrike по защите контейнеров, но ее не так уж и много.

Вопросы для интервью!

Всем привет!

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

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

В ней собраны вопросы по различным областям. Например:
🍭 Core DevOps Concepts
🍭 Kubernetes
🍭 CI/CD
🍭 Monitoring and Logging
🍭 Site Reliability Engineering и другие

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

Из минусов – вопросов пока что крайне мало и, зачастую, они достаточно общего характера.

Но! Надеемся, что проект будет развиваться и количество вопросов будет только увеличиваться.

Например, если у вас есть, чем поделиться, то правила внесения изменений описаны в разделе contribute ☺️

Курсы от Wiz!

Всем привет!

Команда Wiz подготовила небольшой набор обучающих курсов, посвященных Cloud Native Security. На текущий момент доступно: Kubernetes Security и SecOps for Cloud. В скором времени команда планирует выпустить AI Security.

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

Например, курс про Kubernetes содержит:
🍭 Основы контейнеризации и Kubernetes
🍭 Ошибки в конфигурациях, security posture
🍭 Управление уязвимостями и безопасность цепочки поставок
🍭 Сетевая безопасность, Zero Trust
🍭 Runtime Security и не только

В среднем, для прохождения потребуется от 45 до 60 минут. Никакой регистрации не требуется (вообще). Можно просто открыть ссылку и читать/слушать 😊

#мероприятие
12 февраля в 11:00 подключайтесь к вебинару «Фреймворк безопасности контейнеров JCSF» 🛡

Для оценки уровня безопасности контейнерного окружения компании используют зарубежные NIST 800-190, CIS Kubernetes benchmark, CIS Docker benchmark или изучают премудрости 118 приказа ФСТЭК России. Но все они не дают ответ, в какой последовательности все практики необходимо выполнять.

«Инфосистемы Джет» создала и выложила в открытый доступ свой фреймворк по мерам безопасности контейнерных сред и сред контейнерной оркестрации – Jet Container Security Framework (JCSF).

На совместном вебинаре эксперты из Luntry и «Инфосистемы Джет» обсудят:
🔹Предысторию возникновения фреймворка
🔹Плюсы и минусы существующих документов
🔹Отличия JCSF от прочих стандартов
🔹Отдельные практики контейнерной безопасности и уровни зрелости для них
🔹Проведение аудита по JCSF

➡️ Регистрация

The Ultimate DevSecOps Playbook for 2025 AI, ML and beyond

Всем привет!

В приложении можно скачать электронную книгу от Hadess (~ 116 страниц), посвященную безопасной разработке.

Внутри можно найти информацию о:
🍭 KPI команды DevSecOPs и как их считать
🍭 Уровни зрелости DevSecOps (от Initial до Optimized)
🍭 Технологии, используемые для автоматизации практик безопасной разработки
🍭 Использование AI и LLM в DevSecOps – где и для чего они могу пригодиться
🍭 Немного про MLSecOps/AISecOps в DevSecOps

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

Знакомьтесь, Шерлок!

Всем привет!

Меня зовут Антон Гаврилов, я один из авторов этого канала. Приятно познакомиться!

Последний год мы вместе с командой работаем над собственной ASOC/ASPM/Иное (мне не очень нравятся эти аббревиатуры 😊) системой, которая получила имя «Шерлок».

В декабре 2024 года был выпущен первый релиз. И мне очень хочется показать его вам и всем, кому это будет интересно!

Если вы:
🍭 Хотите задавать каверзные вопросы
🍭 Хотите посмотреть на-еще-одно-отечественное-ПО
🍭 Продемонстрировать свой скепсис
🍭 Пожать руку, поделиться советом и пожелать удачи
🍭 …

То приходите на вебинар, который будет 13.02, начало в 11:00 (Мск). Да, будет небольшая презентация (для погружения в контекст), а основная часть будет посвящена «живой демонстрации».

Думаю, что на все про всё у нас уйдет часа 1,5. Но! Если вопросов будет много, то задержимся и найдем ответы на все 😊

Спасибо и до встречи!

Антон

P.S. Буду признателен за пересылку приглашения ☺️ Очень хочется узнать ваши мысли относительно того, что мы сделали и продолжаем делать!

Автоматизация создания схем для Kubernetes

Всем привет!

По ссылке можно найти утилиту, которая позволяет автоматизировать процесс создания диаграмм, визуализирующих взаимосвязь ресурсов приложения, запущенного в Kubernetes - KubeDiagrams.

Подобные утилиты существуют (и предоставлены в repo). KubeDiagrams отличается от них тем, что его можно очень по-разному настроить.

Сам процесс выглядит примерно так:
🍭 Применяем необходимые манифесты в кластере Kubernetes
🍭 Ждем пока все ресурсы будут созданы, pod – запущены и т.д.
🍭 Делаем kubectl get all,sa,cm,pod… -o=yaml > file.yaml
🍭 Передаем указанный файл на вход KubeDiagrams

Готово! Получаем красивую схему
Примеры работы утилиты можно найти в repo.

Насколько хорошо она себя покажет с «большими» приложениями – трудно сказать, надо экспериментировать! ☺️

P.S. Возможно, что есть те, кто ей пользовался и они захотят поделиться мнением ☺️

Использование AI для triage: опыт Semgrep

Всем привет!

Продолжаем тему использования AI для оптимизации процесса управления ИБ-дефектами при статическом анализе исходного кода.

«Мы рады заявить, что оценка Semgrep Assistant по обнаружению true positive совпадает с аналогичной оценкой наших специалистов в 95% случаев» - так начинается статья от Semgrep.

Далее в статье описано как именно команде удалось достичь таких впечатляющих результатов.

Например:
🍭 Процесс работы Assistant Autotriage – схема, дополнительный контекст (метаданные правил, предыдущие решения, примеры того, что (не) должно быть найдено и т.д.)
🍭 Сравнение используемых моделей (на выборке из 2000 findings)
🍭 Улучшение результативности за счет разных моделей, оптимизации prompt и т.д.

В завершение описаны идеи команды по дальнейшему развитию Assistant. Например, сейчас он сам не «закрывает» найденные ИБ-дефекты, а только подсказывает.

Рекомендуем! Читается легко, много всего интересного, включая дополнительные ссылки на исследования Semgrep в области использования машинного обучения.

В пятницу прошла интересная беседа уважаемых в мире DevOps людей 😎

Смотрели под лупой новую версию Штурвала и рассуждали нужен ли ванильный куб, если можно скачать бесплатную community версию продукта и не мучиться? 😵

Всем приятного просмотра 🤓

https://www.youtube.com/watch?v=1My_GAXjI3A

Полезные ссылки:
Telegram - https://t.me/shturval_community
Сайт - https://chislitellab.ru/shturval/

Использование AI в статическом анализе

Всем привет!

Статья от GitHub, в которой описано то, как они применяют AI для оптимизации процесса работы с результатами статического анализа ПО.

В статье приводится общая информация о том, как и для чего можно использовать AI в SAST.

Например, выявление большего количества ИБ-дефектов или помощь в их устранении.

Последнему как раз и посвящена основная часть статьи. Автор описывает процесс того, как работает Code Scanning Autofix в связке с CodeQL.

Алгоритм следующий:
🍭 Кодовая база сканируется с использованием CodeQL
🍭 Подготовка prompt’a с информацией об ИБ-дефекте для отправки в Copilot (описание уязвимости из базы CodeQL, пример исходного кода)
🍭 Проверка ответа, полученного от Copilot, удаление всего «лишнего»
🍭 Создание pull request, содержащего вариант по устранению ИБ-дефекта и его описание

Указанный выше алгоритм более детально описывается в статье, с примерами.

Кроме того, в статье очень много ссылок на полезные материалы по теме использования AI для анализа ПО.

Анализ достижимости: что это такое и как это работает?

Всем привет!

В приложении можно скачать презентацию Mike Larkin, в которой он наглядно показывает, что такое анализ достижимости и как его можно реализовать с использованием open source инструментов.

Авто рассматривает:
🍭 Что такое достижимый код
🍭 Общая информация об анализе достижимости и почему он так важен
🍭 CVE и «информативность» их описания
🍭 SBOM и его роль в анализе достижимости
🍭 Графы вызовов, их использование для понимания «кто вызывает кого» и не только

В результате у Автора получается объединить все вышеописанное вместе для того, чтобы рассмотреть анализ достижимости со всех сторон (пусть и поверхностно).

Для наглядности материал содержит отсылки на используемый инструментарий и примеры анализа для Golang и Java-приложения.

Помимо этого, можно ознакомиться с видео. Рекомендуем! Хотя бы потому, что в нем представлены примеры запуска утилит и комментарии Автора, чего нет в презентации.

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

Ротация секретов: how to?

Всем привет!

Небольшой, но тем не менее достаточно важный пятничный пост. Бывает так, что секрет был компрометирован. И его надо сменить.

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

В подборку вошли:
🍭 Atlassian
🍭 GitHub
🍭 GitLab
🍭 OpenAI
🍭 Slack и многое другое

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

Image Verify Cache в Kyverno

🔍 Всем привет!
Если вы уже знакомы с инструментом Kyverno, то знаете, что он помогает обеспечить соблюдение политик безопасности в кластере. В частности одно из его возможных применений — верификация образов, подписанных на этапе сборки.

Kyverno имеет неожиданную особенность — по-умолчанию он сохраняет в кэше ссылку на образ, для политик типа imageVerify. Согласно документации, это реализовано для снижения нагрузки на сеть, так как при повторном использовании образа проверка не повторяется. По умолчанию кеш хранится 60 минут.
Но что, если вам нужно изменить это поведение? Разработчики предусмотрели несколько вариантов:

1. Параметры запуска kyverno:
   - imageVerifyCacheEnabled — отключает кеш для imageVerify.
   - imageVerifyCacheMaxSize — определяет количество хранимых значений.
   - imageVerifyCacheTTLDuration — задает время хранения записи в кэше.
2. Использование параметра useCache: false в самой политике.

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

Kubewatch: оповещения о событиях в кластерах Kubernetes

Всем привет!

Kubewatch – утилита, которая позволяет получать оповещения о событиях в кластерах Kubernetes, связанных с ресурсами.

Например, создание Service, присвоение ClusterRoleBinding, изменение параметров Deployment и т.д.

Это может быть полезно команде информационной безопасности: узнать, что кому-то был предоставлен доступ или где-то изменили параметры Security Context.

Сейчас Kubewatch поддерживает «основные» ресурсы:
🍭 Deployment
🍭 Service
🍭 ClusterRole
🍭 Secret
🍭 ConfigMap и т.д.

Также можно реализовать настройку оповещений для CRD.

Данные можно отправлять в различные средства коммуникации, например, Slack, Mattermost, Teams, электронная почта и т.д.

А если нужно «что-то свое», то можно использовать обычный webhook.

A practical guide to software supply chain security

Всем привет!

В приложении можно скачать небольшую книгу (~ 21 страница) от Red Hat, посвященную информационной безопасности цепочки поставок ПО.

Книга состоит из разделов:
🍭 Общее описание того, что из себя представляет цепочка поставки ПО
🍭 Основные атаки на цепочку поставки ПО
🍭 Способы защиты от вышеперечисленных атак

Материал структурирован по этапам жизненного цикла ПО – от Create до Run.

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

Wormable XSS в Atlassian

Всем привет!

Команда Snapsec проводила аудит информационной безопасности Atlassian и обнаружила очень интересное поведение одной функции.

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

В статье Авторы рассказывают про:
🍭 Что такое link-based XSS и как их реализовать
🍭 Поиск «чего-то подходящего в продуктах Atlassian» для реализации link-based XSS
🍭 Повышение привилегий с помощью XSS в рамках одной организации
🍭 Повышение привилегий с помощью XSS в рамках нескольких организаций

Каждый шаг детально описан, есть примеры payloads, скриншоты и комментарии.