Централизованное управление уязвимостями
Всем привет!
Когда сканеров становится много, а уязвимостей еще больше, неплохо бы иметь единое место для их сбора, фильтрации и приоритизации. SecObserve (open-source) – может стать новым отличным решением на замену DefectDojo:
Платформе меньше двух лет, но уже доступно множество фич:
🎯 Интегрируется в CI/CD, поддерживает SARIF и парсеры на множество инструментов
🎯 Удобное управление проектами – поддержка веток и версий
🎯 Отслеживает лицензии – импорт информации из SBOM (CycloneDX и SPDX)
🎯 Обогащает данные с помощью Exploit Prediction Scoring System (EPSS)
🎯 Дает метрики как по всем продуктам так и по отдельным
🎯 Экспортирует уязвимости в трекеры (Jira, GitLab, GitHub), отправляет уведомления в Slack, Teams, email
🎯 REST API для автоматизации
🎯 Хорошая документация
Из минусов:
🤷♂️ Нет поддержки LDAP, что часто важно
🤷♂️ Не понятно как поведет себя с большим кол-вом данных
А вы как управляете уязвимостями в проектах?
Всем привет!
Когда сканеров становится много, а уязвимостей еще больше, неплохо бы иметь единое место для их сбора, фильтрации и приоритизации. SecObserve (open-source) – может стать новым отличным решением на замену DefectDojo:
Платформе меньше двух лет, но уже доступно множество фич:
🎯 Интегрируется в CI/CD, поддерживает SARIF и парсеры на множество инструментов
🎯 Удобное управление проектами – поддержка веток и версий
🎯 Отслеживает лицензии – импорт информации из SBOM (CycloneDX и SPDX)
🎯 Обогащает данные с помощью Exploit Prediction Scoring System (EPSS)
🎯 Дает метрики как по всем продуктам так и по отдельным
🎯 Экспортирует уязвимости в трекеры (Jira, GitLab, GitHub), отправляет уведомления в Slack, Teams, email
🎯 REST API для автоматизации
🎯 Хорошая документация
Из минусов:
🤷♂️ Нет поддержки LDAP, что часто важно
🤷♂️ Не понятно как поведет себя с большим кол-вом данных
А вы как управляете уязвимостями в проектах?
👍10❤2🔥2
OWASP DevSecOps Guideline
Всем привет!
Как-то так получилось, что мы ни разу не писали про материалы по DevSecOps от OWASP, а именно про OWASP DevSecOps Guideline.
В нем собрана информация о:
🍭 Моделировании угроз
🍭 Статическом и динамическом анализе
🍭 Композиционном анализе
🍭 Анализе образов и контейнеров и т.д.
Для каждого раздела описано что это такое и какими open source инструментами можно пользоваться для реализации практики.
Кроме этого, есть ссылки на полезные материалы по теме.
Из нюансов – проект давно не обновлялся. Однако, базовые вещи так и не потеряли актуальности и им можно пользоваться.
Всем привет!
Как-то так получилось, что мы ни разу не писали про материалы по DevSecOps от OWASP, а именно про OWASP DevSecOps Guideline.
В нем собрана информация о:
🍭 Моделировании угроз
🍭 Статическом и динамическом анализе
🍭 Композиционном анализе
🍭 Анализе образов и контейнеров и т.д.
Для каждого раздела описано что это такое и какими open source инструментами можно пользоваться для реализации практики.
Кроме этого, есть ссылки на полезные материалы по теме.
Из нюансов – проект давно не обновлялся. Однако, базовые вещи так и не потеряли актуальности и им можно пользоваться.
👍8
🔍 TruffleHog Analyzer – анализ утекших API-ключей
Всем привет!
Обнаружение секретов в коде – уже стандарт, но что делать, если ключ утек? TruffleHog предлагает новый подход:
🎯 Проверяет активность ключа – действующий он или нет
🎯 Определяет владельца – чей именно ключ
🎯 Анализирует доступ – какие ресурсы доступны по ключу (доступно до 20 источников)
🎯 Выявляет привилегии – что можно делать с этими ресурсами
🎯 Помогает в отзыве – инструкция как отозвать секрет
Если хотите разобраться глубже – вебинар по теме.
Как вы проверяете утекшие ключи? Пользуетесь ли авто-валидацией? Делитесь в комментариях! 💁♂️
Всем привет!
Обнаружение секретов в коде – уже стандарт, но что делать, если ключ утек? TruffleHog предлагает новый подход:
trufflehog analyze позволяет провести глубокий анализ ключа, выяснив, какие у него разрешения и какие ресурсы он затрагивает. Теперь можно не только находить ключи, но и сразу понимать их влияние. 🎯 Проверяет активность ключа – действующий он или нет
🎯 Определяет владельца – чей именно ключ
🎯 Анализирует доступ – какие ресурсы доступны по ключу (доступно до 20 источников)
🎯 Выявляет привилегии – что можно делать с этими ресурсами
🎯 Помогает в отзыве – инструкция как отозвать секрет
Если хотите разобраться глубже – вебинар по теме.
Как вы проверяете утекшие ключи? Пользуетесь ли авто-валидацией? Делитесь в комментариях! 💁♂️
Trufflesecurity
Self-Discovering API Permissions ◆ Truffle Security Co.
his webinar helps security teams determine if the credential is still active, who’s credential is it, the resources and permissions associated with it, and more.
❤🔥9👍6🔥4❤3
Анализ угроз для 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, источники событий, которые помогут ее обнаружить и сама логика обнаружения.
Статья не затрагивает темы защиты, фокусируясь полностью на идентификации. Причина проста – защита потребовала бы отдельной статьи по теме 😊
Всем привет!
Команда 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, источники событий, которые помогут ее обнаружить и сама логика обнаружения.
Статья не затрагивает темы защиты, фокусируясь полностью на идентификации. Причина проста – защита потребовала бы отдельной статьи по теме 😊
Medium
Securing Continuous Delivery: Argo CD Threat Detection
Explore the techniques our SOC team employs to detect threats in Argo CD
👍6❤1
Компрометация данных через session tokens…
Всем привет!
… или еще одна история о том, как заработать 15 000$ на bug bounty. Все начиналось как обычно, bug hunter взял «заказ» на Hackerone на уже знакомую ему систему.
События начали стремительно развиваться после того, как он заполнил данные на странице регистрации – имя, email, прочую информацию.
Оказывается, что сервер вернул сессионный token, но не простой, а без… expiration date. Это заинтересовало исследователя и он решил продолжить изучение.
После завершения регистрации и создания учетной записи приложение перенаправило его на страницу вида
Следующий шаг вполне логичен – попробовать поискать аналогичные token в сети. Google Dorks в помощь и да, token был получен, как и доступ к конфиденциальной информации его владельца.
В завершении статьи описываются дополнительные исследования Автора относительно того, сколько по времени подобная уязвимость была в приложении. Рассказывать не будем, рекомендуем прочесть статью 😊
Всем привет!
… или еще одна история о том, как заработать 15 000$ на bug bounty. Все начиналось как обычно, bug hunter взял «заказ» на Hackerone на уже знакомую ему систему.
События начали стремительно развиваться после того, как он заполнил данные на странице регистрации – имя, email, прочую информацию.
Оказывается, что сервер вернул сессионный token, но не простой, а без… expiration date. Это заинтересовало исследователя и он решил продолжить изучение.
После завершения регистрации и создания учетной записи приложение перенаправило его на страницу вида
https://somesite.com/apply/information/?s=success&token=… Все так, там был «тот самый token без срока действия».Следующий шаг вполне логичен – попробовать поискать аналогичные token в сети. Google Dorks в помощь и да, token был получен, как и доступ к конфиденциальной информации его владельца.
В завершении статьи описываются дополнительные исследования Автора относительно того, сколько по времени подобная уязвимость была в приложении. Рассказывать не будем, рекомендуем прочесть статью 😊
Medium
Exposing PII and SSNs through Persistent Session Tokens — $15,000 Bug Bounty
Intro: Flanking the Application
👍3
Как TruffleHog ускорил поиск секретов за счет алгоритмических оптимизаций
Всем привет!
Отличная статья о том как TruffleHog обновил алгоритмы сканирования, ускорив поиск утекших секретов. Теперь сканирование быстрее без потери точности – за счет оптимизации переходов при построении автомата Aho-Corasick.
Что изменилось?
🎯 Один проход по коду: ~800 ключевых слов от всех детекторов проверяются за раз, без повторных циклов
🎯 Aho-Corasick + предвычисления: заранее просчитаны переходы состояний, что сократило CPU-нагрузку
🎯 Быстрее на 11–17%: особенно заметно на больших репозиториях
🎯 Масштабируемость: добавление новых детекторов больше не замедляет анализ. Применение Aho-Corasick обеспечивает линейную масштабируемость по объему данных
🎯 Следующий шаг — оптимизация памяти и ускорение сканирования до 22–40%
Подробнее – в разборе алгоритма
Используете TruffleHog? 🐽
Всем привет!
Отличная статья о том как TruffleHog обновил алгоритмы сканирования, ускорив поиск утекших секретов. Теперь сканирование быстрее без потери точности – за счет оптимизации переходов при построении автомата Aho-Corasick.
Что изменилось?
🎯 Один проход по коду: ~800 ключевых слов от всех детекторов проверяются за раз, без повторных циклов
🎯 Aho-Corasick + предвычисления: заранее просчитаны переходы состояний, что сократило CPU-нагрузку
🎯 Быстрее на 11–17%: особенно заметно на больших репозиториях
🎯 Масштабируемость: добавление новых детекторов больше не замедляет анализ. Применение Aho-Corasick обеспечивает линейную масштабируемость по объему данных
🎯 Следующий шаг — оптимизация памяти и ускорение сканирования до 22–40%
Подробнее – в разборе алгоритма
Используете TruffleHog? 🐽
Trufflesecurity
Under the Hood: The Algorithmic Power Behind TruffleHog’s Secret Scanning (Part 1 of 2) ◆ Truffle Security Co.
TruffleHog uses the Aho-Corasick algorithm to efficiently scan data for sensitive information. AThis post is the first in a two-part serie dives into CPU optimizations, focusing on how precomputing failure transitions can speed up the scanning process.
🔥7❤2👍2
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-файлы ☺️
Всем привет!
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-файлы ☺️
GitHub
GitHub - devops-kung-fu/bomber: Scans Software Bill of Materials (SBOMs) for security vulnerabilities
Scans Software Bill of Materials (SBOMs) for security vulnerabilities - devops-kung-fu/bomber
Finalizers в Kubernetes: что это и зачем?
Всем привет!
Наверное, при работе с Kubernetes вы встречались с тем, что после
Зачастую причина этого состояния кроется вупокоиться с миром удалять что-либо.
Просто и понятно о них описано в статье:
🍭 Автор делает собственный
🍭Поясняет что делать, если
🍭 Рассказывает о том, что есть
Статья небольшая, зато дает общее представление о том, как «победить» состояние бесконечного удаления.
Всем привет!
Наверное, при работе с Kubernetes вы встречались с тем, что после
kubectl delete … удаляемый ресурс «подвисал» в состоянии terminating.Зачастую причина этого состояния кроется в
finalizers - тех самых «очень важных делах», не совершив которые нельзя Просто и понятно о них описано в статье:
🍭 Автор делает собственный
finalizer и пытается удалить ресурс🍭Поясняет что делать, если
terminating все-таки висит🍭 Рассказывает о том, что есть
finalizer и как они устроеныСтатья небольшая, зато дает общее представление о том, как «победить» состояние бесконечного удаления.
SRC Innovations
Can't delete your kube pod? Here's the reason why!
If you can't delete your kubernetes pod, the most common reason are finalizers. This article tells you more about finalizers, what they are, and how you can fix a Terminating pod that just won't terminate!
👍4
Введение в OCI
Всем привет!
При работе с образами контейнеров вы, вероятно, слышали про то, что они создаются в соответствии со спецификацией Open Container Initiative, OCI.
Но что это значит? Если вас интересует ответ на этот вопрос, то рекомендуем прочесть статью.
В ней Автор разбирает несколько типов OCI-спецификаций:
🍭 OCI Image-spec: структура образов контейнеров
🍭OCI Distribution-spec: способы распространения образов контейнеров
🍭OCI Runtime-spec: реализация жизненного цикла контейнеров
Для каждой спецификации Автор кратко описывает что она из себя представляет, какие данные содержит и зачем она нужна.
В завершении приведены ссылки на полное описание спецификаций, если вам интересно разобраться более подробно
Всем привет!
При работе с образами контейнеров вы, вероятно, слышали про то, что они создаются в соответствии со спецификацией Open Container Initiative, OCI.
Но что это значит? Если вас интересует ответ на этот вопрос, то рекомендуем прочесть статью.
В ней Автор разбирает несколько типов OCI-спецификаций:
🍭 OCI Image-spec: структура образов контейнеров
🍭OCI Distribution-spec: способы распространения образов контейнеров
🍭OCI Runtime-spec: реализация жизненного цикла контейнеров
Для каждой спецификации Автор кратко описывает что она из себя представляет, какие данные содержит и зачем она нужна.
В завершении приведены ссылки на полное описание спецификаций, если вам интересно разобраться более подробно
Medium
OCI Introduction: The Full Journey from Code to Container in a Kubernetes Environment
Introduction to OCI
⚡5
Сравнение LLM для моделирования угроз
Всем привет!
По ссылке можно найти результаты сравнения возможностей LLM по моделированию угроз.
В выборку попали: gemma, Phi, DeepSeek, llama и не только.
Сравнение проводилось по группам критериев:
🍭 STRIDE Coverage & Accuracy: насколько модель покрывает все группы угроз в соответствии с методологией STRIDE
🍭Threat Completeness: показывает количество угроз, качество описания
🍭Technical Validity: насколько описание является технически корректным и релевантным
🍭JSON Structure Compliance: проверка корректности заполнения и формата данных в итоговых результатах
Все результаты представлены в виде интерактивных графиков – общие результаты, результаты по приведенным выше группам и т.д.
Больше подробностей про саму методологию можно найти в соответствующем разделе сайта.
P.S. Кстати, это сравнением сделал Matt Adams – Автор STRIDE GPT, о которой мы писали тут.
Всем привет!
По ссылке можно найти результаты сравнения возможностей LLM по моделированию угроз.
В выборку попали: gemma, Phi, DeepSeek, llama и не только.
Сравнение проводилось по группам критериев:
🍭 STRIDE Coverage & Accuracy: насколько модель покрывает все группы угроз в соответствии с методологией STRIDE
🍭Threat Completeness: показывает количество угроз, качество описания
🍭Technical Validity: насколько описание является технически корректным и релевантным
🍭JSON Structure Compliance: проверка корректности заполнения и формата данных в итоговых результатах
Все результаты представлены в виде интерактивных графиков – общие результаты, результаты по приведенным выше группам и т.д.
Больше подробностей про саму методологию можно найти в соответствующем разделе сайта.
P.S. Кстати, это сравнением сделал Matt Adams – Автор STRIDE GPT, о которой мы писали тут.
Tmbench
TM-Bench: Threat Modeling Benchmark
A Benchmark for LLM-Based Threat Modeling
👍4❤2
Bearer: open source SAST
Всем привет!
Bearer – open source SAST от команды Cycode. Как и многие другие SAST-решения он может искать как ИБ-дефекты в исходном коде, так и секреты.
Поддерживается следующий набор языков:
Количество правил варьируется – от 66 для PHP до 88 для Python. Ознакомиться с ними можно вот тут (само правило, описание, рекомендации, полезные ссылки и соотношение с CWE).
Отличительной особенностью Bearer является то, что он может анализировать использование чувствительной информации, например, имена, номера телефонов и т.д. С полным перечнем можно ознакомиться тут.
По завершению работы можно получить несколько отчетов – Security Report, Privacy Report и Data Types Report.
Если вам интересно как работает Bearer внутри, то можно обратиться к этому разделу документации.
Кстати, она достаточно емкая, удобная и информативная – рекомендуем к изучению для лучшего знакомства со сканером ☺️
Всем привет!
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 внутри, то можно обратиться к этому разделу документации.
Кстати, она достаточно емкая, удобная и информативная – рекомендуем к изучению для лучшего знакомства со сканером ☺️
GitHub
GitHub - Bearer/bearer: Code security scanning tool (SAST) to discover, filter and prioritize security and privacy risks.
Code security scanning tool (SAST) to discover, filter and prioritize security and privacy risks. - Bearer/bearer
👍8🤔1
The State of Secrets Sprawl 2025.pdf
2.2 MB
The State of Secrets Sprawl 2025
Всем привет!
В приложении можно найти отчет (~46 страниц) от GitGuardian, посвященный утечкам конфиденциальной информации, а именно – секретов.
Казалось бы, одна из самых базовых рекомендаций – не «храните» секреты в исходном коде и конфигурационных файлах – однако, год от года количество компрометированных секретов растет.
В отчете много статистической информации:
🍭 58% всех секретов – Generic (обычные строки для подключения к чему-либо)
🍭 35% просканированных private repo содержали хотя бы 1 секрет в открытом виде
🍭 Наиболее «популярный» секрет в private repo – ODBC connection string
🍭 Если говорить об образа контейнеров, то самое популярное место для поиска секретов –да, конечно, ENV (65% найденных секретов)
🍭 Большинство секретов остается «активными» после того, как их нашли
🍭 И многое другое
Отчет получился очень интересным, информативным и насыщенным.
Читается легко, «воды» практически нет, зато есть много данных для размышления. Рекомендуем! ☺️
Всем привет!
В приложении можно найти отчет (~46 страниц) от GitGuardian, посвященный утечкам конфиденциальной информации, а именно – секретов.
Казалось бы, одна из самых базовых рекомендаций – не «храните» секреты в исходном коде и конфигурационных файлах – однако, год от года количество компрометированных секретов растет.
В отчете много статистической информации:
🍭 58% всех секретов – Generic (обычные строки для подключения к чему-либо)
🍭 35% просканированных private repo содержали хотя бы 1 секрет в открытом виде
🍭 Наиболее «популярный» секрет в private repo – ODBC connection string
🍭 Если говорить об образа контейнеров, то самое популярное место для поиска секретов –
🍭 Большинство секретов остается «активными» после того, как их нашли
🍭 И многое другое
Отчет получился очень интересным, информативным и насыщенным.
Читается легко, «воды» практически нет, зато есть много данных для размышления. Рекомендуем! ☺️
👍3🤔1
Kubernetes Security Hardening CLI
Всем привет!
Kube-Sec – еще одна утилита, которая позволяет анализировать конфигурации Kubernetes-кластеров для идентификации ИБ-дефектов.
При помощи нее можно найти:
🍭 Privileged Containers
🍭 RBAC Misconfigurations
🍭 Publicly Accessible Services
🍭 Pods Running as Root и не только
Проверки можно настраивать (включать/отключать), результаты предоставляются в качестве JSON/CSV.
В ближайшее время Автор собирается добавить регулярные сканирования (ежедневные/еженедельные)
Если не хочется устанавливать утилиту, но хочется посмотреть на то, как она работает – в репозитории есть демонстрационный ролик.
Важно: проект пока что не является production ready со слов Автора и все еще находится в стадии разработки.
Всем привет!
Kube-Sec – еще одна утилита, которая позволяет анализировать конфигурации Kubernetes-кластеров для идентификации ИБ-дефектов.
При помощи нее можно найти:
🍭 Privileged Containers
🍭 RBAC Misconfigurations
🍭 Publicly Accessible Services
🍭 Pods Running as Root и не только
Проверки можно настраивать (включать/отключать), результаты предоставляются в качестве JSON/CSV.
В ближайшее время Автор собирается добавить регулярные сканирования (ежедневные/еженедельные)
Если не хочется устанавливать утилиту, но хочется посмотреть на то, как она работает – в репозитории есть демонстрационный ролик.
Важно: проект пока что не является production ready со слов Автора и все еще находится в стадии разработки.
GitHub
GitHub - rahulbansod519/Kube-Sec
Contribute to rahulbansod519/Kube-Sec development by creating an account on GitHub.
👍6
Обогащение информацией об уязвимостях
Всем привет!
При работе с уязвимостями многие (по крайней мере по началу) используют метрики, получаемые при использовании методологии 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.
Всем привет!
При работе с уязвимостями многие (по крайней мере по началу) используют метрики, получаемые при использовании методологии 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.
GitHub
GitHub - t0sche/cvss-bt: Enriching the NVD CVSS scores to include Temporal & Threat Metrics
Enriching the NVD CVSS scores to include Temporal & Threat Metrics - t0sche/cvss-bt
👍7
Моделирование угроз: опыт 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. О нем мы писали тут
Всем привет!
По ссылкам доступны статьи, посвященные моделированию угроз (раз, два) и тому, как этот процесс реализован в 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. О нем мы писали тут
The Trail of Bits Blog
Threat modeling the TRAIL of Bits way
Discover TRAIL, Trail of Bits’ systematic threat modeling approach that identifies design-level security weaknesses and provides actionable remediation guidance.
👍6❤1👎1🔥1
DNS resolution в Linux и Kubernetes
Всем привет!
«It’s always DNS!» Да, все так.Нет, не баян, а классика ☺️ Для получения представления или усиления существующего рекомендуем вам ознакомиться со статьей.
Все началось с того, что Автор получил сообщение об ошибке:
Это послужило началом приключения, которое описано в статье. Автор делится своими знаниями о том, как устроен DNS resolution в Linux и Kubernetes.
В статье можно найти информацию о:
🍭 Общая теория DNS в Kubernetes
🍭 DNS в Linux:
🍭 Что изменится при использовании, например, Alpine?
🍭 DNS в 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Все это описывается максимально подробно, с примерами, комментариями и ссылками на документацию по теме.
А в завершении, конечно же, ответ на вопрос – «А почему же Автор получил такое сообщение об ошибке». Рекомендуем к прочтению!
👍14🔥3
Container Security Site
Всем привет!
Rory McCune – личность достаточно известная в мире информационной безопасности контейнеров и сред контейнеризации.
У него, помимо превосходных статей и выступлений, есть сайт, в котором он агрегирует разную информацию по теме как для атакующих, так и для защищающихся.
Внутри можно найти:
🍭 Attackers: Compromised Container Checklist
🍭 Attackers: Compromised User Credentials Checklist
🍭 Container Breakout Vulnerabilities
🍭 Defenders: Container Image Hardening
🍭 Reading List и многое другое
Крайне полезный ресурс, если вам интересна тема защиты контейнеров. Однозначно рекомендуем к изучению!
Всем привет!
Rory McCune – личность достаточно известная в мире информационной безопасности контейнеров и сред контейнеризации.
У него, помимо превосходных статей и выступлений, есть сайт, в котором он агрегирует разную информацию по теме как для атакующих, так и для защищающихся.
Внутри можно найти:
🍭 Attackers: Compromised Container Checklist
🍭 Attackers: Compromised User Credentials Checklist
🍭 Container Breakout Vulnerabilities
🍭 Defenders: Container Image Hardening
🍭 Reading List и многое другое
Крайне полезный ресурс, если вам интересна тема защиты контейнеров. Однозначно рекомендуем к изучению!
[“container-security site”]
Container Security Site
[“A site about container security”]
👍4❤1
API Pentesting Tools
Всем привет!
Давно не было awesome-подборок, решили это поправить ☺️ По ссылке доступны наборы open source инструментов, которые могут пригодиться при ИБ-анализе API.
Материал структурирован по разделам:
🍭 Reconnaisance
🍭 AuthN, AuthZ Testing
🍭 Input Validation Testing
🍭 Security Headers, CORS Testing и не только
Как и везде в аналогичных наборах, для каждого раздела приводится инструмент, ссылка на него и краткое описание его возможностей.
А вы пользуетесь такими подборками или не видите в них смысла?
Всем привет!
Давно не было awesome-подборок, решили это поправить ☺️ По ссылке доступны наборы open source инструментов, которые могут пригодиться при ИБ-анализе API.
Материал структурирован по разделам:
🍭 Reconnaisance
🍭 AuthN, AuthZ Testing
🍭 Input Validation Testing
🍭 Security Headers, CORS Testing и не только
Как и везде в аналогичных наборах, для каждого раздела приводится инструмент, ссылка на него и краткое описание его возможностей.
А вы пользуетесь такими подборками или не видите в них смысла?
GitHub
GitHub - yogsec/API-Pentesting-Tools: API Pentesting Tools are specialized security tools used to test and analyze the security…
API Pentesting Tools are specialized security tools used to test and analyze the security of Application Programming Interfaces (APIs). - GitHub - yogsec/API-Pentesting-Tools: API Pentesting Tools...
👍5❤1
Идентификация вредоносного кода
Всем привет!
Убеждать кого-то о важности защиты от атаки на цепочку поставок вряд ли придется. Множество вредоносных пакетов в пакетных индексах, некорректные конфигурации сборочных сред, образы контейнеров с майнерами и многое другое.
Немного тяжелее становится, когда речь заходит о том как быть и что делать? Тема сама по себе довольна обширная и существуют разные подходы по противодействию.
Чтобы немного упростить задачу рекомендуем ознакомиться со статьей от Apiiro, в которой они рассказывают про то, как идентифицируют вредоносный код.
Не только словом! Команда предоставила в общий доступ несколько своих наработок.
Это:
🍭 Набор правил для Semgrep (Opengrep) для идентификации вредоносного кода
🍭 PRevent – анализ PR GitHub на наличие чего-то подозрительного
Инструменты можно использовать для анализа различных языков: Java, PHP, Ruby, Golang и т.д. А о том, чем именно руководствовались Авторы при разработке правил и утилит, можно узнать в статье.
В завершении (Appendix A) приведена статистика о True/False Positive при использовании наработок Apiiro применительно к Malicious Software Packages Dataset, подготовленного DataDog
Всем привет!
Убеждать кого-то о важности защиты от атаки на цепочку поставок вряд ли придется. Множество вредоносных пакетов в пакетных индексах, некорректные конфигурации сборочных сред, образы контейнеров с майнерами и многое другое.
Немного тяжелее становится, когда речь заходит о том как быть и что делать? Тема сама по себе довольна обширная и существуют разные подходы по противодействию.
Чтобы немного упростить задачу рекомендуем ознакомиться со статьей от Apiiro, в которой они рассказывают про то, как идентифицируют вредоносный код.
Не только словом! Команда предоставила в общий доступ несколько своих наработок.
Это:
🍭 Набор правил для Semgrep (Opengrep) для идентификации вредоносного кода
🍭 PRevent – анализ PR GitHub на наличие чего-то подозрительного
Инструменты можно использовать для анализа различных языков: Java, PHP, Ruby, Golang и т.д. А о том, чем именно руководствовались Авторы при разработке правил и утилит, можно узнать в статье.
В завершении (Appendix A) приведена статистика о True/False Positive при использовании наработок Apiiro применительно к Malicious Software Packages Dataset, подготовленного DataDog
Apiiro | Deep Application Security Posture Management (ASPM)
Guard your Codebase: Practical Steps and Tools to Prevent Malicious Code
Protect your codebase from malicious threats. Discover tools and best practices to detect and prevent attacks—read more now!
👍4❤2❤🔥1👏1
Ingress Nightmare: hands-on lab
Всем привет!
Новость об Ingress Nightmare очень быстро распространилась по сети и, вероятно, станет одной из «наиболее часто обсуждаемых уязвимостей» в 2025. По крайней мере для мира безопасности сред контейнеризации.
Если вам не хватило множества описаний и хочется посмотреть, как оно работает «на деле», то в этом repo собрана необходима информация.
Внутри можно найти алгоритм действий и необходимые скрипты для того, чтобы проэксплуатировать CVE-2025-1974.
Кстати, помимо этого, в repo есть и другие лабораторные работы по безопасности Kubernetes. Подробнее про него мы писали тут.
Всем привет!
Новость об Ingress Nightmare очень быстро распространилась по сети и, вероятно, станет одной из «наиболее часто обсуждаемых уязвимостей» в 2025. По крайней мере для мира безопасности сред контейнеризации.
Если вам не хватило множества описаний и хочется посмотреть, как оно работает «на деле», то в этом repo собрана необходима информация.
Внутри можно найти алгоритм действий и необходимые скрипты для того, чтобы проэксплуатировать CVE-2025-1974.
Кстати, помимо этого, в repo есть и другие лабораторные работы по безопасности Kubernetes. Подробнее про него мы писали тут.
GitHub
dvka/workshop/labs/ingress-nightmare at master · Alevsk/dvka
Damn Vulnerable Kubernetes App (DVKA) is a series of apps deployed on Kubernetes that are damn vulnerable. - Alevsk/dvka
👍2
Проверка подписей образов контейнеров в 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
Всем привет!
Периодически возникает задача по проверке электронных подписей образов контейнеров в 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
👍7🔥6🥰3