DevSecOps Talks

Chainguard: интеграция со сканерами уязвимостей

Всем привет!

Вторая статья из серии This Shit is Hard (про первую, посвященную Chainguard Factory) мы писали тут.

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

Если упростить, то сканеры работают примерно так:
🍭 Анализ артефакта (ELF-файл, JAR-файл, образ контейнера и т.д.) с целью понять, что в него «положили»
🍭 Соотношение полученной информации (пакеты, версии) с известными источниками данных об уязвимостях
🍭 Обогащение «контекстом». Если сканер понимает откуда был получен пакет, то он может запросить дополнительную информацию от поставщика

Третий пункт – именно то, на что обращает внимание команда Chainguard. Они составляют определенные файлы, в которых содержится дополнительная информация.

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

Ребята ежедневно сканируют собираемые образы (они используют Grype) и постоянно работают над сокращением уязвимостей.

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

Сканеров очень много и все они работают по-разному. Поэтому Chainguard выпустили собственные рекомендации о том, как можно с ними интегрироваться, на что обращать внимание и как можно реализовать дополнить результаты работы сканера данными из их feeds. Кроме того, они размещают информацию на OSV.dev.

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

P.S. Список сканеров, которые поддерживает Chainguard на текущий момент, доступен тут.

Offensive Container Security: техники, сценарии атак

Всем привет!

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

В статье содержится информация о:
🍭 Наиболее «популярные» ошибках в конфигурации Docker (privileged, exposed docker socket, fs mount и т.д.)
🍭 Наиболее «популярных» ошибках в конфигурации Kubernetes (exposed endpoint, token abuse, RBAC misconfigurations и т.д.)
🍭 Техниках побега из контейнера и повышения привилегий
🍭 Способах закрепления и дальнейших действиях в кластере
🍭 Атаках на цепочку поставки, применимых к контейнеризации

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

Использование нейросетей для выявления секретов, опыт Wiz

Всем привет!

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

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

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

Именно этому и посвящена статья от Wiz, в которой команда описывает свой путь.

«Традиционные» модели (GPT, Claude Sonnet и т.д.) им не подошли по ряду причин:
🍭 Слишком сильное потребление ресурсов (Wiz анализирует миллионы файлов ежедневно)
🍭 Слишком высокая стоимость (обусловленная, опять-таки, большим количеством анализируемой информации)
🍭 Передача конфиденциальной информации (многие пользователи Wiz не хотели, чтобы их данные попадали в вышеуказанные сети)

Поэтому команда решила отойти от парадигмы «bigger is better» и использовать небольшую модель, которую обучили выполнять ровно одну задачу – искать секреты в исходном коде и конфигурационных файлах.

Все этапы: от формирования набора данных (data set) до тестирования и анализа результатов (ожидание/реальность) представлены в статье.

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

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

DevOps VS ИБ: кто кого? ⁉️

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

14 августа (четверг) в 18:00 приглашаем вас присоединиться к настоящему батлу DevOps и ИБ — со взаимными претензиями, дракой и реальными примерами из жизни.

Среди вопросов дискуссии:

🍭 Забытые секреты, неверные доступы и не только: чем пренебрегают команды DevOps?
🍭 Часто встречающиеся проблемы ИБ в пайплайнах.
🍭 Топ абсурдных требований от безопасников.
🍭 Кто такой ибэшник мечты?
🍭 Кто должен быть медиатором во время конфликтов?
🍭 Успешные кейсы интеграции DevOps и ИБ.

⤵️ Регистрация и подробная программа.

Что такое анализ достижимости? Часть 3!

Всем привет!

Завершающая статья из цикла, посвященного анализу достижимости (о первых двух мы писали тут и тут).

В последней части Автор рассказывает о сложностях, которые присущи Runtime Reachability. Одной из таких сложностей является то, что все понимаю ее по-разному.

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

С точки зрения Автора все несколько иначе:
🍭 Зависимость загружена и, возможно, используется. Имеет место быть. Ведь если нет зависимости, то не т и уязвимости. Но сильно не поможет.
🍭 Доступ по сети. Может быть использован для расстановки приоритетов. Если есть N приложений с уязвимостью, эксплуатируемой удаленно и только 2 доступны извне – то лучше обратить внимание на них
🍭 Исполнение уязвимой функции. Самое интересное – именно этот способ может позволить максимально эффективно отсеять лишнее. Ведь если зависимость загружена, это не означает, что используется уязвимый метод

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

Нюанс в том, что информацию об исполнении уязвимой функции в runtime получить не так просто и крайне мало средств автоматизации.

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

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

Что такое анализ достижимости? Часть 2!

Всем привет!

Продолжение вчерашнего поста. Автор определился с тем, что такое анализ достижимости и пошел дальше.

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

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

Далее Автор разбирает каждый из типов более детально и с примерами. Например, в чем разница между Package Level Reachability и Function Level Reachability, если говорить про статический анализ достижимости.

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

Что такое анализ достижимости?

Всем привет!

Этот термин (хоть он далеко и не новый) появляется все чаще и чаще. Но что он означает? Как обычно, разные специалисты/компании интерпретируют его по-своему.

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

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

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

Например, понимание того:
🍭 Загружена ли библиотека
🍭 Используется ли метод
🍭 Доступно ли ПО извне
🍭 Есть ли какие-то меры по ИБ

может сильно помочь. И да, CVE может и присутствовать, но эксплуатировать ее нельзя. Тогда это false positive?

Поэтому, по мнению Автора, анализ достижимости это не только про комбинирование практик SAST и SCA, но и про понимание контекста – инфраструктуры, средств защиты.

Таким образом получается, что цель не в снижении false positive, а в поиске true positive.

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

Predictive Vulnerability Database

Всем привет!

Сегодня хотим поделиться с вами ресурсом от Miggo – Predictive Vulnerability Database. Да, еще один агрегатор информации о «CVE». Но не совсем!

Помимо стандартной информации:
🍭 Оценка уровня критичности (CVSS v3.1)
🍭 EPSS
🍭 Даты публикации, обновления
🍭 Наличия исправления

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

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

Из нюансов – информация о методах есть только для уязвимостей, которым менее 60 дней и автоматизировать обращение к базе через API (по крайней мере бесплатно) – не получится.

В остальном – она открыта для использования ☺️

«Внутри» Chainguard Factory

Всем привет!

Команда Chainguard известна тем, что создает и поддерживает образы с минимальным количеством уязвимостей. Их SLA: 7 дней для «Критичных», 14 для «Высоких», «Средних» и «Низких».

И это сложно! Собирать множество образов для разных дистрибутивов с невероятным количеством разных зависимостей…

«Мы делаем это не потому, что это просто, а потому, что думали, будто это будет просто». Если вам интересно узнать о том, как это устроено «внутри», то предлагаем прочесть статью с говорящим названием «This Shit is Hard».

В ней Автор разбирает следующие области:
🍭 Сборочная линия. От GitHub Actions до собственных наработок
🍭 Команда. Да-да, всегда самое важное и ценное
🍭 Роботизация. Автоматизация рутинных задач, чтобы команда хоть иногда отдыхала
🍭 Использование ИИ. Куда без него 😅
🍭Тестирование. «Нельзя просто так взять и собрать»
🍭 Доставка. Как сделать так, чтобы наработки забрали быстро и безопасно

В статье нет деталей, тем не менее читается она на одном дыхании.

Есть такой тезис, что «весь код – ваш код». Команда Chainguard усиливает идею – «относитесь к конвейеру сборки так, будто это промышленное окружение».

Рекомендуем к прочтению!

Как «безопасный» кластер Kubernetes был взломан за 17 минут

Всем привет!

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

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

Однако, это не помогло.

Случилось примерно следующее:
🍭 Злоумышленник просканировал публично доступные endpoints (забыли про kubelet read-only port)
🍭 Быстро нашел уязвимый контейнер (почему он таким стал – лучше прочтите сами)
🍭 При помощи него развернул майнер криптовалюты
🍭 Узлы кластера начали «разваливаться»

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

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

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

Gitxray: анализ GitHub репозиториев

Всем привет!

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

Он позволяет собрать множество информации о репозитории для последующего анализа.

Например:
🍭 Искать чувствительную информацию в профилях contributors
🍭 Идентифицировать не настоящие (fake) или зараженные (infected) репозитории
🍭 Анализ времени commit’ов для идентификации аномалий
🍭 Предоставлять сведения об артефактах релизов, которые были изменены уже после релиза
🍭 И многое другое

Устанавливается и запускается крайне просто. Результаты работы утилиты предоставляются в виде наглядного html-отчета.

Больше информации об Gitxray можно найти в репозитории или в документации.

Open Source Project Security Baseline

Всем привет!

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

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

Всего порядка 50 рекомендаций. Например:
🍭 Когда был выпущен релиз, то должна обновиться и документация
🍭 Должна вестись запись всех изменений (само изменение, Автор, дата)
🍭 Для каждого проекта должен быть указать контакт по вопросам ИБ
🍭 Перед тем, как принять изменение, необходимо убедиться, что тесты пройдены и функционал соответствует ожиданиям
🍭 Все релизные объекты должны быть однозначно «связаны» с релизом и многое другое

Указанные практики можно использовать, например, при оценке надежности open-source проекта или использовать у себя (да, применимы далеко не все, но можно найти вполне интересные).

Помимо этого, для каждой практики кратко описано зачем она нужна (какой риск она сокращает), приведен небольшой набор рекомендаций и соотношение с иными стандартами и фреймворками (SSDF, PCI DSS, SAMM и т.д.)

Zeropod: оптимизация потребления ресурсов в Kubernetes

Всем привет!

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

При этом они потребляют ресурсы, которые могут быть нужнее «соседу». Как быть? Например, делать scale down до 0. И именно это и делает Zeropod.

Если просто, то по истечении некоторого времени от последнего TCP-соединения, он делает checkpoint (используя CRIU) и scale down до 0.

После, если TCP-соединения появляется вновь, pod восстанавливается и продолжает работу. Для пользователя это происходит «бесшовно». При этом реализуется оптимизация использования вычислительных ресурсов кластера Kubernetes.

Более детально процесс и логика работы Zeropod описаны в GitHub-репозитории проекта. Помимо этого, в repo можно найти информацию по установке, настройке и возможностях утилиты.

Важно: концепт, возможно, и интересный, но использовать такое "у себя" лучше после плотного тестирования ☺️

А как вы думаете, есть ли в этом смысл или "нет, очень опасно и зачем оно вообще нужно"?

Используете проверку подписей и хэшей компонентов у себя в разработке?

Практика T-CODE-SC-2-3 предполагает проверку цифровых подписей и контрольных сумм компонентов. Казалось бы, звучит логично и даже просто. Но как обстоят дела на практике?

Что можно использовать прямо сейчас:
🔍 npm: npm ci --verify-store-integrity
🔍 pip: hashin добавляет sha256 в requirements.txt
🔍 poetry: poetry.lock содержит sha256
🔍 maven: проверка jar — sha256sum -c lib.jar.sha256
🔍 GPG/PGP: gpg --verify lib.jar.asc lib.jar

Чаще всего приходится писать свои скрипты: в пайплайне, в CI/CD или обвязке пакетных менеджеров. Готового единого решения, которое проверяет всё — пока нет.

А у вас как ?
- Используете ли вы проверку хэшей/подписей?
- Где реализовали — в CI, на ARM, в IDE?
- Какие инструменты подошли?
- Есть ли ограничения, которые мешают внедрению?
- Считаете ли эту практику соответствующей 2 уровню зрелости по DevSecOps Assessment Framework?

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

OpenCVE: управление информацией об уязвимостях

Всем привет!

OpenCVE – проект, который позволяет управлять данными о CVE, получаемыми из различных источников (NVD, RedHat, MITRE, Vulnrichment и т.д.)

Из ключевых функций можно выделить:
🍭 Наличие интерактивного графического web-интерфейса
🍭 Возможность «подписки» на определенные CVE с последующим получением уведомлений об изменениях
🍭 Получение комплексной информации об уязвимостях
🍭 Отслеживание истории изменения CVE
🍭 Создание собственных дашбордов
🍭 Интеграция с используемыми сервисами через API/Webhook и не только

Решение платное, но есть бесплатный вариант с некоторым (не критическим) ограничением по функционалу.

Установка возможна как в облаке, так и on-premise.

Больше информации об OpenCVE можно найти в GitHub-репозитории проекта и в документации.

Вредоносный код в `is`

Всем привет!

Еще один пример атаки на цепочку поставок ПО. На этот раз «героем» стала is - достаточно популярная JavaScript библиотека (2.8 млн загрузок в неделю).

В нее было встроено вредоносное ПО, которое собирало различную информацию (имя, ОС, сведения о CU и т.д.) о рабочей станции, на которой оно запускалось, и передавала данные «наружу» через websocket.

Если кратко, то:
🍭 Учетные данные maintainer’a были скомпрометированы с использованием phishing
🍭 Злоумышленники сменили owner’a, что оставалось незамеченным несколько часов
🍭 В is был добавлен вредоносный код

Подмена была обнаружена достаточно оперативно и уже устранена: уязвимая версия – v3.3.1 – уже удалена, после чего уже легитимные авторы разместили обновленный вариант – v3.3.2.

Рекомендации постепенно становятся классикой: понимать из чего именно собирается ПО; контролировать то, что попадает в периметр; не забывать, что весь код (и заимствованные библиотеки тоже) - это всё ваш код, который надо анализировать; делать все это на регулярной основе.

P.S. Больше подробностей об инциденте можно узнать из статьи и ссылок, которые в ней доступны.

Библиотека Validating Admission Policies

Всем привет!

В репозитории можно найти набор Validating Admission Policies в формате CEL, подготовленных командой ARMO.

За основу при разработке политик был взят перечень ИБ-контролей, используемый в Kubescape.

Примеры того, что есть в репозитории:
🍭 Forbidden Container Registries
🍭 Automatic mapping of service account
🍭 Writable hostPath mount
🍭 Naked PODs
🍭 Image pull policy on latest tag и другие

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

Использование Validating Admission Policies может быть целесообразно в том случае, если вы не хотите использовать сторонние решения (Kyverno, Gatekeeper и их аналоги) и полностью использовать функционал, доступный в Kubernetes.

Kubetail – logging dashboard для Kubernetes

Всем привет!

Если для анализа логов в моменте нужно что-то легковесное, небольшое, простое в эксплуатации, то можно познакомиться с Kubetail.

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

Состоит Kubetail из CLI-утилиты и интерактивного dashboard, который можно установить как локально, так и в кластере Kubernetes.

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

Больше подробностей можно прочесть в документации.

Кстати, если хочется посмотреть, как это выглядит, то у Kubetail есть интерактивная демо-площадка, доступная вот тут.

Уязвимости OAuth и что с ними делать

Всем привет!

Open Authentication (OAuth) повсеместно используемый способ аутентификации, в котором вместо логина и пароля используется токен.

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

Именно им и посвящена статья от Outpost24. В ней автор рассматривает:
🍭 Open redirect and redirect URI manipulation
🍭 Missing or weak CSRF/state protections
🍭 Implicit flow and lack of PKCE (Proof Key for Code Exchange)
🍭 Inadequate scope validation and overly broad permissions
🍭 Token leakage via insecure storage or transport и не только

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

Кстати, на сайте Outpost24 можно найти еще много чего интересного по тематике Application Security.