DevSecOps Talks

🔐 Sec в DevSecOps: ищем баланс безопасности в процессе разработки! Всем привет!👋 🤔 Знакомая ситуация? Безопасность важна, но не хочется превращать процесс разработки в бесконечную череду проверок и согласований! В нашей новой статье разобрали самые острые вопросы интеграции безопасности в DevOps: 📊 4 подхода к внедрению Security в процессы разработки 🛠 Shift-Down Security — плюсы и минусы революционного подхода 🏢 Платформенный подход как способ облегчить жизнь разработчикам 🔥 Главное — найти баланс между защитой приложения и комфортом команды! 🔍 Читайте подробнее в посте на Хабре

Раннее обнаружение «CVE» с использованием LLM Всем привет! Регистрация CVE требует некоторого времени. При этом, информация о том, что именно было исправлено в проекте, для которого регистрируется CVE, доступна сильно раньше. Её только надо найти. Бывают и более пугающие случаи: когда было сделано обновление по устранению уязвимости, но CVE никогда не присваивалась. Однако, информация об обновлении все равно доступна в GitHub-репозитории (для open-source проектов). И все точно также – её только надо найти. Именно этой задачей и озаботился Автор статьи. С использованием LLM он создал GitHub Action, который на периодической основе анализировал заданный перечень open-source репозиториев. Для этого извлекались новые коммиты и передавались в Claude, задачей которого было определить – устранялись ли уязвимости или нет. Однако, такой подход создавал как false positive, так и false negative-результаты. Для устранения этого недостатка Автор немного адаптировал подход и используемые инструкции (все в явном виде указано в статье). В итоге все вышло «не без шероховатостей», но тем не менее – PoC был реализован и с его результатами можно ознакомиться по ссылке. Зато! Это решает задачу получения информации об исправлении уязвимости максимально рано, не дожидаясь публикации CVE, обновления баз данных анализаторов и т.д.

CVE Quality-by-Design Manifesto Всем привет! Что такое CVE известно всем и каждому, кто имеет отношение к информационной безопасности. Многие годы собиралась информация об уязвимостях. И каждый год их становится только больше (на этом сайте удобно посмотреть ретроспективу, начиная с 1999 года и до нынешнего времени). По мнению Автора статьи пора переходить от «количества» к «качеству», ведь то, что мы имеем сейчас (далеко) не всегда может быть полезно и применимо. Автор предлагает сфокусироваться на: 🍭 Completeness. Заполнение данных о всех возможных полях, предоставление понятной информации о том, «что это такое и почему это плохо» 🍭 Accuracy. Гомогенность данных, отсутствие устаревшей информации, точность описания 🍭 Timeliness. Своевременное внесение информации об уязвимостях и изменении в них 🍭 Utility. Определение того, насколько полезна запись для принятия решений 🍭 Enrichment. Предоставление дополнительной информации об уязвимости (помимо референсов) Да, с одной стороны, звучит как «за всё хорошее против всего плохого». С другой – с таким ростом количества записей о CVE инструмент может стать достаточно бесполезным, если не предпринимать никаких усилий для того, чтобы сделать данные более целесообразными для использования. А вы согласны с Автором статьи или всё итак нормально и вполне себе работает без каких-либо изменений?

MCP Scan Всем привет! MCP Scan – open-source утилита, которая позволяет выявлять уязвимости при работе с агентами, MCP и навыками (skills). Доступен следующий функционал: 🍭 Автоматическое обнаружение конфигурации MCP, агентов и навыков 🍭 Идентификация Prompt Injection, Tool Poisoning атак и Toxic Flaws в MCP 🍭 Анализ агентов и навыков для выявления Prompt Injection, вредоносного ПО, работы с чувствительными данными и не только Работает с Claude, Cursor, Windsurf и не только. Устанавливается и запускается просто, сразу готов к работе. Можно запускать в нескольких режимах. Пассивное сканирование – запускается по запросу и предоставляет результат. Активный proxy – MCP Scan анализирует все взаимодействие и сразу сообщает о подозрительной активности. Больше про утилиту можно прочесть в GitHub-репозитории или в официальной документации.

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-репозитории или в официальной документации.