Автоматизация процесса управления сетевыми политиками
Всем привет!
Контролировать потоки сетевого трафика – дело хорошее. В 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.
Snyk: Greybeard!
Всем привет!
🚨 Исключительно пятничный пост 🚨
Ребята из Snyk решили, что стандартные описания уязвимостей достаточно скучные и хочется их как-то персонализировать и сделать более «понятными».
Для этого они выпустили новую CLI утилиту – Greybeard!
Работает все просто:
🍭 Качаем Greybeard
🍭 Указываем OpenAI API Key
🍭 Используем Greybeard для анализа «чего-либо» (например, образов контейнеров)
В качестве результата получаем не обычное описание в стиле «Пакет XYZ содержит уязвимость в каком-то методе», а нечто вроде «Listen up, youngster! I see you've got a critical RCE vulnerability in that package. Back in my day, we'd have been fired for leaving something this obvious in production. You better fix this ASAP unless you want your servers to become someone else's bitcoin miner...»
Подробности, как обычно, в repo проекта. А мы желаем вам отличной пятницы и прекрасной Пасхи! ☺️
Всем привет!
Ребята из Snyk решили, что стандартные описания уязвимостей достаточно скучные и хочется их как-то персонализировать и сделать более «понятными».
Для этого они выпустили новую CLI утилиту – Greybeard!
Работает все просто:
🍭 Качаем Greybeard
🍭 Указываем OpenAI API Key
🍭 Используем Greybeard для анализа «чего-либо» (например, образов контейнеров)
В качестве результата получаем не обычное описание в стиле «Пакет XYZ содержит уязвимость в каком-то методе», а нечто вроде «Listen up, youngster! I see you've got a critical RCE vulnerability in that package. Back in my day, we'd have been fired for leaving something this obvious in production. You better fix this ASAP unless you want your servers to become someone else's bitcoin miner...»
Подробности, как обычно, в repo проекта. А мы желаем вам отличной пятницы и прекрасной Пасхи! ☺️
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - snyk-labs/snyk-cli-greybeard: A wrapper for Snyk CLI that transforms security scan results into grumpy, sarcastic commentary…
A wrapper for Snyk CLI that transforms security scan results into grumpy, sarcastic commentary from an experienced security "greybeard" using OpenAI. - snyk-labs/snyk-cli-greybeard
CyberCamp 2025: call for papers!
Всем привет!
CyberCamp возвращается! Мероприятие, посвященное развитию как теоретических, так и практических навыков по информационной безопасности ищет спикеров!
В этом году CyberCamp будет длиться целую неделю(ну почти) : с 20 по 25 октября 2025 года, дни докладов – 21,22 и 23 октября.
Темы по безопасной разработке и DevSecOps в наличии:
🐾 Безопасность приложений (исходный код, компоненты и т.д.)
🐾 Защита цепочки поставки ПО
🐾 Управление секретами
🐾 Защита API
🐾 Управление приоритетами при устранении ИБ-дефектов в безопасной разработке
🐾 Защита окружения разработки (VCS, CI/CD, Registry и т.д.)
🐾 Защита контейнеров: от Docker до Kubernetes
Если у вас есть что рассказать, то все просто: заполняете форму на сайте, после чего с вами свяжутся представители программного комитета и уточнят данные.
Что делать, если «вашей темы» нет в списке? Все равно заполнять форму и подаваться с докладом!
Важную информацию о датах можно найти на сайте мероприятия. Ждем ваших заявок и до встречи на CyberCamp 2025!
P.S. CFP открыт до 15-ого июня 2025 года🟢
Всем привет!
CyberCamp возвращается! Мероприятие, посвященное развитию как теоретических, так и практических навыков по информационной безопасности ищет спикеров!
В этом году CyberCamp будет длиться целую неделю
Темы по безопасной разработке и DevSecOps в наличии:
Если у вас есть что рассказать, то все просто: заполняете форму на сайте, после чего с вами свяжутся представители программного комитета и уточнят данные.
Что делать, если «вашей темы» нет в списке? Все равно заполнять форму и подаваться с докладом!
Важную информацию о датах можно найти на сайте мероприятия. Ждем ваших заявок и до встречи на CyberCamp 2025!
P.S. CFP открыт до 15-ого июня 2025 года
Please open Telegram to view this post
VIEW IN TELEGRAM
CPU Limits и throttling в Kubernetes
Всем привет!
Еще один отличный материал, посвященный управлению ресурсами в Kubernetes. А именно – когда (не) надо использовать CPU Limits при работе с контейнерами.
Сперва Автор описывает общий концепт: что такое CPU Requests и CPU Limits, для чего они используются и как все это связано с cgroups v2.
Если упростить, то CPU Limits определяют максимальное время использования процессора в
рамках «окна», равного 100 ms.
Грубо говоря, если установлен CPU Limit, равный 0.4, то на реализацию задачи, которой требуется 200 ms процессорного времени уйдет… 440 ms.
Причина проста – в первые 100 ms было использовано лишь 40 ms времени процессора, остальные 60 ms – простой и ожидание нового «окна».
Для некоторых приложений это не столь значимо, для некоторых – достаточно критично. Например, могут не сработать liveness probes, могут быть пропущены heartbeat-события и многое другое.
В завершении статьи Автор дает рекомендации о том, когда (не) нужно использовать CPU Limits и о том, как можно идентифицировать throttling.
Кстати, статья – это лишь некоторое summary доклада, презентация которого доступна по ссылке в статье (~ 100 слайдов, посвященных тематики).
Много графиков, пояснений и формул, что позволят лучше разобраться в вопросе и решить для себя – а стоит ли использовать CPU Limits.
Всем привет!
Еще один отличный материал, посвященный управлению ресурсами в Kubernetes. А именно – когда (не) надо использовать CPU Limits при работе с контейнерами.
Сперва Автор описывает общий концепт: что такое CPU Requests и CPU Limits, для чего они используются и как все это связано с cgroups v2.
Если упростить, то CPU Limits определяют максимальное время использования процессора в
рамках «окна», равного 100 ms.
Грубо говоря, если установлен CPU Limit, равный 0.4, то на реализацию задачи, которой требуется 200 ms процессорного времени уйдет… 440 ms.
Причина проста – в первые 100 ms было использовано лишь 40 ms времени процессора, остальные 60 ms – простой и ожидание нового «окна».
Для некоторых приложений это не столь значимо, для некоторых – достаточно критично. Например, могут не сработать liveness probes, могут быть пропущены heartbeat-события и многое другое.
В завершении статьи Автор дает рекомендации о том, когда (не) нужно использовать CPU Limits и о том, как можно идентифицировать throttling.
Кстати, статья – это лишь некоторое summary доклада, презентация которого доступна по ссылке в статье (~ 100 слайдов, посвященных тематики).
Много графиков, пояснений и формул, что позволят лучше разобраться в вопросе и решить для себя – а стоит ли использовать CPU Limits.
Reddit
From the kubernetes community on Reddit: CPU Limits in Kubernetes: Why Your Pod is Idle but Still Throttled: A Deep Dive into What…
Explore this post and more from the kubernetes community
SecDim: теория и практика по безопасной разработке!
Всем привет!
Еще один сайт, на котором можно найти (местами бесплатную) теорию и практику по разработке безопасного ПО.
На сайте можно найти:
🍭 Теорию по принципам Secure Design
🍭 Основы безопасной разработки
🍭 Разборы реальных случаев (например, Stack Overflow Outage в 2016)
🍭 Безопасная работа с GitHub Actions
🍭 Безопасное программирование на Java, Golang, Python, JS и т.д.
Понравилась, как реализована практика: есть небольшое видео, в котором объясняется концепт уязвимости. Далее нужно поправить существующий код и пройти тесты. И тут есть нюанс – важно не только исправить дефект, но и сохранить работоспособность приложения.
Сами тесты «лежат рядом» и можно посмотреть, что и как проверяется на случай, если застряли и «непонятно, что от вас хотят»
Все это можно «скачать и разбирать» локально или воспользоваться возможностями, предоставляемыми SecDim.
Всем привет!
Еще один сайт, на котором можно найти (местами бесплатную) теорию и практику по разработке безопасного ПО.
На сайте можно найти:
🍭 Теорию по принципам Secure Design
🍭 Основы безопасной разработки
🍭 Разборы реальных случаев (например, Stack Overflow Outage в 2016)
🍭 Безопасная работа с GitHub Actions
🍭 Безопасное программирование на Java, Golang, Python, JS и т.д.
Понравилась, как реализована практика: есть небольшое видео, в котором объясняется концепт уязвимости. Далее нужно поправить существующий код и пройти тесты. И тут есть нюанс – важно не только исправить дефект, но и сохранить работоспособность приложения.
Сами тесты «лежат рядом» и можно посмотреть, что и как проверяется на случай, если застряли и «непонятно, что от вас хотят»
Все это можно «скачать и разбирать» локально или воспользоваться возможностями, предоставляемыми SecDim.
Secdim
SecDim - Learn
Learn Secure Software Engineering - SecDim
Trail of Bits: Fuzzing!
Всем привет!
Trail of Bits продолжает развивать свой Testing Handbook. Теперь в нем можно найти информацию по одной из самых «пугающих» и сложных тем в Application Security, а именно – Fuzzing.
Команда собрала подборку для:
🍭 C/C++ (libFuzzer, AFL++, LibAFL)
🍭Rust (cargo-fuzz)
🍭Python (Atheris)
🍭Ruby (Ruzzy)
🍭OSS-Fuzz
Для каждого предлагаемого инструмента приводится небольшая инструкция по использованию: от установки до запуска и настройки.
Да, это «лишь капля в море», но может стать хорошей отправной точкой для начала. Кстати, в разделе «Additional resources» есть ссылки на дополнительные материалы по теме для углубленного изучения.
Помимо этого в Testing Handbook можно найти информацию о статическом анализе на примере Semgrep и материалы по тестированию Web-приложений. Об этом мы писали тут и тут.
Всем привет!
Trail of Bits продолжает развивать свой Testing Handbook. Теперь в нем можно найти информацию по одной из самых «пугающих» и сложных тем в Application Security, а именно – Fuzzing.
Команда собрала подборку для:
🍭 C/C++ (libFuzzer, AFL++, LibAFL)
🍭Rust (cargo-fuzz)
🍭Python (Atheris)
🍭Ruby (Ruzzy)
🍭OSS-Fuzz
Для каждого предлагаемого инструмента приводится небольшая инструкция по использованию: от установки до запуска и настройки.
Да, это «лишь капля в море», но может стать хорошей отправной точкой для начала. Кстати, в разделе «Additional resources» есть ссылки на дополнительные материалы по теме для углубленного изучения.
Помимо этого в Testing Handbook можно найти информацию о статическом анализе на примере Semgrep и материалы по тестированию Web-приложений. Об этом мы писали тут и тут.
Testing Handbook
Fuzzing
Fuzzing represents a dynamic testing method that inputs malformed or unpredictable data to a system to detect security issues, bugs, or system failures.
Устройство файловой системы контейнеров
Всем привет!
«Как каждый контейнер получает свою собственную файловую систему?» - с этого вопроса началось небольшое исследование, описанное в статье.
Сперва Автор создает простой контейнер на базе Alpine и помещает внутрь него файл
Да, этот самый файл можно найти и в операционной системе хоста по пути
Эти данные необходимы для управления overlayfs, которую использует Docker. Грубо говоря, есть несколько «директорий» (не совсем так, но для концепта подойдет):
🍭 Lower, доступную только для чтения. Именно там хранится то, что было в изначальном образе
🍭 Upper (она же Diff), в которую можно записывать. Тот самый «дополнительный слой образа», который создается при старте контейнера
🍭 Merged. Соединение Upper и Lower
После пояснения основных концептов на крайне наглядных примерах (схемы с комментариями) Автор создает файловую систему контейнера, имитируя деятельность Docker.
В итоге имеем отличную статью, которая позволяет лучше разобраться в том, как именно устроены и работают контейнеры. Рекомендуем!
Всем привет!
«Как каждый контейнер получает свою собственную файловую систему?» - с этого вопроса началось небольшое исследование, описанное в статье.
Сперва Автор создает простой контейнер на базе Alpine и помещает внутрь него файл
hello_there.txt.Да, этот самый файл можно найти и в операционной системе хоста по пути
/var/lib/docker… А еще там есть разные папки - diff, merged и именно этому посвящена остальная часть статьи.Эти данные необходимы для управления overlayfs, которую использует Docker. Грубо говоря, есть несколько «директорий» (не совсем так, но для концепта подойдет):
🍭 Lower, доступную только для чтения. Именно там хранится то, что было в изначальном образе
🍭 Upper (она же Diff), в которую можно записывать. Тот самый «дополнительный слой образа», который создается при старте контейнера
🍭 Merged. Соединение Upper и Lower
После пояснения основных концептов на крайне наглядных примерах (схемы с комментариями) Автор создает файловую систему контейнера, имитируя деятельность Docker.
В итоге имеем отличную статью, которая позволяет лучше разобраться в том, как именно устроены и работают контейнеры. Рекомендуем!
Substack
Primer on Linux container filesystems
Building a container filessytem by hand
Поиск секретов с PSCommitSecretScanner
Всем привет!
PSCommitSecretScanner – PowerShell-модуль, который позволяет искать секреты в git-репозиториях.
Доступен следующий функционал:
🍭 Сканирование public или internal GitHub repo
🍭 Анализ последних commits
🍭 Фильтрация результатов (например, покажи данные за X последних дней)
«Под капотом» - набор регулярных выражений для поиска секретов разного вида: AWS Keys, GitHub Tokens, Slack Webhooks, JWT и т.д. С полным списком ознакомиться можно тут.
Кстати, многое в работе PSCommitSecretScanner было позаимствовано у другого проекта – PSSecretScanner, который также использует возможности PowerShell для поиска секретов.
Всем привет!
PSCommitSecretScanner – PowerShell-модуль, который позволяет искать секреты в git-репозиториях.
Доступен следующий функционал:
🍭 Сканирование public или internal GitHub repo
🍭 Анализ последних commits
🍭 Фильтрация результатов (например, покажи данные за X последних дней)
«Под капотом» - набор регулярных выражений для поиска секретов разного вида: AWS Keys, GitHub Tokens, Slack Webhooks, JWT и т.д. С полным списком ознакомиться можно тут.
Кстати, многое в работе PSCommitSecretScanner было позаимствовано у другого проекта – PSSecretScanner, который также использует возможности PowerShell для поиска секретов.
GitHub
GitHub - HCRitter/PSCommitSecretScanner: This Module Helps to Scan a Commit History of a Repo for Leakage of Secrets
This Module Helps to Scan a Commit History of a Repo for Leakage of Secrets - HCRitter/PSCommitSecretScanner
Обновление JCSF!
Всем привет!
Мы обновили наш фреймворк по аудиту и защите контейнерной инфраструктуры JCSF! Благодаря ему можно как провести аудит собственной контейнерной инфраструктуры, так и запланировать дальнейшие действия в области защиты сред контейнеризации.
В новом релизе:
🍭 Добавили домен по аудиту standalone Docker
🍭 Доработали раздел по защите манифестов
🍭 Исправили определения и добавили детализацию по проверкам
Детальная информация по новому релизу и сам фреймворк доступны по ссылке.
Напомним, что мы будем очень рады, если вы присоединитесь к совершенствованию JCSF и станете его контрибьютором.
Всем привет!
Мы обновили наш фреймворк по аудиту и защите контейнерной инфраструктуры JCSF! Благодаря ему можно как провести аудит собственной контейнерной инфраструктуры, так и запланировать дальнейшие действия в области защиты сред контейнеризации.
В новом релизе:
🍭 Добавили домен по аудиту standalone Docker
🍭 Доработали раздел по защите манифестов
🍭 Исправили определения и добавили детализацию по проверкам
Детальная информация по новому релизу и сам фреймворк доступны по ссылке.
Напомним, что мы будем очень рады, если вы присоединитесь к совершенствованию JCSF и станете его контрибьютором.
GitHub
GitHub - Jet-Security-Team/Jet-Container-Security-Framework: Jet Container Security Framework (JCSF)
Jet Container Security Framework (JCSF). Contribute to Jet-Security-Team/Jet-Container-Security-Framework development by creating an account on GitHub.
Виртуальные машины внутри контейнеров
Всем привет!
K8s умеет много всего, в том числе запускать и управлять виртуальными машинами. Реализуется это с помощью KubeVirt.
Статья Learn KubeVirt: Deep Dive for VMware vSphere Admins подробно раскрывает основные моменты, связанные с этой технологией.
В частности, на примере терминов из VMware vSphere вы поймете как KubeVirt работает с
🍭хранилищами данных
🍭сетью передачи данных
🍭 и как выполнить базовые операции по мониторингу, поиску неисправностей и т.д.
В конце автор подводит итог о плюсах\минусах технологии и применимости ее в реальной жизни.
PS. От себя добавим: возможности по управлению виртуальными машинами сильно зависят от дистрибутива K8s. Например в OpenShift это будут одни возможности, в каком-то другом дистрибутиве иные. Обращайте на это внимание!
Всем привет!
K8s умеет много всего, в том числе запускать и управлять виртуальными машинами. Реализуется это с помощью KubeVirt.
Статья Learn KubeVirt: Deep Dive for VMware vSphere Admins подробно раскрывает основные моменты, связанные с этой технологией.
В частности, на примере терминов из VMware vSphere вы поймете как KubeVirt работает с
🍭хранилищами данных
🍭сетью передачи данных
🍭 и как выполнить базовые операции по мониторингу, поиску неисправностей и т.д.
В конце автор подводит итог о плюсах\минусах технологии и применимости ее в реальной жизни.
PS. От себя добавим: возможности по управлению виртуальными машинами сильно зависят от дистрибутива K8s. Например в OpenShift это будут одни возможности, в каком-то другом дистрибутиве иные. Обращайте на это внимание!
vEducate.co.uk
Learn KubeVirt: Deep Dive for VMware vSphere Admins
A deep dive into KubeVirt for vSphere admins. Learn VM creation, storage, networking, and operations mapped to familiar VMware concepts.
Как Kubernetes управляет контейнерами?
Всем привет!
Еще одна статья из серии «как оно работает под капотом?». На этот раз Автор разбирается в том, как именно Kubernetes управляет контейнерами.
Начинается все с просто аналогии:
🍭 Есть некая сущность, которая определяет то, что она хочет создать (спецификация)
🍭Есть еще одна сущность, которая может принимать спецификацию и транслировать ее в нечто более «низкоуровневое»
🍭Последняя сущность принимает все, что получилось выше и запускает контейнеры, используя возможности Linux
Да, это очень и очень упрощенная модель, но она позволяет понять основные концепции.
Далее, после небольшой справки по процессам в Linux (запуск, изоляция), начинается самое интересное!
Процессы, управление ресурсами через `cgroups`, и многое другое! Автор разбирает это все на примерах создания
Крайне наглядно и полезно, рекомендуем!
Всем привет!
Еще одна статья из серии «как оно работает под капотом?». На этот раз Автор разбирается в том, как именно Kubernetes управляет контейнерами.
Начинается все с просто аналогии:
🍭 Есть некая сущность, которая определяет то, что она хочет создать (спецификация)
🍭Есть еще одна сущность, которая может принимать спецификацию и транслировать ее в нечто более «низкоуровневое»
🍭Последняя сущность принимает все, что получилось выше и запускает контейнеры, используя возможности Linux
Да, это очень и очень упрощенная модель, но она позволяет понять основные концепции.
Далее, после небольшой справки по процессам в Linux (запуск, изоляция), начинается самое интересное!
Процессы, управление ресурсами через `cgroups`, и многое другое! Автор разбирает это все на примерах создания
pod в кластере Kubernetes, а также рассматривает происходящее «с точки зрения узла», на котором все это создается.Крайне наглядно и полезно, рекомендуем!
Esc.sh
How Kubernetes Runs Containers : A Practical Deep Dive
Taking a deep dive into how Kubernetes runs containers as Linux processes
LLSoftSecBook.pdf
881.9 KB
Low-Level Software Security for Compiler Developers
Всем привет!
Впереди майские праздники и есть немного свободного времени, например, для того, чтобы что-то почитать.
Если вы искали материал по теме безопасной разработки, то предлагаем вам ознакомиться с электронной книгой в приложении – Low-Level Software Security for Compiler Developers.
В ней содержится много интересной и полезной информации (~ 71 страница) о том, с какими нюансами можно столкнуться при работе с компиляторами.
Внутри можно найти:
🍭 Memory vulnerability based attacks
🍭 Covert channels and side-channels
🍭 Supply chain attacks
🍭 Underhanded code и не только
Книга не предполагает очень глубокого погружения. Ее цель – дать общее представление о происходящем. А если будут интересны детали, то ссылки на соответствующие материалы можно найти в самой книге.
P.S. Есть еще несколько версий книги: git-версия книги, доступная вот тут и web-версия, доступная вот тут.
Всем привет!
Впереди майские праздники и есть немного свободного времени, например, для того, чтобы что-то почитать.
Если вы искали материал по теме безопасной разработки, то предлагаем вам ознакомиться с электронной книгой в приложении – Low-Level Software Security for Compiler Developers.
В ней содержится много интересной и полезной информации (~ 71 страница) о том, с какими нюансами можно столкнуться при работе с компиляторами.
Внутри можно найти:
🍭 Memory vulnerability based attacks
🍭 Covert channels and side-channels
🍭 Supply chain attacks
🍭 Underhanded code и не только
Книга не предполагает очень глубокого погружения. Ее цель – дать общее представление о происходящем. А если будут интересны детали, то ссылки на соответствующие материалы можно найти в самой книге.
P.S. Есть еще несколько версий книги: git-версия книги, доступная вот тут и web-версия, доступная вот тут.
БеКон 2025!!!
Всем привет!
Уже в третий раз будет проводиться самая ожидаемая конференция, посвященная практическим аспектам ИБ контейнеров и сред контейнеризации – БеКон!
В этом году нас ждет 10 докладов по различным темам:
🍭 Советы по использованию Policy Engine
🍭 Управление трафиком с Cilium
🍭 «Минималистичные ОС» - Talos
🍭 Соответствие требованиям ФСТЭК
🍭 Безопасность ML-кластеров и не только
Программа, как и всегда, получилась крайне насыщенной и интересной. И, что радует, Организаторы продолжают фокусироваться на технических деталях. Поэтому, воды – минимально, «мяса» - максимально!
Само мероприятие пройдет в Москве, 3 июня 2025 года. Подробности приведены на сайте конференции.
Также рекомендуем вступить в канал, в котором будут освещать организационные моменты и саму конференцию.
P.S. До повышения цен на билеты осталось 3 дня. Если хотели посетить, но не могли решиться – сейчас самое время! ☺️
Всем привет!
Уже в третий раз будет проводиться самая ожидаемая конференция, посвященная практическим аспектам ИБ контейнеров и сред контейнеризации – БеКон!
В этом году нас ждет 10 докладов по различным темам:
🍭 Советы по использованию Policy Engine
🍭 Управление трафиком с Cilium
🍭 «Минималистичные ОС» - Talos
🍭 Соответствие требованиям ФСТЭК
🍭 Безопасность ML-кластеров и не только
Программа, как и всегда, получилась крайне насыщенной и интересной. И, что радует, Организаторы продолжают фокусироваться на технических деталях. Поэтому, воды – минимально, «мяса» - максимально!
Само мероприятие пройдет в Москве, 3 июня 2025 года. Подробности приведены на сайте конференции.
Также рекомендуем вступить в канал, в котором будут освещать организационные моменты и саму конференцию.
P.S. До повышения цен на билеты осталось 3 дня. Если хотели посетить, но не могли решиться – сейчас самое время! ☺️
bekon.luntry.ru
Конференция БеКон
Ежегодная конференция по безопасности контейнеров и контейнерных сред, организованная компанией Luntry.