Forwarded from k8s (in)security (Дмитрий Евдокимов)
Наши хорошие друзья запустили аж целых
1) Исследование рынка безопасной разработки и DevSecOps
2) Исследование рынка средств контейнеризации
3) Исследование рынка безопасности ИИ-систем (MLSecOps)
По сути это опросы, результаты которых должны показать реальное (не маркетинговое) положения дел в этих направлениях. Мы с радостью поддерживаем их в этой активности!
Больше деталей можно узнать тут.
3 исследования: 1) Исследование рынка безопасной разработки и DevSecOps
2) Исследование рынка средств контейнеризации
3) Исследование рынка безопасности ИИ-систем (MLSecOps)
По сути это опросы, результаты которых должны показать реальное (не маркетинговое) положения дел в этих направлениях. Мы с радостью поддерживаем их в этой активности!
Больше деталей можно узнать тут.
👍4🔥4🥰2💩2
Защита CI/CD: опыт Cilium
Всем привет!
Защита цепочки поставки и окружения сборки/доставки максимально актуальна в настоящее время.
Для команды Cilium это крайне важно, т.к. их продуктами пользуются множество компаний по всему миру.
Поэтому они достаточно серьёзно подошли к вопросу. И, заодно, поделились своим опытом со всеми желающими.
В статье затрагиваются темы:
🍭 Кто может запускать сборки, где они осуществляются
🍭 Использование
🍭 Работа с зависимостями (pinning, обновления и т.д.)
🍭 Статический анализ
🍭 Работа с учётными данными и не только
Если нет времени читать всю статью, то вначале есть очень ёмкий tl;dr. Он описывает (в общем) подходы и практики, которые применяет Cilium.
Многое «завязано» на возможности GitHub Actions, однако это можно повторить и в других CI-решениях, если сам подход вам понравился.
Всем привет!
Защита цепочки поставки и окружения сборки/доставки максимально актуальна в настоящее время.
Для команды Cilium это крайне важно, т.к. их продуктами пользуются множество компаний по всему миру.
Поэтому они достаточно серьёзно подошли к вопросу. И, заодно, поделились своим опытом со всеми желающими.
В статье затрагиваются темы:
🍭 Кто может запускать сборки, где они осуществляются
🍭 Использование
CODEOWNERS для контроля изменений🍭 Работа с зависимостями (pinning, обновления и т.д.)
🍭 Статический анализ
🍭 Работа с учётными данными и не только
Если нет времени читать всю статью, то вначале есть очень ёмкий tl;dr. Он описывает (в общем) подходы и практики, которые применяет Cilium.
Многое «завязано» на возможности GitHub Actions, однако это можно повторить и в других CI-решениях, если сам подход вам понравился.
cilium.io
Securing CI/CD for an open source project: lessons from Cilium
A case study of how Cilium secures its CI/CD pipeline end to end: SHA-pinned actions, two-phase checkouts for pull_request_target, Re...
👍2
AI агенты для SRE-операций
Всем привет!
Эксплуатация чего бы то ни было задача непростая, особенно когда возникают инциденты и их приходится решать. Особенно ночью. Или в выходные.
При этом процесс (зачастую) носит достаточно системный характер: посмотреть журналы событий, проанализировать метрики, уточнить что было установлено, какие были изменения и т.д.
И проблема далеко не всегда в сложности задачи или отсутствии данных для анализа. Скорее наоборот – данных слишком много и тратится много времени на поиск ответов.
Это приводит к мысли об автоматизации. Хотя бы в части понимания причины и возможных действий по её устранению.
Именно этому и посвящена статья.
В ней Автор рассказывает собственный опыт создания системы, которая получает уведомление об инциденте, анализирует данные и предоставляет пользователю сведения о причине и возможных способах решения проблемы.
Для этого предлагается 5-и уровневая архитектура:
🍭 Layer 1. Данные. Журналы, метрики, события и т.д.
🍭 Layer 2. Инструменты. Системы мониторинга, логирования, непрерывной сборки, оркестрации контейнеров и т.д.
🍭 Layer 3. «Специалисты». Агенты для работы с инструментами
🍭 Layer 4. Оркестрация. Управление работой агентов
🍭 Layer 5. Люди. Принятие решений, аналитика, отчётность
С использованием этой архитектуры Автор реализовал 8 шагов, который автоматизируют процесс работы с инцидентами.
Помимо этого, в статье можно найти примеры того, как это работает и перечень технологий, которые позволили реализовать концепт.
Всем привет!
Эксплуатация чего бы то ни было задача непростая, особенно когда возникают инциденты и их приходится решать. Особенно ночью. Или в выходные.
При этом процесс (зачастую) носит достаточно системный характер: посмотреть журналы событий, проанализировать метрики, уточнить что было установлено, какие были изменения и т.д.
И проблема далеко не всегда в сложности задачи или отсутствии данных для анализа. Скорее наоборот – данных слишком много и тратится много времени на поиск ответов.
Это приводит к мысли об автоматизации. Хотя бы в части понимания причины и возможных действий по её устранению.
Именно этому и посвящена статья.
В ней Автор рассказывает собственный опыт создания системы, которая получает уведомление об инциденте, анализирует данные и предоставляет пользователю сведения о причине и возможных способах решения проблемы.
Для этого предлагается 5-и уровневая архитектура:
🍭 Layer 1. Данные. Журналы, метрики, события и т.д.
🍭 Layer 2. Инструменты. Системы мониторинга, логирования, непрерывной сборки, оркестрации контейнеров и т.д.
🍭 Layer 3. «Специалисты». Агенты для работы с инструментами
🍭 Layer 4. Оркестрация. Управление работой агентов
🍭 Layer 5. Люди. Принятие решений, аналитика, отчётность
С использованием этой архитектуры Автор реализовал 8 шагов, который автоматизируют процесс работы с инцидентами.
Помимо этого, в статье можно найти примеры того, как это работает и перечень технологий, которые позволили реализовать концепт.
Medium
Building an AI Agent That Runs Your SRE Operations — What I Learned, What Works, and How You Can Do It Too
Every SRE team has the same story. Here is how we change the ending.
👍2🔥2💩1
Qwen 2.5 7B: «тонкая» настройка для ответов на ИБ-вопросы
Всем привет!
Автор статьи работает над собственным решением – Valqore. Его задача состоит в сканировании Kubernetes, Terraform и облачных ресурсов для поиска ошибок различного рода: от ИБ до несоответствия требованиям.
В качестве основы используется «движок» с детерминированным набором правил: он не галлюцинирует и даёт идемпотентный результат.
Для удобства пользователя Автор захотел добавить ИИ, который смог бы объяснить просто и понятно: «Что не так и как это исправить?».
И тут возникла проблема: ответы AI могли быть корректными, но общими. Она хорошо «подсказывала» в вопросах, связанных с облаками. Однако, ответы резко становились хуже, если вопросы были именно про Valqore.
Решением стало обучение Qwen 2.5 7B:
🍭 Создание набора данных о правилах (что проверяет, в чём проблема, как исправить и т.д.)
🍭 Создание набора данных о «доменах» (Kubernetes, Terraform, CIS Benchmarks и т.д.)
🍭 Тренировка
В результате Автору получилось добиться желаемого результата. Примеры «до» и «после» можно найти в статье.
Кроме того, там перечислены его «ошибки» и «гипотезы, которые не сработали».
А в завершение статьи представлена общая статистика обучения: от количества тестовых данных до времени обучения.
Всем привет!
Автор статьи работает над собственным решением – Valqore. Его задача состоит в сканировании Kubernetes, Terraform и облачных ресурсов для поиска ошибок различного рода: от ИБ до несоответствия требованиям.
В качестве основы используется «движок» с детерминированным набором правил: он не галлюцинирует и даёт идемпотентный результат.
Для удобства пользователя Автор захотел добавить ИИ, который смог бы объяснить просто и понятно: «Что не так и как это исправить?».
И тут возникла проблема: ответы AI могли быть корректными, но общими. Она хорошо «подсказывала» в вопросах, связанных с облаками. Однако, ответы резко становились хуже, если вопросы были именно про Valqore.
Решением стало обучение Qwen 2.5 7B:
🍭 Создание набора данных о правилах (что проверяет, в чём проблема, как исправить и т.д.)
🍭 Создание набора данных о «доменах» (Kubernetes, Terraform, CIS Benchmarks и т.д.)
🍭 Тренировка
В результате Автору получилось добиться желаемого результата. Примеры «до» и «после» можно найти в статье.
Кроме того, там перечислены его «ошибки» и «гипотезы, которые не сработали».
А в завершение статьи представлена общая статистика обучения: от количества тестовых данных до времени обучения.
Medium
I Fine-Tuned a 7B Model to Be a Cloud Security Expert On My Local Machine, For $0
43 minutes on a consumer GPU, 3,298 training pairs, $0 API cost and it refuses to hallucinate
❤3
JWT: уязвимости, атаки и ИБ-практики
Всем привет!
Сейчас сложно представить веб-приложение, которое не использует JSON Web Token (JWT). Например, для аутентификации.
Оттого эти токены и их безопасность – задача достаточно важная. Но какие для них характерны уязвимости, атаки и как сделать их более защищёнными?
Ответы на эти вопросы можно найти в статье.
В ней Автор рассматривает:
🍭 Что такое JWT, его структура
🍭 Преимущества и недостатки использования JWT
🍭 Наиболее часто встречающиеся уязвимости JWT
🍭 Способы повышения безопасности при работе с JWT
Статья написана очень доступным и простым языком. Много примеров, диаграмм и пояснений.
Отлично подойдёт как для начала изучения вопроса, так и для систематизации знаний.
Всем привет!
Сейчас сложно представить веб-приложение, которое не использует JSON Web Token (JWT). Например, для аутентификации.
Оттого эти токены и их безопасность – задача достаточно важная. Но какие для них характерны уязвимости, атаки и как сделать их более защищёнными?
Ответы на эти вопросы можно найти в статье.
В ней Автор рассматривает:
🍭 Что такое JWT, его структура
🍭 Преимущества и недостатки использования JWT
🍭 Наиболее часто встречающиеся уязвимости JWT
🍭 Способы повышения безопасности при работе с JWT
Статья написана очень доступным и простым языком. Много примеров, диаграмм и пояснений.
Отлично подойдёт как для начала изучения вопроса, так и для систематизации знаний.
Vaadata - Your Expert Partner in Offensive Security
JWT: Vulnerabilities, Attacks & Security Best Practices
This article explains how JWT (JSON Web Token) works. It also details the vulnerabilities, attacks and best practices to secure the Implementation of JWT.
👍2🔥2
AegisBPF: runtime-защита Linux и Kubernetes
Всем привет!
AegisBPF – open-source инструмент, который позволяет отслеживать и блокировать несанкционированные действия с файловой системой и/или попытки установления сетевых соединений.
Для этого он использует возможности BPF и Linux Security Modules (LSM).
Из ключевых возможностей можно выделить:
🍭 Использование BPF LSM для блокировки открытия файлов
🍭 Контроль разрешенных IP-адресов, CIDR, портов и т.д.
🍭 Возможность работы в режиме «мониторинга»
🍭 Выгрузка метрик в Prometheus (количество блокировок, статистика)
🍭 Полноценное журналирование активности и не только
Возможна установка как на «обычную» Linux-машину, так и в кластер Kubernetes (для этого есть готовый Helm Chart).
Для визуализации информации (общие метрики, информация по политикам) можно использовать WebUI AegisBPF.
Больше информации, включая данные о потреблении ресурсов в сравнении с Tetragon и Falco, можно найти в GitHub-репозитории проекта.
Всем привет!
AegisBPF – open-source инструмент, который позволяет отслеживать и блокировать несанкционированные действия с файловой системой и/или попытки установления сетевых соединений.
Для этого он использует возможности BPF и Linux Security Modules (LSM).
Из ключевых возможностей можно выделить:
🍭 Использование BPF LSM для блокировки открытия файлов
🍭 Контроль разрешенных IP-адресов, CIDR, портов и т.д.
🍭 Возможность работы в режиме «мониторинга»
🍭 Выгрузка метрик в Prometheus (количество блокировок, статистика)
🍭 Полноценное журналирование активности и не только
Возможна установка как на «обычную» Linux-машину, так и в кластер Kubernetes (для этого есть готовый Helm Chart).
Для визуализации информации (общие метрики, информация по политикам) можно использовать WebUI AegisBPF.
Больше информации, включая данные о потреблении ресурсов в сравнении с Tetragon и Falco, можно найти в GitHub-репозитории проекта.
GitHub
GitHub - ErenAri/Aegis-BPF: Deterministic Linux runtime enforcement with eBPF LSM: block file/network operations before syscalls…
Deterministic Linux runtime enforcement with eBPF LSM: block file/network operations before syscalls complete. - ErenAri/Aegis-BPF
The Definitive Guide to AI for DevOps1.pdf
93.2 MB
The Definitive Guide to AI for DevOps / Agentic DevOps
Всем привет!
В приложении можно найти whitepaper (~ 43 страницы): The Definitive Guide to AI for DevOps / Agentic DevOps.
Материал подготовлен небезызвестным специалистом в мире Kubernetes и DevOps – Mumshad Mannambeth совместно с Jennifer Riggins.
Согласно материалу, в 2026 году из-за массового внедрения ИИ в «основную жизнь» «основной вопрос» изменился с «Насколько быстро мы можем писать код?» на «Как мы можем безопасно доставлять его в промышленное окружение?».
Но ИИ – таже самая технология, помощник. И всё очень сильно зависит от того, как с ним работать.
Бездумное использование принесёт больше проблем. Продуманное – может помочь. Но как быть и что делать?
Именно этому и посвящён whitepaper.
Он содержит разделы:
🍭 Where we are today. Нюансы, порождаемые повсеместным использованием ИИ
🍭 Where we need now. Использование guardrails, использование мульти-агентских систем, безопасность и observability
🍭 Measurement that matter. О том, какие метрики можно использовать для оценки эффективности использования ИИ в DevOps
Явных ответов и детальных планов, содержащих пошаговые инструкции не представлено.
Однако, внутри много интересных мыслей, которые помогут сориентироваться в том, что делать.
P.S. Поблагодарить Mumshad Mannambeth и команду, которая делала whitepaper можно вот тут! ☺️
Всем привет!
В приложении можно найти whitepaper (~ 43 страницы): The Definitive Guide to AI for DevOps / Agentic DevOps.
Материал подготовлен небезызвестным специалистом в мире Kubernetes и DevOps – Mumshad Mannambeth совместно с Jennifer Riggins.
Согласно материалу, в 2026 году из-за массового внедрения ИИ в «основную жизнь» «основной вопрос» изменился с «Насколько быстро мы можем писать код?» на «Как мы можем безопасно доставлять его в промышленное окружение?».
Но ИИ – таже самая технология, помощник. И всё очень сильно зависит от того, как с ним работать.
Бездумное использование принесёт больше проблем. Продуманное – может помочь. Но как быть и что делать?
Именно этому и посвящён whitepaper.
Он содержит разделы:
🍭 Where we are today. Нюансы, порождаемые повсеместным использованием ИИ
🍭 Where we need now. Использование guardrails, использование мульти-агентских систем, безопасность и observability
🍭 Measurement that matter. О том, какие метрики можно использовать для оценки эффективности использования ИИ в DevOps
Явных ответов и детальных планов, содержащих пошаговые инструкции не представлено.
Однако, внутри много интересных мыслей, которые помогут сориентироваться в том, что делать.
P.S. Поблагодарить Mumshad Mannambeth и команду, которая делала whitepaper можно вот тут! ☺️
❤3💩1
MCP Configuration Poisoning
Всем привет!
Ёмкая статья от Checkmarx, посвященная тому, как можно выполнять произвольный код на рабочей станции жертвы через воздействие на конфигурационные MCP-файлы.
Эти файлы содержат информацию о возможных для использования MCP-серверах: наименование, выполняемая команда, аргументы, переменные окружения и т.д.
Сама атака состоит в том, чтобы подменить «выполняемую команду» на ту, что нужна атакующему и с большой вероятностью она выполнится.
Из плохого – запуск в большинстве случаев может произойти автоматически, без запроса подтверждения пользователем. В некоторых сценариях даже Human-In-The-Loop (HITL) можно обойти.
Из хорошего – реализовать это может быть не так просто, т.к. потребует некоторого доступа к данным проекта.
В качестве примера реализации Автор приводит Snyk,(кстати, Snyk сперва не согласился с тем, что это недостаток ☺️) .
Подобное трудно найти с использованием сканеров. «Ограничивать» команды тоже не всегда представляется возможным.
Поэтому в качестве рекомендации Автор предлагает использование «песочниц», мониторинг и контроль выполняемых программ и подтверждение действий пользователем.
Всем привет!
Ёмкая статья от Checkmarx, посвященная тому, как можно выполнять произвольный код на рабочей станции жертвы через воздействие на конфигурационные MCP-файлы.
Эти файлы содержат информацию о возможных для использования MCP-серверах: наименование, выполняемая команда, аргументы, переменные окружения и т.д.
Сама атака состоит в том, чтобы подменить «выполняемую команду» на ту, что нужна атакующему и с большой вероятностью она выполнится.
Из плохого – запуск в большинстве случаев может произойти автоматически, без запроса подтверждения пользователем. В некоторых сценариях даже Human-In-The-Loop (HITL) можно обойти.
Из хорошего – реализовать это может быть не так просто, т.к. потребует некоторого доступа к данным проекта.
В качестве примера реализации Автор приводит Snyk,
snyk-agent-scan которых как раз мог «реализовать» MCP Configuration PoisoningПодобное трудно найти с использованием сканеров. «Ограничивать» команды тоже не всегда представляется возможным.
Поэтому в качестве рекомендации Автор предлагает использование «песочниц», мониторинг и контроль выполняемых программ и подтверждение действий пользователем.
Checkmarx
MCP Config Poisoning: Text file to RCE - Checkmarx Zero
Attackers can weaponize your AI agent tooling just by sneaking a text file into the right place on your system.
Contextual Security Analysis Guide 2026.pdf
386.6 KB
Contextual Security Analysis
Всем привет!
В приложении можно найти небольшой документ (~ 18 страниц) от DryRun Security, в котором представлена их модель контекстного анализа безопасности ПО.
Начинается всё с небольшого вступления, описывающего проблематику и «слепые» зоны детерминированных подходов, а также нюансы, связанные с генерацией кода.
Чтобы это преодолеть, по мнению команды DryRun, необходимо получать контекст, который позволит понять, что важно, а что - нет.
Но что такое этот самый «контекст»? Именно это и раскрывается в статье, а именно – SLIDE.
Он содержит параметры:
🍭 Surface. Как поверхность атаки меняется от commit к commit
🍭 Language. Какие языки программирования, framework’и, зависимости и т.д. участвуют в изменении
🍭 Intent. Информация об Авторе изменения, частоте изменений, ИБ-компетенциям
🍭 Detection. Данные о сканировании, получаемые из SAST, DAST, SCA и т.д.
🍭 Environment. Данные, с которыми работает ПО, наличие регуляторных требований и т.д.
Для каждого параметра кратко описывается почему он важен для расстановки приоритетов, а также где (потенциально) эти данные можно получить.
В итоге имеем набор данных, который позволяет понять, насколько то или иное изменение критично и стоит ли обращать на него внимание.
Несколько примеров использования предлагаемого подхода можно найти непосредственно в материале.
Всем привет!
В приложении можно найти небольшой документ (~ 18 страниц) от DryRun Security, в котором представлена их модель контекстного анализа безопасности ПО.
Начинается всё с небольшого вступления, описывающего проблематику и «слепые» зоны детерминированных подходов, а также нюансы, связанные с генерацией кода.
Чтобы это преодолеть, по мнению команды DryRun, необходимо получать контекст, который позволит понять, что важно, а что - нет.
Но что такое этот самый «контекст»? Именно это и раскрывается в статье, а именно – SLIDE.
Он содержит параметры:
🍭 Surface. Как поверхность атаки меняется от commit к commit
🍭 Language. Какие языки программирования, framework’и, зависимости и т.д. участвуют в изменении
🍭 Intent. Информация об Авторе изменения, частоте изменений, ИБ-компетенциям
🍭 Detection. Данные о сканировании, получаемые из SAST, DAST, SCA и т.д.
🍭 Environment. Данные, с которыми работает ПО, наличие регуляторных требований и т.д.
Для каждого параметра кратко описывается почему он важен для расстановки приоритетов, а также где (потенциально) эти данные можно получить.
В итоге имеем набор данных, который позволяет понять, насколько то или иное изменение критично и стоит ли обращать на него внимание.
Несколько примеров использования предлагаемого подхода можно найти непосредственно в материале.
❤1👍1
Насколько хорошо ИИ анализирует код, написанный им же?
Всем привет!
Автор статьи работает в Greptile, которая занимается разработкой агента для AI Code Review.
В процессе работы ему стало интересно, влияет ли используемая модель на то, сколько недостатков находится?
Или, если проще, насколько хороши модели в анализе кода, который написан ими же?
Для этого он подготовил данные и методологию:
🍭 Собрал данные из 500 PR, которые были написаны с использованием Claude Code и Codex
🍭 «Авторство» модели определялось через данные, получаемые из commit, названий PR и/или веток
🍭 Подготовил перечень дефектов, которые были в этих 500 PR
🍭 Запустил Codex и Claude Code в
🍭 «Почистил» результаты от комментариев, которые относились к «стилистике» и не являлись дефектами
Что получилось? Оказалось, что модели лучше ищут ошибки в коде, который написан другими моделями.
Разрыв не очень большой, но всё же присутствует.
Ещё одним интересным наблюдением оказалось то, что модель скорее всего допустит ошибку при разработке, которую она скорее всего пропустит в review.
Помимо этого, в статье есть ещё много интересного. Включая дефекты, которые находились при «рассуждениях», но пропадали из «финального вердикта».
Всем привет!
Автор статьи работает в Greptile, которая занимается разработкой агента для AI Code Review.
В процессе работы ему стало интересно, влияет ли используемая модель на то, сколько недостатков находится?
Или, если проще, насколько хороши модели в анализе кода, который написан ими же?
Для этого он подготовил данные и методологию:
🍭 Собрал данные из 500 PR, которые были написаны с использованием Claude Code и Codex
🍭 «Авторство» модели определялось через данные, получаемые из commit, названий PR и/или веток
🍭 Подготовил перечень дефектов, которые были в этих 500 PR
🍭 Запустил Codex и Claude Code в
/review 3 раза🍭 «Почистил» результаты от комментариев, которые относились к «стилистике» и не являлись дефектами
Что получилось? Оказалось, что модели лучше ищут ошибки в коде, который написан другими моделями.
Разрыв не очень большой, но всё же присутствует.
Ещё одним интересным наблюдением оказалось то, что модель скорее всего допустит ошибку при разработке, которую она скорее всего пропустит в review.
Помимо этого, в статье есть ещё много интересного. Включая дефекты, которые находились при «рассуждениях», но пропадали из «финального вердикта».
Greptile
Models are worse at reviewing their own code | Greptile Blog
We noticed GPT reviewed Claude's code better than its own, and vice versa. So we ran a thousand buggy PRs through both models to find out why.
❤4🤡1
DSO2026_DD.pdf
4.1 MB
State of DevSecOps 2026
Всем привет!
В приложении можно скачать отчёт от Datadog (~23 страницы), посвященный состоянию DevSecOps.
Для подготовки отчёта команда проанализировала результаты, генерируемые Datadog Code Security’s Software Composition Analysis.
В итоге получилось следующее:
🍭 87% организаций «обладают» хотя бы одной эксплуатируемой уязвимостью
🍭 Обновления библиотек занимают длительное время (медиана – «отставание» на 278 дней от самой новой major-версии)
🍭 Только 18% критичных уязвимостей остаются такими после уточнения базовой CVSS-оценки
🍭 32% организаций использовали публичные Docker образы через день после выхода новой версии
🍭 Аналогичное характерно и для JS и Python – 55%
Ничего революционного, ещё одно подтверждение того, что атаки на цепочку поставок сейчас занимают крайне объёмное место и важно уметь с ними работать.
В завершении отчёта можно найти набор общих рекомендаций о том, как можно повысить уровень защищенности при работе с open-source компонентами, цепочкой поставки и т.д.
Всем привет!
В приложении можно скачать отчёт от Datadog (~23 страницы), посвященный состоянию DevSecOps.
Для подготовки отчёта команда проанализировала результаты, генерируемые Datadog Code Security’s Software Composition Analysis.
В итоге получилось следующее:
🍭 87% организаций «обладают» хотя бы одной эксплуатируемой уязвимостью
🍭 Обновления библиотек занимают длительное время (медиана – «отставание» на 278 дней от самой новой major-версии)
🍭 Только 18% критичных уязвимостей остаются такими после уточнения базовой CVSS-оценки
🍭 32% организаций использовали публичные Docker образы через день после выхода новой версии
🍭 Аналогичное характерно и для JS и Python – 55%
Ничего революционного, ещё одно подтверждение того, что атаки на цепочку поставок сейчас занимают крайне объёмное место и важно уметь с ними работать.
В завершении отчёта можно найти набор общих рекомендаций о том, как можно повысить уровень защищенности при работе с open-source компонентами, цепочкой поставки и т.д.
❤2
Конфигурация сети в Linux: практика
Всем привет!
По ссылке доступна лабораторная работа от Iximiuz Labs(Ivan Velichko), в которой придётся поработать с настройкой сети Linux-хостов.
Условия простые: есть 2 сервера в одной сети. На одном – Ubuntu, на втором Rocky Linux. Надо проанализировать их конфигурацию и ответить на вопросы.
Примеры вопросов:
🍭 Какие названия у основных сетевых интерфейсов
🍭 IPv4/MAC-адреса рабочих станций
🍭 IPv4 адрес шлюза по умолчанию
🍭 Через какой интерфейс пакеты отправляются на указанный адрес и т.д.
Да, задания достаточно базовые, но! Это те знания, которые точно пригодятся, ведь без понимания работы сетей – никуда. И если вы начинаете с этим работать, то лабораторные – то, что надо.
Для запуска не требуется ничего устанавливать, всё доступно непосредственно на сайте в интерактивной «площадке».
P.S. Помимо этой лабораторной, на labs.iximiuz.com можно найти ещё очень много всего интересного – рекомендуем!
Всем привет!
По ссылке доступна лабораторная работа от Iximiuz Labs(Ivan Velichko), в которой придётся поработать с настройкой сети Linux-хостов.
Условия простые: есть 2 сервера в одной сети. На одном – Ubuntu, на втором Rocky Linux. Надо проанализировать их конфигурацию и ответить на вопросы.
Примеры вопросов:
🍭 Какие названия у основных сетевых интерфейсов
🍭 IPv4/MAC-адреса рабочих станций
🍭 IPv4 адрес шлюза по умолчанию
🍭 Через какой интерфейс пакеты отправляются на указанный адрес и т.д.
Да, задания достаточно базовые, но! Это те знания, которые точно пригодятся, ведь без понимания работы сетей – никуда. И если вы начинаете с этим работать, то лабораторные – то, что надо.
Для запуска не требуется ничего устанавливать, всё доступно непосредственно на сайте в интерактивной «площадке».
P.S. Помимо этой лабораторной, на labs.iximiuz.com можно найти ещё очень много всего интересного – рекомендуем!
iximiuz Labs
Inspect Network Interfaces, IP Addresses, and Routes on a Linux Host | Challenge
Practice reading the network configuration of Linux hosts: find interface names, IP and MAC addresses, the default gateway, and detect which routes a server uses to reach different destinations.
❤3
WIZ_CC_CS.pdf
6.2 MB
Claude Code: Security Best Practices
Всем привет!
Небольшой пятничный пост!
В приложении можно найти документ (~ 7 страниц), подготовленный Wiz и посвященный вопросам безопасности при работе с Claude Code.
Cheat Sheet содержит разделы:
🍭 Prompt Hygiene and Data Handling. Что (не) надо писать в prompt
🍭 Secure Code Generation. Рекомендации о том, как получить более безопасный код при его генерации
🍭 Supply Chain Attacks. Проверки на slopsquatting, работа с lockfile
🍭 Access Control. Ограничение возможностей агента, его полномочий и доступа к чувствительным данным
Каждый раздел содержит Action Item, в котором даются вполне конкретные советы и примеры того, как можно и нужно делать.
В завершение приводится небольшой перечень лучших практик по работе с агентами, MCP, встраиванию проверок в CI.
Ёмко, лаконично и по делу ☺️
Всем привет!
Небольшой пятничный пост!
В приложении можно найти документ (~ 7 страниц), подготовленный Wiz и посвященный вопросам безопасности при работе с Claude Code.
Cheat Sheet содержит разделы:
🍭 Prompt Hygiene and Data Handling. Что (не) надо писать в prompt
🍭 Secure Code Generation. Рекомендации о том, как получить более безопасный код при его генерации
🍭 Supply Chain Attacks. Проверки на slopsquatting, работа с lockfile
🍭 Access Control. Ограничение возможностей агента, его полномочий и доступа к чувствительным данным
Каждый раздел содержит Action Item, в котором даются вполне конкретные советы и примеры того, как можно и нужно делать.
В завершение приводится небольшой перечень лучших практик по работе с агентами, MCP, встраиванию проверок в CI.
Ёмко, лаконично и по делу ☺️
❤4👍2💩1