DevSecOps Talks

SITF: SDLC Infrastructure Threat Framework. Всем привет! SITF – открытый framework от Wiz, который может быть использован для защиты элементов ИТ-инфраструктуры, которые используются при разработке ПО. Он «разбит» на 5 основных разделов: 🍭 Endpoint/IDE 🍭 VCS 🍭 CI/CD 🍭 Registry 🍭 Production/Cloud Для каждого раздела описаны техники атак (суммарно их более 70 на текущий момент): указан перечень рисков и возможные способы контроля. Еще одной интересной особенностью является Attack Flow Visualizer. Он представляет из себя интерактивный drag’n’drop инструмент для визуализации атак. Работает примерно так: берем компоненты из разделов (IDE, VCS, CI/CD и т.д.), добавляем техники и создаем сценарии атак. В качестве примера в статье рассмотрен Shai-Hulud-2.0 и его анализ с использованием SITF. А если и этого мало, то можно скачать SITF в качестве «плаката» и хоть на стену вешай!

Astrological CPU Scheduler Всем привет! Человек не всесилен, многое ему неподвластно и иногда требуется помощь «свыше»! Для этого, например, можно воспользоваться Astrological CPU Scheduler. Эта эзотерическая утилита позволяет реализовывать CPU Scheduling Decisions с учётом расположения планет, особенностей знаков зодиака и иных ключевых астрологических принципов. Из значимого функционала можно выделить: 🍭 Точный расчет положения планет 🍭 Знание особенностей знаков зодиака 🍭 Определение ретроградности 🍭 Анализ фаз луны 🍭 Учет влияния огненных и водных знаков Всё это и даже больше используется для того, чтобы сделать корректные настройки. Если этого недостаточно, то можно обратиться к ресурсу, в котором представлен календарь, подсказывающий лучшие даты для «деплоя в продакшен» с разбивкой по знакам зодиака. P.S. Да, просто шуточный пятничный пост 😅 (или нет?! 🤔). Серьезное в нём лишь то, что мы желаем вам стабильных релизов, безопасных обновлений и удачных «деплоев в продакшен» 🤗. С пятницей!!! Отличного всем вечера и прекрасных выходных!!!

Observability Conf Всем привет! 19 марта в Москве состоится Observability Conf — отраслевая конференция для всех, кто отвечает за надежность и предсказуемость цифровых сервисов. В программе — выступления от VK, Ozon, «Газпромбанка», «Лаборатории Касперского», «Инфосистемы Джет», X5 Digital, Proto, «Лаборатории Числитель», «Петрович.Тех» и других. А участие — бесплатное. Эксперты обсудят как: 🍭 Работать с мониторингом как в условиях ограниченных ресурсов и отсутствия зрелых процессов, так и в масштабных корпоративных инфраструктурах. 🍭 Перейти от набора метрик к осмысленной наблюдаемости. 🍭 Выстроить эффективную работу с инцидентами. 🍭 Использовать современные инструменты, включая ИИ, для повышения устойчивости систем. Места на офлайн ограничены площадкой, успевайте зарегистрироваться.

Изменение Snyk Security Database Всем привет! Недавно Snyk сделали некоторое «объединение»: данные из Snyk Advisor теперь стали доступны на security.snyk.io. Если перевести на более понятный язык, то теперь полная информация о пакетах (как для разработчиков, так и для ИБ-специалистов) стала доступна в «едином окне». Например: 🍭 Общий «уровень здоровья» пакета (с учетом категорий: безопасность, популярность, поддержка, сообщество) 🍭 Сведения о частоте коммитов 🍭 Информация об уязвимостях (с привязкой к версиям) 🍭 Сведения о количестве скачиваний пакета и т.д. «Работает» не только для языков программирования, но и для пакетов операционных систем.

Security as Code Platform Всем привет! Для каждого языка используется собственный анализатор, у каждого из которых свой набор правил, разрозненная инфраструктура и потребность в покрытии сотен репозиториев. Если вам знакома (или интересна) эту ситуация, то рекомендуем прочесть статью от Plaid. В ней ребята описывают собственный опыт создания Security as Code-платформы. Если кратко, то они унифицировали свои средства анализа и перешли к централизованной модели по принципу Security Pipeline as Code. Есть набор шаблонов, который можно и нужно подключать для анализа репозиториев. Проверки разные – от инкрементального анализа PR до полноценных сканирований. Но интересно другое – как именно ребята создавали свою платформу. Для этого собрались все части «триады». Каждый выполнял свою часть: 🍭 Безопасность определяла «что»: какие сканеры, какие правила, на какие события 🍭 Инфраструктура помогала с вопросом «как»: использование Terraform, контейнеризации и оркестрации 🍭 Специалисты по конвейеру сборки помогали с проработкой конфигурации и оптимизации времени работы задач по ИБ в конвейере 🍭 Разработчики «оценивали» насколько все понятно и удобно для дальнейшего устранения ИБ-дефектов И именно такая совместная работа позволила получить весьма и весьма плодотворные результаты. Еще хочется отметить «рефлексию» в конце статьи, в которой описано, как и что можно было сделать лучше: от настройки сканеров до сокращения количества ложных срабатываний. Рекомендуем к прочтению!

AV API Gateway Всем привет! По ссылке можно ознакомиться с AV API Gateway – open-source решением, реализованным на Go и gin-gonic. Функциональности достаточно много: 🍭 Core Gateway Features. HTTP Routing, gRPC Routing, WebSocket Proy и т.д. 🍭 Security & TLS. Поддержка TLS 1.2/1.3, mTLS, интеграция с Vault и т.д. 🍭 AuthN/AuthZ. Поддержка разных способов аутентификации – JWT, API Key, mTLS, OIDC и т.д. 🍭 Traffic Management. Балансировка нагрузк, управление сессиями, зеркалирование трафика и тд. 🍭 Caching. In-memory Cache, работа с Redis и т.д. С полным перечнем возможностей AV API Gateway можно ознакомиться в GitHub-репозитории проекта. Помимо этого, в нем есть большое количество примеров по настройке и эксплуатации решения. Выглядит всё это достаточно интересно, рекомендуем к ознакомлению!

IDE SHEPHERD: анализ IDE-расширений в режиме реального времени Всем привет! Представить современную разработку без использования IDE можно, но уже достаточно сложно. Согласно отчету от Stack Overflow 75,9% разработчиков используют VS Code, при этом Cursor стремительными шагами набирает популярность. У этих IDE есть нечто общее – возможность получения дополнительного функционала через использование расширений (extensions). И если некоторые из них весьма безобидны и упрощают жизнь, то другие могут нанести вред. Иногда даже через использование расширений от производителей средств по информационной безопасности. Чтобы повысить уровень защищенности при работе с IDE команда DataDog выпустила IDE-SHEPHERD. Да-да, расширение, которое используется для анализа расширений. С её помощью можно: 🍭 Отслеживать запуск процессов 🍭 Отслеживать установку сетевых соединений 🍭 Контролировать запускаемые задачи 🍭 Идентифицировать аномалии в установленных расширениях с использованием методов эвристического анализа Больше про возможности IDE-SHEPHERD, про то, как она «выглядит» и про то, как работает «внутри» можно прочесть в статье. Дополнительно, в статье есть пара примеров того, как ее использование помогло найти вредоносные расширения.

KEV: панацея или нет? Всем привет! База данных, в которой содержится информация об уязвимостях, для которых существуют эксплойты - Known Exploited Vulnerabilities (KEV) – является одной из «точек принятия» решения о необходимости повышения приоритета по устранению уязвимости. Но спасает ли она от всего? Примерно таким вопросом задался Автор статьи. По ссылке можно найти небольшое исследование, в котором Автор представляет иную точку зрения: KEV – скорее некоторый baseline, а не универсальный индикатор расстановки приоритетов. Если сравнить с общим количеством уязвимостей, которое лишь растет год от года, то в KEV можно найти лишь 1%. При этом, наличие эксплойта, хоть и сильно повышает «значимость» уязвимости никак напрямую не связано с риском её эксплуатации для конкретной Компании. В итоге он предлагает следующую модель: 🍭 Уровень №1. Анализ KEV, работа с уязвимостями, которые в ней есть 🍭 Уровень №2. Анализ возможности эксплуатации уязвимостей, которых нет в KEV 🍭 Уровень №3. Использование предсказательных моделей, например, EPSS (к которой тоже есть ряд вопросов) Дополнительно ситуация осложняется и тем, что время на подготовку эксплойтов также сокращается из-за использования нейронных сетей, которые показывают неплохие результаты. Поэтому вопрос расстановки приоритетов по устранению уязвимостей остается открытым. А какие подходы используете вы для решения этой задачи?

Trail of Bits Skills Marketplace Всем привет! Trail of Bits предоставили публичный доступ к Skills – Claude Code плагинам, которые позволяют использовать возможности AI для проведения ИБ-анализа и тестирования. Доступен целый набор «помощников»: 🍭 Semgrep Rule Creator – создание правил для Semgrep 🍭 Static Analysis с использованием Semgrep и CodeQL и последующим анализом SARIF 🍭 Variant Analysis – поиск идентичных ИБ-дефектов в кодовой базе 🍭 Fix Review – анализ предлагаемых способов устранения ИБ-дефектов Firebase APK Scanner – анализ APL на предмет наличия некорректных конфигураций Полный перечень представлен в GitHub-репозитории проекта. Для каждого навыка (skill) представлено его назначение и краткое описание того, что он может делать. Устанавливается крайне просто – /plugin marketplace add trailofbits/skills. Единственный нюанс: работает только с Claude Code и, соответственно, нужен доступ к этому ресурсу.

Игровой сервер в Kubernetes Всем привет! Есть такой сервис – Agones. Он позволяет запускать серверы для игр (dedicated game servers) в Kubernetes и управлять ими. Автор статьи решил разобраться в том, как им пользоваться, зачем он нужен и почему простых pods и deployments будет недостаточно. Для этого он проделал путь: 🍭 Создание собственной игры. Автор выбрал «классические» камень-ножницы-бумага 🍭 Интеграция с SDK Agones, реализация необходимых методов 🍭 Развертывание наработок (Agones вместе со своей игрой) в Kubernetes 🍭 Реализация сервиса по поиску пары для игры (matchmaking) В итоге получилась массивная статья на ~28 минут, в которой каждый шаг разбирается очень детально. Рекомендуем к прочтению, даже если вы не собираетесь запускать игры на Kubernetes, ведь внутри – отличный инженерный опыт: разобраться, понять, запустить, поискать ошибки и пользоваться!

Секреты в GitLab репозиториях Всем привет! Автор проанализировал 5 600 000 GitLab-репозиториев на предмет наличия секретов в них и попутно заработал $9 000 на bug bounty. Если кратко, то использовался весьма стандартный подход: 🍭 Получение общедоступных репозиториев через /api/v4/projects 🍭 Запуск Trufflehog с параметрами --only-verified, --allow-verification-overlap 🍭 Анализ полученных результатов В итоге Автору удалось найти 17 430 секретов, большинство из которых относилось к GCP, MongoDB, TelegramBotToken и OpenAI. Подробнее с результатами исследования, включая способ автоматизации отправки отчетов на BugBounty-программы, можно ознакомиться в статье.

Prompt Injection Attack Classification System Всем привет! Prompt Injection Attack Classification System – проект, в котором Автор классифицировал и систематизировал Prompt Injection-атаки. Представлены 4 основные категории: 🍭 Attack Intents. Описывают цели – извлечение данных, реализация отказа в обслуживании, отравление данных и т.д. 🍭 Attack Techniques. Способы атак – прямые или «косвенные» инъекции 🍭 Attack Evasions. Методы обфускации, которые можно использовать для сокрытия атак 🍭 Attack Inputs. Входные точки для совершения атаки – API-запрос, загрузка файлов, взаимодействие с чат-ботом и т.д. Всего получилось 107 «сущностей»: 18 Intents, 28 Techniques, 51 Evasion и 10 Inputs. Каждая «карточка» интерактивна – нажав на нее можно получить дополнительную информацию.

Supply Chain атака на CodeBuild Всем привет! Потрясающая статья от Wiz, в которой ребята делятся опытом того, как им удалось получить административные права от репозитория aws/aws-sdk-js-v3. Сама суть атаки достаточно проста – сделать PR, который запустит процесс сборки и предоставит атакующим секреты. Но дьявол, как обычно, в деталях. Найти несколько Public CodeBuild Projects оказалось не сложно: информация об их настройках доступна всем. Нюанс в том, что есть webhook filters, которые определяют некоторый набор условий, что должны быть выполнены для запуска процесса сборки, в том числе, при реализации PR. Одним из таких фильтров является ACTOR_ID - идентификатор пользователя, которому дозволено это реализовать. Казалось бы, это конец… Но нет! Присмотревшись к тому, как именно формируется это поле, команда поняла, что внутри обычная regex-проверка. При этом проверка не на полное совпадение строки, а лишь на вхождение! И именно этим воспользовалась команда. Как именно – крайне рекомендуем прочитать – очень красиво и элегантно! В итоге запустить сборку и получить административный доступ к репозиторию получилось. Да – push в main, принятие любых PR и т.д. Таким образом, все пользователи aws/aws-sdk-js-v3 могли бы получать очень «интересные обновления». Но все хорошо, что хорошо кончается. Wiz сообщили об этой находке в AWS и проблема была устранена. На всякий случай в статье приведен перечень действий, которые позволят повысить уровень защищенности при использовании CodeBuild.

Clang Hardening Guide Всем привет! По ссылке можно ознакомиться с рекомендациями по настройке компиляторов C и C++ для того, чтобы сделать их более безопасными. Материал структурирован по разделам: 🍭 General Protections 🍭 Defenses Against Stack-Based Memory Corruption 🍭 Defenses Against Code-Reuse Attacks (ROP/JOP) 🍭 Defenses Against Speculative Execution Attacks Для каждого раздела приведены примеры настроек, которые можно использовать, и описания того, что эти настройки делают. Еще одним полезным материалом по теме могут послужить рекомендации от OpenSSF – Compiler Options Hardening Guide for C and C++.

Написание eBPF-программы Всем привет! Для знакомства с технологией нет ничего лучше, чем «потрогать ее самому». Поэтому, если вы хотели познакомиться с eBPF программами, но не знали с чего начать – ebpf.party может стать той самой «отправной точкой». Это нечто вроде лабораторных работ, где есть все, что нужно – от необходимого теоретического минимума до интерактивной платформы, в которой можно запускать наработки. ebpf.party включает в себя следующие разделы: 🍭 Introduction 🍭 Concept familiarization 🍭 Stateful eBPF 🍭 Kernel probes В каждом разделе описано что необходимо реализовать и предоставлен фрагмент кода с комментариями для лучшего понимания происходящего. Чтобы было чуть проще, в самом задании приводятся примеры, ссылки на материалы по теме и «наводящие вопросы». Для всех задач есть автоматическая проверка корректности – можно будет сразу понять все ли верно сделано или надо что-то изменить. Самое «то» для погружения в eBPF! Рекомендуем!

Gixy-Next: анализ конфигурации Nginx Всем привет! Gixy-Next – open-source утилита, которая позволяет анализировать nginx.conf на предмет некорректных настроек по информационной безопасности. Является активно поддерживаемым fork Gixy от Яндекса. Gixy-Next может помочь найти более 20 некорректных настроек, включая: 🍭 Duplicate Content Type 🍭 External DNS Resolvers 🍭 Host Header Spoofing 🍭 Allow Without Deny 🍭 error_log Set To Off и не только Для каждой проверки приводится описание «почему это плохо», пример некорректной конфигурации и пример того, как это сделать правильно. Подробнее о проекте можно прочесть в GitHub-репозитории или в официальной документации.

ESP Kubernetes Reference Implementation Всем привет! Endpoint State Policy (ESP) позволяет анализировать кластеры Kubernetes на предмет соответствия требованиям. Это нечто вроде OpenSCAP, только вместо XML используются собственные DSL-политики. Состоит он из нескольких основных компонентов: Orchestrator (получает политики, агрегирует аттестации-свидетельства), Controller Agent (работает с cluster-scoped политиками) и Daemon Agent (работает с node-scoped политиками). ESP поддерживает несколько «форматов анализа»: 🍭 k8s_resource. Анализ манифестов API ресурсов Kubernetes 🍭 file_metadata. Исследует аттрибуты файлов с использованием stat() 🍭 file_content. Позволяет анализировать содержимое файлов через работу со строками (содержит, начинается, совпадает и т.д.) 🍭 json_record. Анализ конфигурационных файлов формата JSON 🍭 tcp_listener. Проверяет находится ли порт в статусе listen (через чтение /proc/net/tcp) и не только Да, это не то решение, которое «показывает результат сразу после запуска». Однако, обширная и гибкая функциональность может быть очень полезна при проведении аудитов соответствия кластера Kubernetes требованиям. Подробности о работе ESP можно прочесть в GitHub-репозитории проекта.

USVL: визуализация атак и моделей угроз Всем привет! Universal Security Visualization Library (USVL) – open-source проект, который генерирует схемы на основании предоставленной конфигурации. Он может «отрисовать»: 🍭 Attack Trees. Иерархические диаграммы сценария атаки 🍭 Attack Graph. Визуализация атаки с точки зрения сети 🍭 Threat Modelling. Диаграммы потоков данных, учитывающие анализ, реализованный с использованием STRIDE Если это не хватает, то допустимо создание собственных диаграмм («из коробки» доступны формы для использования и шаблоны). В качестве «входных данных» USVL может работать с TOML, YAML и JSON. Полученные результаты можно выгружать в Mermaid-формате. Подробнее с возможностями инструмента, вариантами его запуска и эксплуатации можно ознакомиться в GitHub-репозитории проекта.

A2A Security Scanner Всем привет! Безопасность Agent-to-Agent взаимодействий становится все более и более актуальной задачей. Если что-то «пойдет не так», то могут случиться разные последствия: кража ценной информации, повышение привилегий, подмена артефактов, prompt-injection атаки и многое другое. Для анализа A2A можно воспользоваться open-source решением от Cisco – A2A Security Scanner. Из основных функций можно выделить: 🍭 Множество специализированных анализаторов: YARA-правила, идентификация угроз с LLM, использование эвристики и не только 🍭 Покрытие множества A2A угроз 🍭 Наличие API и CLI для реализации интеграций и не только Подробнее со сканером (в том числе с видами угроз, которые он может идентифицировать) можно ознакомиться в GitHub-репозитории и в статье от Cisco, где они его анонсировали.

CrashLoopBackOff и как с ним бороться Всем привет! Если вы работали с Kubernetes, то, скорее всего, хотя бы раз видели такое вот сообщение: CrashLoopBackOff. Да, для опытных специалистов это уже не проблема. А всем остальным может быть интересна вот эта статья, в которой Автор разбирает эту ошибку. В статье есть информация о том: 🍭 Что это такое и как оно работает 🍭 Как искать ошибки, приводящие к этому состоянию 🍭 Наиболее частые причины возникновения CrashLoopBackOff 🍭 Как исправить это состояние и сделать так, чтобы все работало Да, в статье вы не найдете каких-либо откровений, но она может быть полезна для тех, кто только начинает знакомиться с миром контейнеризации и Kubernetes в частности. Пояснения, примеры и общий checklist по поиску ошибок – все это есть в статье.