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
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
🍭 Если говорить об образа контейнеров, то самое популярное место для поиска секретов –
🍭 Большинство секретов остается «активными» после того, как их нашли
🍭 И многое другое
Отчет получился очень интересным, информативным и насыщенным.
Читается легко, «воды» практически нет, зато есть много данных для размышления. Рекомендуем! ☺️
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.
Обогащение информацией об уязвимостях
Всем привет!
При работе с уязвимостями многие (по крайней мере по началу) используют метрики, получаемые при использовании методологии 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
Моделирование угроз: опыт 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
In this blog, we’ll talk about our threat modeling process, TRAIL, which stands for Threat and Risk Analysis Informed Lifecycle. TRAIL enables us to trace and document the impact of flawed trust assumptions and insecure design decisions throughout each client’s…
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Все это описывается максимально подробно, с примерами, комментариями и ссылками на документацию по теме.
А в завершении, конечно же, ответ на вопрос – «А почему же Автор получил такое сообщение об ошибке». Рекомендуем к прочтению!
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”]
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...
Идентификация вредоносного кода
Всем привет!
Убеждать кого-то о важности защиты от атаки на цепочку поставок вряд ли придется. Множество вредоносных пакетов в пакетных индексах, некорректные конфигурации сборочных сред, образы контейнеров с майнерами и многое другое.
Немного тяжелее становится, когда речь заходит о том как быть и что делать? Тема сама по себе довольна обширная и существуют разные подходы по противодействию.
Чтобы немного упростить задачу рекомендуем ознакомиться со статьей от 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!
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
Проверка подписей образов контейнеров в 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
Мы на DevOps Conf 7-8 апреля: все активности в одном посте 👍
Уже в понедельник стартует юбилейная конференция DevOps Conf, и мы, конечно, там будем. А вы?)
📍 Где нас можно найти: стенд №6, рядом с конгресс-холом.
🎤 Где нас можно послушать: 7 апреля в 10:00 в зале «Пекин» будет выступать Саша Краснов, СТО платформы «Штурвал». Тема доклада: «Как я перестал страдать и полюбил CoreDNS».
🎁 Как можно побороться за крутой мерч: все просто — поучаствовать в наших активностях. А их очень много: и шоковая викторина, и бой «ванильного» кубера против «Штурвала», и игра по миру Kubernetes. Призы достойные, мы ими очень гордимся.
Приходите!
Уже в понедельник стартует юбилейная конференция DevOps Conf, и мы, конечно, там будем. А вы?)
Приходите!
Please open Telegram to view this post
VIEW IN TELEGRAM
Автоматизация процесса управления сетевыми политиками
Всем привет!
Контролировать потоки сетевого трафика – дело хорошее. В Kubernetes для этого есть сетевые политики (опустим, что они могут различаться у разных CNI).
Создать простые политики для тестов достаточно легко. Но как поддерживать их в актуальном состоянии? Как сделать так, чтобы ваши политики не сломали все «соседу» (в случае использование некоего общего ресурса). И, конечно же, как это делать автоматизировано?
Если вам интересны ответы на эти вопросы, то очень и очень рекомендуем прочесть вот эту статью. В ней Автор рассказывает о автоматизации процесса управления сетевыми политиками с использованием Otterize, Kyverno и ArgoCD.
Статья содержит в себе:
🍭 Погружение в проблематику
🍭 Нюансы, с которыми придется столкнуться при решении задачи «в лоб»
🍭 Как Otterize может упростить и оптимизировать процесс конфигурации политик (про утилиту мы писали тут и тут)
🍭 Варианты автоматизации процесса управления сетевыми политиками и при чем тут Kyverno
В завершении статьи Автор собирает все «кусочки» вместе и демонстрирует итоговое решение, к которому они пришли.
Схемы, конфигурации, комментарии, размышления, варианты решения разных задач – все на месте!
Всем привет!
Контролировать потоки сетевого трафика – дело хорошее. В Kubernetes для этого есть сетевые политики (опустим, что они могут различаться у разных CNI).
Создать простые политики для тестов достаточно легко. Но как поддерживать их в актуальном состоянии? Как сделать так, чтобы ваши политики не сломали все «соседу» (в случае использование некоего общего ресурса). И, конечно же, как это делать автоматизировано?
Если вам интересны ответы на эти вопросы, то очень и очень рекомендуем прочесть вот эту статью. В ней Автор рассказывает о автоматизации процесса управления сетевыми политиками с использованием Otterize, Kyverno и ArgoCD.
Статья содержит в себе:
🍭 Погружение в проблематику
🍭 Нюансы, с которыми придется столкнуться при решении задачи «в лоб»
🍭 Как Otterize может упростить и оптимизировать процесс конфигурации политик (про утилиту мы писали тут и тут)
🍭 Варианты автоматизации процесса управления сетевыми политиками и при чем тут Kyverno
В завершении статьи Автор собирает все «кусочки» вместе и демонстрирует итоговое решение, к которому они пришли.
Схемы, конфигурации, комментарии, размышления, варианты решения разных задач – все на месте!
Medium
GitOps: How to Manage Dynamic Network Policy Changes at Scale Across 25 Clusters?
The Challenge of using netpols without blocking developers or being blocked by them
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 или сама база в «отчуждаемом» формате, чтобы можно было ее забрать «к себе». Если знаете, как и что – пишите в комментариях ☺️
Всем привет!
По ссылке доступен еще один источник получения информации по уязвимостям – 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 или сама база в «отчуждаемом» формате, чтобы можно было ее забрать «к себе». Если знаете, как и что – пишите в комментариях ☺️
wiz.io
The CVE Database: Curated Vulnerability Intelligence by Wiz | Wiz
Wiz's CVE Database curates CVE data to create easy-to-navigate profiles that cover the entire vulnerability timeline, exploit scenarios, and mitigation steps.
P-SSCRM_v1.pdf
663.3 KB
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 и иными стандартами можно найти в документе.
Всем привет!
В приложении можно скачать P-SSCRM (~ 17 страниц) – framework, посвященный обеспечению безопасности при работе с цепочкой поставок ПО.
P-SCCRM был разработан с учетом данных, собранных на основании результатов анализа атак на цепочки поставки, реализованных в 2022, 2023 годах.
Framework разделен на домены:
🍭 Governance. Организация процесса защиты и оценка его эффективности
🍭 Product. Выпуск продукта с минимальным количеством ИБ-дефектов
🍭 Environment. Защита исходного кода, компонентов, инфраструктуры сборки и т.д.
🍭 Deployment. Идентификация и анализ ИБ-дефектов в продукте
Для каждого домена определены задачи (tasks) в общем количестве 73 штуки. Описание задач, а также соотношение практик P-SSCRM с BSIMM, NIST, SALSA и иными стандартами можно найти в документе.
EPSS.pdf
669.4 KB
Так ли хороша 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
Всем привет!
Любая информация, которая может быть использована для понимания «актуальности» уязвимости крайне важна. Она помогает понять на что стоит обращать внимание при разборе тысяч срабатываний, которые генерируются сканерами.
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
Rogue: Web Vulnerability Scanner
Всем привет!
По ссылке можно найти Rogue – open source проект, представляющий из себя web-сканер, «под капотом» которого используется LLM.
Он умеет:
🍭 Анализировать web-трафик за счет встроенного proxy
🍭 Понимать контекст приложения и «адаптироваться» в зависимости от получаемых результатов
🍭 Генерировать payloads, «подходящие» для конкретного приложения
🍭 Подтверждать наличие уязвимостей, что снижает количество false positive
🍭 Генерировать отчетность и не только
В качестве LLM используется OpenAI и Anthropic Claude, поэтому для того, чтобы опробовать Rogue «в деле», потребуется указать соответствующие API-ключи.
Больше про утилиту можно узнать в repo проекта.
Важно(!): со слов Автора, это больше PoC, который он планирует дорабатывать, а не законченное решение.
Всем привет!
По ссылке можно найти Rogue – open source проект, представляющий из себя web-сканер, «под капотом» которого используется LLM.
Он умеет:
🍭 Анализировать web-трафик за счет встроенного proxy
🍭 Понимать контекст приложения и «адаптироваться» в зависимости от получаемых результатов
🍭 Генерировать payloads, «подходящие» для конкретного приложения
🍭 Подтверждать наличие уязвимостей, что снижает количество false positive
🍭 Генерировать отчетность и не только
В качестве LLM используется OpenAI и Anthropic Claude, поэтому для того, чтобы опробовать Rogue «в деле», потребуется указать соответствующие API-ключи.
Больше про утилиту можно узнать в repo проекта.
Важно(!): со слов Автора, это больше PoC, который он планирует дорабатывать, а не законченное решение.
GitHub
GitHub - faizann24/rogue: Automated web vulnerability scanning with LLM agents
Automated web vulnerability scanning with LLM agents - faizann24/rogue
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, которые есть практически в каждом разделе репозитория.
Всем привет!
В 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, которые есть практически в каждом разделе репозитория.
GitHub
GitHub - m14r41/PentestingEverything: Penetration Testing For - Web | Mobile | API | Thick Client | Source Code Review | DevSecOps…
Penetration Testing For - Web | Mobile | API | Thick Client | Source Code Review | DevSecOps | Wireless | Network Pentesting, etc... - m14r41/PentestingEverything
Основы работы с REGO
Всем привет!
REGO может показаться не самым простым языком, особенно если до этого вы работали с «более привычными» Python, Golang, Java и т.д.
Чтобы упростить начало работы с ним и немного снизить порог входа, команда SNYK подготовила обширный материал – Getting started with Practical Rego.
Статья (~ 28 минут чтения) включает в себя сведения о:
🍭 Общую информацию про REGO и его декларативность
🍭 Сравнения, работа с правилами и функциями
🍭 Управление потоком выполнения, работы с циклами
🍭 Поиск ошибок, отладка и т.д.
Что особенно хорошо – так это обилие примеров и пояснений к ним, а также отсылки на дополнительные материалы, которые помогут лучше разобраться.
Если вы давно смотрели на REGO, но не знали с чего начать, то эта статья может быть вам полезна.
Всем привет!
REGO может показаться не самым простым языком, особенно если до этого вы работали с «более привычными» Python, Golang, Java и т.д.
Чтобы упростить начало работы с ним и немного снизить порог входа, команда SNYK подготовила обширный материал – Getting started with Practical Rego.
Статья (~ 28 минут чтения) включает в себя сведения о:
🍭 Общую информацию про REGO и его декларативность
🍭 Сравнения, работа с правилами и функциями
🍭 Управление потоком выполнения, работы с циклами
🍭 Поиск ошибок, отладка и т.д.
Что особенно хорошо – так это обилие примеров и пояснений к ним, а также отсылки на дополнительные материалы, которые помогут лучше разобраться.
Если вы давно смотрели на REGO, но не знали с чего начать, то эта статья может быть вам полезна.
Snyk
Getting started with Practical Rego | Snyk
Read this guide introducing Rego, a declarative policy language, for programmers familiar with imperative languages like Python or Java. It covers key concepts, common pitfalls, and best practices for writing effective Rego policies.
Slopsquatting: еще одна supply chain уязвимость
Всем привет!
Typosquatting давно известная и понятная уязвимость, обусловленная самым слабым звеном в любой системе безопасности – человеком.
Да, можно опечататься, не знать, не посмотреть на то, что пишешь – не важно – и вот уже качается не тот пакет, что должен был.
Этим пользуются и злоумышленники, регистрируя пакеты, которые именно что «похожи» в названиях на оригинальные.
Мир меняется, все больше и больше людей используют искусственный интеллект, в том числе и для разработки ПО.
Однако и AI может ошибаться. Например, предлагать к использованию пакеты, которые не существуют. Этим тоже могут воспользоваться злоумышленники – например, собрать статистику о том, какие пакеты из несуществующих чаще рекомендуют LLM и зарегистрировать их. Но уже «с другим содержанием».
Согласно статье около 20% из 205 000 рекомендуемых LLM пакетов были несуществующими. Процент галлюцинаций меняется от модели к модели: DeepSeek и WizardCoder – 21,7%, GPT 4 – 5,2%.
Статья достаточно поверхностная, но в ней есть ссылка на полноценное исследование вопроса, с данными, аналитикой, выводами и всем необходимым.
Из рекомендаций можно выделить нестареющую классику: не тащить все подряд из интернета, проверять из чего состоит разрабатываемое ПО, использовать локальные реестры, оформлять SBoM и делать все это не разово, а на периодической основе.
Всем привет!
Typosquatting давно известная и понятная уязвимость, обусловленная самым слабым звеном в любой системе безопасности – человеком.
Да, можно опечататься, не знать, не посмотреть на то, что пишешь – не важно – и вот уже качается не тот пакет, что должен был.
Этим пользуются и злоумышленники, регистрируя пакеты, которые именно что «похожи» в названиях на оригинальные.
Мир меняется, все больше и больше людей используют искусственный интеллект, в том числе и для разработки ПО.
Однако и AI может ошибаться. Например, предлагать к использованию пакеты, которые не существуют. Этим тоже могут воспользоваться злоумышленники – например, собрать статистику о том, какие пакеты из несуществующих чаще рекомендуют LLM и зарегистрировать их. Но уже «с другим содержанием».
Согласно статье около 20% из 205 000 рекомендуемых LLM пакетов были несуществующими. Процент галлюцинаций меняется от модели к модели: DeepSeek и WizardCoder – 21,7%, GPT 4 – 5,2%.
Статья достаточно поверхностная, но в ней есть ссылка на полноценное исследование вопроса, с данными, аналитикой, выводами и всем необходимым.
Из рекомендаций можно выделить нестареющую классику: не тащить все подряд из интернета, проверять из чего состоит разрабатываемое ПО, использовать локальные реестры, оформлять SBoM и делать все это не разово, а на периодической основе.
CSO Online
AI hallucinations lead to a new cyber threat: Slopsquatting
Attackers can weaponize and distribute a large number of packages recommended by AI models that don’t really exist.