fa
Feedback
DevSecOps Talks

DevSecOps Talks

رفتن به کانال در Telegram

Рассказываем об актуальном в мире DevSecOps. Канал DevSecOps-команды "Инфосистемы Джет"

نمایش بیشتر
7 839
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+357 روز
+9730 روز
آرشیو پست ها
8 tips for securing CI/CD pipeline Всем привет! Тема безопасности конвейера сборки набирает все большую популярность, появляются различные guides, стандарты, рекомендации и т.д. SNYK не стал исключением и выпустил свой cheatsheet. Внутри можно найти: 🍭 Check your dependencies for potential security issues 🍭 Perform static analysis on your own code 🍭 Scan your container images 🍭 CI pre and post merge scanning и не только Для каждой из 8-и рекомендаций приводятся примеры и описание того, что имеется ввиду.

Использование LLM для анализа open source пакетов Всем привет! Интересный эксперимент провела команда Endor Labs. Ребята захотели проверить гипотезу о возможности использования LLM для анализа open source пакетов. В качестве LLM выбрали ChatGPT v3.5 и приступили к анализу. Среди ~ 1800 «подопытных» было идентифицировано 34 «вредоносных» артефакта, среди которых 🍭 13 – True Positive 🍭 1 представлял из себя безвредный PoC 🍭 5 артефактов содержали обфусцированный код, который был безвреден 🍭 15 – False Negative С одной стороны – результат неудачный. Но, помимо «решения» о вредоносности пакета ChatGPT описывал, что происходит в анализируемом коде. Встречались случаи, когда модель явно описывала Reverse Shell, но признавала пакет «нейтральным». Поэтому все может быть не так плохо. Примеры разбора, а также некоторые «хитрости» как можно обойти такой анализ и обмануть модель (достаточно тривиально) – все это есть в статье. Ранее мы писали о похожем эксперименте от Semgrep, но суть была иная – написание правил анализа. Жутко интересно посмотреть, во что это превратится в горизонте условных 5 лет!

Анализ ИБ пакетов в режиме «реального времени» Всем привет! Один из способов устранения проблем при debug – это Google! Зачастую он ведет на StackOverflow или иные подобные ресурсы, где можно встретить советы в стиле «Надо просто установить/обновить пакет до версии XXX». Допустим, что вы – Разработчик, которому не все равно на ИБ (верим, что такие есть!). Как узнать, есть ли у этого пакета уязвимости и насколько он «хорош» с точки зрения ИБ? Да, есть много разных ресурсов (например, Snyk Advisory, Deps и их аналоги), но потребуется сделать слишком много действий. А хочется здесь и сейчас! Именно так размышляли члены SCAR (Supply Chain Attack Research – организация, объединяющая Checkmarx, Aqua, Cider, SNYK, Mend и не только), когда создавали Overlay. Overlay представляет из себя надстройку для browser (Chrome, Mozilla), которая может распознавать упоминания пакетов на сайтах и сразу «подсказывать» что в нем есть плохого. Альтернативный сценарий – «расширение» выдачи информации о пакетах на индексах с добавлением информации по уязвимостям и результатам анализа OSSF Scorecard. Информацию об ограничениях работоспособности можно найти в repo проекта. Выглядит крайне удобно и, что самое главное, developer-friendly ☺️ P.S. А если Вам захочется чуть больше узнать про SCAR и историю создания Overlay – можно обратиться к этой статье.

Как работает Kube-Proxy? Всем привет! Еще одна неплохая статья, которая может быть полезна при изучении устройства сети Kubernetes. На этот раз главным героем выступает Kube-Proxy. Многие слышали, что «IP-адреса pod’ов практически ничего не значат в Kubernetes». Все так. На самом деле они есть, просто могут достаточно часто изменяться и нужно нечто более постоянное. По этой причине нужен ресурс типа Service, который обладает «стабильным» IP-адресом и набором endpoints – тех самых pod, которые к нему «привязаны» через Labels. Но как именно это происходит? Именно для этого и нужен Kube-Proxy (кстати, можно реализовать аналогичную схему и без него). В статье описано что происходит «под капотом» и разбирается каждый шаг. Отдельно рассматриваются варианты работы Kube-Proxy: IPtables, IPVS и KernelSpace.

Integration of Software Supply Chain Security Всем привет! В приложении можно найти материал от NIST – «Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines» (~ 37 страниц). Важно(!): материл представляет из себя initial public draft и не является завершенным документом. Внутри можно найти: 🍭 SSC Security: Risk Factors and Mitigation Measures 🍭 CI/CD Pipelines: Background, Security Goals 🍭 Integrating SSC Security Into CI/CD Pipelines В целом ничего революционного, но вполне полезно. Достаточно много посвящено аттестации для Environment, Process, Materials и Artifacts. Материал может дополнить вашу коллекцию наработок по теме защиты цепочки поставки ПО ☺️

DevSecOps Assesment Framework Всем привет! С началом первой осенней недели вас! По ссылке доступен репозиторий с открытой частью нашего фреймворка оценки процесса безопасной разработки. По своей сути это набор инструментов, правил и процессов, которые помогают создавать безопасное ПО, а физически - excel-файл с 4 вкладками: 🍏 Модель технологии — это набор технологий, связанных с безопасной разработкой. Они распределены по доменам и уровням зрелости. 🍏 Модель процессы — это набор практик безопасной разработки, которые тоже распределены по доменам и уровням зрелости. 🍏 Пиратская карта — взгляд сверху на два этих набора. 🍏 Тепловая матрица — инструмент визуализации того, насколько каждая из практик выполняется у вас. Как этим пользоваться? Самое простое — заполнить модель технологии и модель процессы, после чего увидеть результат на тепловой матрице. Можно заполнять таблицы как для компании целиком, чтобы получить "среднюю температуру", так и для каждой команды разработки отдельно для более точного результата. Мы вышли с этим в open source, поэтому мы будем рады любым вопросам, комментариям и предложениям. Предлагаем вам поиграть с фреймворком, создать пару-тройку issues и задать нам вопросы :) Welcome!

Анонс перед выходными Всем привет! Готовы к перевороту календаря? Мы тоже долго готовились и наконец объявляем: 3 сентября мы выходим в open source с нашей методикой оценки безопасной разработки - DAF, он же DevSecOps Assesment Framework. Фреймворк представляет собой описание набора инструментов и процессов, которые помогают создавать безопасное ПО. По ссылке в GitHub будет доступно 3 раздела нашего фреймворка: 🍏 Модель технологии — это набор технологий, связанных с безопасной разработкой. Они распределены по направлениям и уровням зрелости. 🍏 Модель процессы — это набор практик безопасной разработки, которые тоже распределены по направлениям и уровням зрелости. 🍏 Пиратская карта — взгляд сверху на два этих набора. Следите за новостями в канале, в понедельник будет пост об этом. Прекрасных вам выходных!

Netassert: проверка сетевой связности k8s Всем привет! При помощи Netassert можно проверить сетевую связность между разными ресурсами Kubernetes (Pod, Deployment, DaemonSet и т.д.), а также возможность их взаимодействия с удаленными хостами. Можно реализовать тесты как TCP, так и UDP-трафика. Хорошо это или нет, но конфигурация тестов представляет из себя *.yaml-файлы, примеры которых можно найти в repo. Состоит утилита из трех основных компонентов: 🍭 Engine: управление тестами 🍭 Packet-sniffer: используется во время UDP-тестов 🍭 L4-Client: используется как во время TCP, так и во время UDP тестов Детально описание процедуры запуска, примеры тестов и описание того, что происходит «под капотом» можно найти в repo проекта.

Software Supply Chain Security: Leadership Compass Всем привет! В приложение доступен отчет, в котором сравниваются несколько решений, автоматизирующих безопасность Software Supply Chain. Интересно не само сравнение, а критерии, по которым его проводили и взгляд на то, «что есть Software Supply Chain Security». Рассматриваются блоки: 🍭 Source Code Integrity 🍭 Build Integrity 🍭 Vulnerability Management 🍭 Visibility and Reporting 🍭 Other Security 🍭 Integrations with Software Supply Chain Tools 🍭 Innovative Capabilities «Раскрытие» пунктов и какой именно функционал требуется – все это есть в отчете.

OWASP: Wrong Secrets Всем привет! В 2022 году был выпущен проект от OWASP, посвященный некорректному хранению секретов. Своеобразная игра – «Найди их все!», которая позволит лучше понять проблематику и способы ее устранения. На момент выпуска было всего 12 «заданий». Хорошие новости! Их стало больше! На текущий момент доступно целых 35! При этом появилась вариативность – некоторые из заданий можно запускать локально, для каких-то требуется Kubernetes и даже облачные технологии не обошли стороной. Обо всем этом можно прочитать в repo проекта. Кстати, набор можно использовать в качестве benchmark для тестирования Secret Detection решений. Для этого есть специальная issue, в которой описано, какие именно секреты (по типам) есть в repo, но не указано «где» 😊

Управление секретами в Kubernetes Всем привет! По ссылке доступна неплохая обзорная статья, посвященная использованию секретов в Kubernetes. В начале Автор рассматривает возможные варианты передачи необходимой информации приложению – через file или через env. Проводит небольшое сравнение этих подходов, указывает на их плюсы и минусы. Далее – размышления о Secrets Source of Truth, в том числе при миграции из одного кластера в другой. Упоминаются Mozilla SOPS и Bitnami Sealed Secrets. Однако, этого может быть недостаточно, поэтому можно рассмотреть Secret Management системы. Для Secret Management Автор рассматривает способы «доставки» секретов приложению: 🍭 API или SDK 🍭 Secret Agent / Sidecar Injection 🍭 Secrets Operator 🍭 Secrets Store CSI Приводится описание сильных и слабых сторон каждого способа, а также их особенности. В завершении – размышления про автоматическое обновление секретов. Информация в статье отлично структурирована и содержит все необходимое для начала изучения.

#экспертиза #обзор «Контейнерная оркестрация на отечественном»: митап прошел, а знания остались Достаточно ли одного Kubernetes для запуска современного приложения в продуктивном окружении? Если вы по каким-то причинам не попали на наше мероприятие, а вопрос для вас актуален, то смотрите запись митапа на нашем YouTube-канале. Наши эксперты знают, с какими отечественными платформами на основе k8s не страшно идти в продуктив, как они устроены и как выглядят вживую. 🔹Как эффективно запустить современное приложение в продуктивном окружении? 🔹Какое платформенное решение нужно разработчикам сегодня? 🔹Какие российские платформы контейнерной оркестрации выбирать Enterprise-компаниям?

Привет, друзья! Мы продолжаем собирать и изучать статистику в мире DevSecOps и поэтому созрел новый опрос: Используются ли у вас плагины SAST \ SCA в IDE?
Anonymous voting

Утечки секретов в CI/CD Всем привет! Про эту тему говорят много и часто. Наверное, можно даже посоревноваться в том, кто сколько способов «печати» секретов в log процесса сборки может придумать. Некоторые из таких способов представлены в небольшой статье от Truffle Security (авторы Trufflehog). Но не с целью научить как можно «выводить» секреты, а для того, чтобы показать, что это возможно. В статье, в том числе, рассматриваются способы «обхода» маскирования, предлагаемого некоторыми CI-системами. В завершении можно найти рекомендации о том, что же делать, чтобы этого не случилось – ротация секретов, управление их привилегиями, анализ логов на наличие чувствительной информации и не только.

Workload Security Evaluator Всем привет! В статье описан подход DataDog к тестированию настроек безопасности средств защиты сред контейнерной оркестрации. За основу ребята взяли материал от Atomic Red Team – open source библиотеки, содержащей информацию о тестах, связанных с матрицей MITRE ATT&CK. Выбрали те, что подходят для контейнеров, например: 🍭 Linux Download File and Run 🍭 Port Scan Nmap 🍭 Shared Library Injection via /ect/ld.so.preload 🍭 Cron – Add script to all Cron Subfolders 🍭 Clear Bash History (rm) И автоматизировали их, после чего поместили в образ контейнера. Далее все просто – запускаете этот образ и получаете информацию о том, что получилось реализовать, а что – нет. Увы, материал не «полностью» открыт: можно попробовать воспроизвести с использованием наработок DataDog, но для этого потребуется API_KEY, который можно получить бесплатно на 14 дней. Альтернативный вариант – собрать самому себе что-то похожее и использовать для тестирования runtime ИБ-политик.

LogLicker: анонимизация журналов событий Всем привет! Бывает, что нужно отправить кому-нибудь log-файл. Например, производителю какого-либо решения, партнеру, в-еще-один-telegram-чат... И не всегда хочется делиться полной информацией, а «затереть» что-то, что не влияет на суть, но может быть конфиденциальным. Если похожие мысли посещали и Вас, то рекомендуем обратить внимание на проект LogLicker. Он был разработан для анонимизации журналов событий AWS CloudTrail, но можно научить работать с иными журналами. Он умеет: 🍭 Идентифицировать чувствительную информацию в логах (привет, regexp! 😊) 🍭 Заменять чувствительную информацию в логах на нечто схожее, но не имеющее сути 🍭 Собирать данные о «заменах», чтобы можно было все вернуть в исходное состояние Управляется все при помощи замены регулярных выражений на те, что нужны Вам. Подробнее про утилиту можно прочесть на GitHub и в этой статье.

Декларативное управление конфигурацией узлов Kubernetes в масштабе ❔Изменять конфигурацию узла Kubernetes нужно не только в момент создания кластера, но и при его обновлениях или изменениях в инфраструктуре. Хорошо, если узлы можно автоматизированно пересоздать или изменить без перезагрузки узла. А что делать, если такой возможности нет или количество узлов в кластере переваливает за сотню? ✅Ребята из «Лаборатории Числитель» – российского разработчика ПО – рассказали про распространенные варианты управления конфигурацией кластеров с помощью Ansible, Cluster API, OpenShift Machine Config и свой оркестратор «Штурвал». Все подробности в посте на Хабре.

Building stuff with the Kubernetes API Всем привет! По ссылке доступна подборка статей на тему «программного общения» с Kubernetes. При этом не только с использованием Golang 😊 Доступны следующие статьи: 🍭 Exploring API Objects 🍭 Using Java client framework 🍭 Using the Python client framework 🍭 Using the Go client framework Первая статья объясняет концепты API-объектов Kubernetes. Все описывается с использованием примеров и большого количества комментариев Автора. Последующие статьи демонстрируют как можно, используя языки программирования, «общаться» с kube-apiserver: начиная от создания простейшего client и заканчивая простейшими операциями с ресурсами Kubernetes. Подборка может быть полезна для тех, кто только погружается в мир Kubernetes-разработки и думает о создании своего operator 😊

Repost from KazDevOps
Кажется, что чем больше кластеров, тем лучше, поскольку Kubernetes предназначен для решения проблем, с которыми мы все сталки
Кажется, что чем больше кластеров, тем лучше, поскольку Kubernetes предназначен для решения проблем, с которыми мы все сталкиваемся. Это действительно оптимизирует операции, ускоряет доставку, повышает ежедневную скорость развертывания и т. д. Но что может пойти не так? Несмотря на популярность DevSecOps и разговоры о нем, проблемы безопасности редко решаются правильно. Лучшие практики безопасности Kubernetes за 5 шагов помогут избежать многих проблем. 👉 Об этом и рассказываем в новой статье. #devops #devsecops #kubernetes @DevOpsKaz

Fluid Attacks: требования по ИБ при разработке ПО Всем привет! Название поста не совсем корректно. Сама по себе Fluid Attacks представляет из себя платформу для управления уровнем ИБ разрабатываемого приложения – та самая «единая точка» сбора данных для дальнейшей работы. Но! Если посмотреть на ее документацию, то можно собрать и/или расширить собственный check list с требованиями по ИБ. Внутри можно найти сгруппированные наборы требований для: 🍭 Credentials 🍭 AuthN/Z 🍭 Session 🍭 Files 🍭 Logs и не только Каждая группа содержит несколько рекомендаций и краткое описание того, зачем это нужно. Перечень является достаточно «объемным», возможно что-то Вам пригодится ☺️