DevSecOps Talks

Application Security Introduction

Всем привет!

Начинаем новую рабочую неделю с плавного погружения в Application Security.

В приложении можно найти материал (~ 73 страницы), в котором описаны основы Application Security.

Например:
🍭 Те самые известные атаки (XSS, CSRF, SQLi, DDoS, IDOR и т.д.)
🍭 Secure Software Development Process (SAMM, BSIMM и т.д.)
🍭 Security Requirements Engineering
🍭 Security Design и не только

Неплохой обзорный материал, в котором собраны основные концепты, методологии, подходы и практики.

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

🚀 Шерлок прокачивает управление ИБ-дефектами!

24 июля в 11:00 мск приглашаем на вебинар по новому релизу «Шерлока» — AppSec-платформы, которая оптимизирует процессы безопасной разработки.

На вебинаре расскажем:
🐾 О возможностях Шерлока для автоматизации
🐾 О новом функционале платформы
🐾 Проведем живое демо и ответим на все ваши вопросы

📌 Успейте зарегистрироваться! 👇
👉 РЕГИСТРАЦИЯ НА ВЕБИНАР

Данные о Supply Chain атаках

Всем привет!

Автор репозитория проделал отличную работу и собрал информацию об общеизвестных Supply Chain атаках.

В наборе данных приведена информация о 56 OSS проектах и 59 инцидентах.

Для каждого случая есть своя «карточка» (конечно же в формате *.yaml!):
🍭 Наименование
🍭 Синопсис
🍭 Дата «реализации»
🍭 Ссылки на материалы по теме
🍭 Информация по артефактам и не только

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

Если хочется посмотреть «на все сразу», то в корне проекта есть oss_summary.csv, в котором представлена консолидированная информация.

EoL или End Of Life

Всем привет!

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

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

Хочется чего-то централизованного, удобного и автоматизируемого. Например, endoflife.date. Это ресурс, на котором собрана информация о различных релизах и их «актуальности» с точки зрения поддержки.

На сайте представлена информация о Ansible, Nginx, Redis, Argo CD, Kubernetes, Kyverno, SonarQube и не только.

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

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

Безопасность Golang parsers

Всем привет!

Разбор (parsing) данных, получаемых от непроверенных источников, может привести к разным последствиям.

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

В статье Trail of Bits Авторы исследуют насколько хороши различные Golang parsers с точки зрения информационной безопасности: можно ли им доверять по умолчанию, можно ли их делать более безопасными и что (не) следует использовать.

Для анализа используется несколько наиболее популярных библиотек для работы с JSON, XML и YAML.

После небольшой вводной про Marshalling и Unmarshalling Авторы переходят к самому интересному – сценариям атак.

Рассматривается:
🍭 (Un)Marshalling unexpected data
🍭 Parser differentials
🍭 Data format confusion

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

Завершает статью набор общих рекомендаций о том, как минимизировать риски при работе с JSON, XML, YAML.

Множество примеров, кода, пояснений! Рекомендуем к изучению!

Поиск уязвимостей в Helm Charts

Всем привет!

В предыдущем посте мы писали о том, как можно искать устаревшие версии используемых Helm Chart’ов.

А как быть с уязвимостями в них? По крайней мере в public-версиях chart’ов, которые используются? Например, есть ли там ошибки конфигураций или уязвимости?

Ответ на этот вопрос можно найти в статье от Cloudsmith.

Автор использует open source инструменты, такие как Trivy и OPA для анализа chart’ов до их активного использования в промышленных средах.

Помимо этого, Автор рекомендует всегда проверять репозиторий, в котором хранится chart. Обращать внимание рекомендуется на: поддержку, использование, автора.

В завершении статье можно найти несколько сценариев, описывающих возможные способы эксплуатации уязвимостей в Helm Chart.

Nova: поиск устаревших Helm Charts

Всем привет!

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

Да, есть специализированные решения, которые могут помочь управлять версиями. Например, тот же Helm. Однако, даже с ним, не всегда получается за всем уследить.

Именно эту проблему и решает Nova – open source проект от команды Fairwinds.

Работает максимально просто:
🍭 Устанавливаем
🍭 Запускаем nova find
🍭 Анализируем результаты

В качестве выходных данных Nova предоставляет информацию об установленной версии chart’a и его latest-версии.

Кроме того, можно посмотреть устаревшие версии образов контейнеров, которые используются в chart’e.

Больше информации об утилите и ее возможностях можно узнать в документации.

HackList: рекомендация по обучениям!

Всем привет!

Не знаете, что изучить на выходных? Не хочется самостоятельно искать материалы по интересующим вас темам?

Возможно, что HackList сможет вам помочь. Он представляет из себя небольшое web-приложение, которое ищет материалы по интересующим вас темам.

Внутри:
🍭 Рекомендации, сформированные с использованием AI на основе ваших интересов
🍭 Поиск по разным источникам: GitHub, OWASP, блоги, обучающие платформы
🍭 «Встроенный dataset» для быстрого получения информации
🍭 Категорирование проектов по разным ИБ-темам
🍭 Дедупликация результатов и приятный UI

Работает очень просто: вы описываете то, что вам интересно. HackList ищет разные проекты и статьи по теме. Читаете описание и начинаете обучение ☺️

Поддерживается около 15 различных ИБ-доменов, в том числе API Security, Mobile Security, DevSecOps и не только.

ШТУРВАЛЬЧИК?

Ребятам из «Лаборатории Числитель», видимо, было мало шуток про Штурвал, теперь они выпустили Штурвальчик.

Многие говорили, что он слишком много жрёт. Теперь минимальный конфиг — это:
▪️один хост с 6 CPU
▪️8 ГБ RAM
▪️80 ГБ хранилища

В целом на мощном ноуте можно раскатать парочку кластеров куба — этого хватит на управляющий и несколько клиентских.

Вопросы можно в Kubernetes-чате «Штурвала» задать.

Обнаружение угроз с Falco!

Всем привет!

Сегодня рассказываем про объемную статью (~ 17 минут), посвященную обнаружению угроз в Kubernetes с использованием Falco.

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

Далее Автор рассказывает про:
🍭 Как Falco обнаруживает угрозы, что есть правила
🍭 Способы установки Falco
🍭 Создание собственных правил для обнаружения угроз
🍭 Настройка оповещений, использование Falcosidekick
🍭 Примеры использования Falco из реальной практики
🍭 Сравнение Falco с другими решениями и не только

В итоге имеем отличный материал для знакомства с Falco.

Если хочется еще больше структурированной информации по решению, то рекомендуем обратиться к Falco from A to Y (про него мы писали тут).

Обновление DevSecOps Assessment Framework (DAF)

Всем привет!

Настала очередь обновления DAF и вот основные изменения нового релиза:
🦴 Появился маппинг DAF на DSOMM
🦴 Появился маппинг DAF на ГОСТ 56939-2024
🦴 Актуализировался маппинг DAF на BSIMM и SAMM
🦴 Появился автомаппинг DAF на PT Table top, SAMM и DSOMM. Работает так: вы заполняете практики в основной вкладке с практиками DAF (Вкладка "Маппинг со стандартами"), а эти же данные, но в разметке PT Table top, SAMM и DSOMM появляются на соответствующих вкладках. Таким образом, проводя аудит по DAF, вы проводите аудит сразу по еще трем другим фреймворкам
🦴 Дополнили вкладку с документами по безопасной разработке - теперь тут есть документы из ГОСТ 56939-2024
🦴 Актуализировали расчет FTE AppSec. Теперь расчеты более приближены к реальности
🦴 Скорректировали текст практик, добавили новые, переместили некоторые практики между уровнями, убрали и добавили новые опечатки

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

Как вы можете заметить, бо́льшая часть практик ГОСТ 56939-2024 и PT Table Top есть в DAF. Наш фреймворк вышел в сентябре 2023 года, и если вы ему следовали, то уже соответствуете новому и ГОСТ и Table Top 😉

Мы всегда открыты к обратной связи и ждем новых контрибьюторов!

Создание Kubernetes Audit Log Policy

Всем привет!

Kubernetes предоставляет достаточно сильный инструмент для сбора событий, описывающих происходящее в кластере – Audit Policy.

По умолчанию она «отключена»: ее сперва надо написать и настроить несколько параметров для kube-apiserver.

Нюанс состоит в том, что сперва может быть не очень понятно, а что надо записывать? Ответу на этот вопрос и посвящена статья.

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

После чего Автор приводит политику, которая (по его мнению) является оптимальной и описывает почему это так.

Кроме этого в статье приводятся Audit Policy от Amazon и Google (но они будут генерировать много событий, к этому надо быть готовым) на случай, если политика Автора вам не нравится и нужно что-то еще.

"Всё не так и всё не то" - хочу создать свою! Тогда, для ускорения процесса, можно воспользоваться «помощником»: Генератором политик аудита, разработанного командой Штурвала, о котором мы писали тут.

А для вдохновения использовать множество наработок от команды Luntry, посвященных вопросам журналирования Kubernetes и не только.

Может ли LLM генерировать безопасный код?

Всем привет!

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

Но что делать, когда хочется некоторой статистики, примеров, аналитики? В этом случае рекомендуем обратить внимание на BaxBench!

Benchmark, в котором авторы исследуют рассматриваемый вопрос. Авторы выбрали 392 задачи, которые описывают 28 сценариев с использованием 14 популярных фреймворков на 6 языках программирования. Далее они «попросили» LLM выполнить эти «задания» и проанализировали результаты.

Получилось следующее:
🍭 62% решений были либо некорректны, либо содержали уязвимости
🍭 Примерно 50% корректных решений не были безопасны
🍭 Получить «работающий и безопасный» вариант оказалось не так просто и требовало дополнительных усилий

Результаты от ChatGPT, DeepSeek, Qwen, Grok и не только представлены на сайте.

Для самостоятельного повтора эксперимента можно воспользоваться наработками из repo.

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

А что вы думаете по этому поводу? Насколько LLM хороши в написании безопасного кода исходя из вашего опыта?

Регистрируйтесь на K8s Community Day — главную сходку сообщества 😋

31 июля в Москве состоится первая независимая конфа Kubernetes Community Day для открытого сообщества профессионалов по куберу и тех, кто только начинает.

Что ждет участников?

◽️ Два пространства с хардкорными докладами, дискуссиями и воркшопами, интерактивы и IT StandUp.
◽️ Живое общение с комьюнити в уютной атмосфере — без HR-стендов и дорогих билетов.
◽️ Выступления от крутых экспертов из Yandex Cloud, еcom.tеch, VK, «Инфосистемы Джет», Luntry, «Лаборатории Числитель», Lamoda Tech, МКБ, Rebrain, Cloud ru и др.
◽️ Честные истории про кейсы, факапы и «боли».

Формат: офлайн и онлайн.

🤝 Участие бесплатное. Регистрация уже открыта!

Kingfisher: анализ секретов от…

Всем привет!

… MongoDB! Да, все так! История о том, как pet-проект превратился в один из основных компонентов анализа наработок компании.

Автор использовал разные open source сканеры для поиска секретов. И во всех из них его «что-то не устраивало»: скорость анализа, количество false positive, ограниченная возможность настройки и т.д.

Решение очевидно – сделать свое! Так и родился Kingfisher.

Из ключевых особенностей можно отметить:
🍭 Высокая скорость работы
🍭 Анализ Git Repo (Remote/Local), истории commit’ов, файловых систем
🍭 Функциональность валидации секретов (например, через отправку API запросов)
🍭Локальная установка и использование, данные «никуда не передаются»
🍭 «Внутри» используются разные типы анализа: pattern matching, энтропия, поддержка некоторых языков программирования для обогащения/уточнения результатов

Больше информации об утилите можно найти в статье. Там также присутствует статистика по скорости работы Kingfisher в сравнении с Trufflehog и GitLeaks.

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

Обновление Jet Container Security Framework (JCSF)

Всем привет!

Свершилось долгожданное: мы учли пожелания всех заинтересованных и обновили JCSF!

Основные изменения:
🦴 Появился маппинг JCSF на CIS Benchmark for Docker
🦴 Появился маппинг JCSF на CIS Benchmark for Kubernetes
🦴 Появился маппинг JCSF на 118 Приказ ФСТЭК России
🦴 Актуализированы (дополнены, изменен текст) некоторые практики JCSF, а также частично перемещены в другие домены
🦴 Появился домен по безопасности Docker и Docker Swarm
🦴 Улучшилось визуальное оформление, исправлены опечатки и ошибки, добавлены новые

Качайте, анализируйте документ и вашу контейнерную инфраструктуру!
Присоединяйтесь к совершенствованию JCSF и становитесь контрибьютором (мы открыты к любым предложениям и отзывам)!

Управление доступом: SSH ключи или сертификаты?

Всем привет!

Управление доступом через SSH ключи повсеместно используется. Генерируем ключевую пару, помещаем открытый ключ на рабочую станцию и все работает.

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

А что, если попробовать использовать не SSH ключи, но SSH-сертификаты? В теории это может решить проблемы, описанные выше. Именно этому посвящена статья.

Идея в том, чтобы:
🍭 Создать сервис, который будет выпускать недолго живущие сертификаты
🍭 Пользователь запрашивает такой сертификат. 🍭 Сервис решает можно ли его выдавать
Получив сертификат, пользователь инициирует SSH соединение с целевым хостом
🍭 SSH daemon хоста проверяет валидность сертификата, осуществляется проверка прав подключения
🍭 Пользователь получает доступ

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

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

А что вы думаете? Имеет ли такой механизм место быть или лучше использовать «привычные» подходы?

Как работают Validating Admission Policy?

Всем привет!

Еще одна статья, в которой описывается «как оно работает под капотом?». На этот раз речь пойдет про Validating Admission Policy и их реализацию в Kubernetes.

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

После небольшой вводной Автор переходит к описанию того, что это такое из чего оно состоит в Kubernetes. Рассматривается «собственный механизм», а не сторонние (Kyverno, Gatekeeper и т.д.).

В статье рассказано о:
🍭 API Definition. Из каких API состоит Validating Admission Policy
🍭 Controller Reconciliation. Из чего она состоит, какие задачи выполняются
🍭 Resource Admission. Как осуществляется проверка создаваемых в кластере ресурсов
🍭 Expression Cost Analysis. Контроль того, что Kubernetes API Server’у не станет «плохо» от проверок

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

Завершает статью немного примеров анализа манифестов и как можно реализовать мониторинг Validating Admission Policy с использованием Prometheus.

Kube Composer

Всем привет!

Нет, это не то, о чем вы подумали! ☺️ Это не утилита, которая превращает compose-файлы в Kubernetes-манифесты.

Kube Composer – это интуитивно понятный YAML-генератор ресурсов кластера, которые вы хотите создать.

Представляет он из себя небольшое web-приложение, которое можно развернуть «у себя», так и воспользоваться playground’ом.

Он позволяет:
🍭 Описывать требуемые ресурсы и их параметры непосредственно в UI
🍭 Работает с Deployments, Services, Volumes, Ingress и не только
🍭 Наглядно показывает связность между разными Kubernetes
🍭 И, конечно же, генерирует YAML-файлы, которые потребуются для создания ресурсов

Не зря говорят, что лучше один раз увидеть, чем сто раз услышать. Поэтому предлагаем вам посмотреть на его возможности воочию.

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

P.S. А еще там можно посмотреть специально подготовленное demo

Что такое CNI и как он работает

Всем привет!

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

В Kubernetes за это отвечает CNI – Container Network Interface – и его реализации (plugin’ы). О том, как это работает можно прочитать в статье.

В ней Автор описывает:
🍭 Из каких «компонентов» состоит CNI plugin, какие его основные задачи
🍭 Как pod «подключается» к сети
🍭 Логика работы CNI plugin’a «под капотом» (создание Virtual Ethernet Pair, назначение IP pod и т.д.)
🍭 Обеспечение сетевой связности между узлами кластера и не только

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

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

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