Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов. Под практикой подразумевается набор мер, который может быть  встроен в один из этапов SDLC/DevOps (Threat modeling, SAST, DAST, SCA, Docker image scanning, Kubernetes scanning, AWS Audit и так далее). Dev Threat Modeling Статический анализ приложений на уязвимости (SAST) Проверка open-source компонент - SCA Поиск секретов Динамический анализ приложений на уязвимости (DAST) Тестирование по принципам Behaviour Driven Development Сканирование образов Docker Ops Kubernetes Security Vulnerability Management Public Cloud Security И это еще не все?  Моделирование угроз в контексте Secure Development Lifecycle представляет из себя процесс анализа архитектуры ПО на предмет наличия в ней потенциальных уязвимостей и небезопасных технологий. Чтобы сократить расходы на добавление дополнительного функционала с точки зрения безопасности, решением может являться внедрение процесса проверок ИБ еще на этапе проектирования архитектуры. На этом же этапе формируются требования со стороны специалистов по безопасности приложений, которые в дальнейшем пойдут в backlog. Подобный подход прибегается, на самом деле, во всех практиках DevSecOps и получил устойчивое выражение “Shift security to the left”.  Чтобы данный процесс нашел место в современной разработке при высокой скорости выхода релизов в крупной IT-компании, процесс моделирования угроз должен быть также автоматизирован. Вот некоторый пул open-source инструментов, которые могут помочь. Ссылка на OWASP Threat Dragon  Довольно простой инструмент для самостоятельного моделирования угроз. Пользователь отрисовывает архитектуру ПО, указывая на ней угрозы, которые могут следовать по методологии STRIDE. Никакой автоматизации, но в классическом варианте, когда процессы отлажены, может быть полезно. Это инструмент в частности используется для моделирования угроз в GitHub. Ссылка на Pytm Pytm - фреймворк на Python для создания диаграмм потоков данных и списка угроз системы. Пользователь Pytm задает модель взаимодействия компонентов в архитектуре в виде кода, после чего инструмент самостоятельно формирует схемы взаимодействия компонентов. Может быть полезно для совместной работы и использовании в системе отслеживания версий.  Ссылка на Materialize threats tool  Materialize-threats - фреймворк на Python, который позволяет конвертировать схемы архитектуры ПО из сервиса draw.io в графы, сохранить их в базу и в дальнейшем работать с утверждениями относительно этих графов при помощи SQL запросов. Помимо этого инструмент умеет формировать тесты на Gherkin. Это любопытный open-source инструмент, который хорошо описывает то, куда двигаются современные Enterpise-решения по моделированию угроз вроде Irius Risks. Сценарий работы с ним следующий: Создание диаграммы взаимодействия компонентов в .drawio, согласно вашему data flow Выделение доверенных зон на диаграмме, согласно Rapid Threat Model Prototyping methodology(в readme есть пояснение) Сохранение файла .drawio Запуск materialize.py с импортом файла .drawio Получение сценария реализации угроз в формате Gherkin.   Не будем долго останавливаться на других инструментах ибо принцип работы везде похожий. Вот еще несколько open-source инструментов по части моделирования угроз: Threatspec Raindance  Microsoft Threat Modeling Tool Большая подборка по моделированию угроз, включая статьи, инструменты, курсы, книги: Awesome threat modeling Переходим к этапу тестирования, а именно статическому анализу кода . Анализаторов кода существует огромное количество. Open-source инструменты, в свою очередь, выделяются тем, что они написаны под какой-то конкретный язык. Большое количество инструментов можно найти в следующих подборках: OWASP Source Code Analysis Tools Static Analysis Tools  Но есть и несколько довольно любопытных инструментов, которые могут быть применены универсально. Ссылка на Salus Образ контейнера, в который помещено сразу несколько статических анализаторов, вроде Bandit, Gosec, Brakeman, а также анализаторы open-source компонентов (Ruby,Node.js, Python,Go). Запускается это следующим образом: На выходе получаем JSON/YAML отчет. На GitHub также можно найти описание встраивания в CircleCI. Ссылка на ShiftLeft Scan Инструмент работает по аналогии с Salus, но с поддержкой большего количества статических анализаторов. В репо можно посмотреть те статические анализаторы, которые были помещены в docker образ (gosec, find-sec-bugs, psalm, bandit, …). В образ Docker поместили даже анализаторы terraform, bash, kubernetes манифестов. Пример запуска статического анализа Python проекта: Более того, к инструменту есть интеграция с IDE. Ссылка на описание SAST в GitLab Gitlab является довольно популярной DevOps платформой, но что еще в ней есть, так это бесплатный набор разных open-source SAST, которые можно подключить из коробки в пайплайн. В Gitlab также есть возможность встроить SCA, поиск секретов, fuzzing и другие практики DevSecOps, но централизованное управление всеми средствами будет доступно только в Gold-версии. Ссылка на LGTM  LGTM - облачная платформа для сканирования кода от компании Semmle, которая в конце того года стала частью GitHub. Semmle также являются автором CodeQL, применение которого было анонсировано GitHub на своей онлайн-конференции Satellite. Ссылка на облачную версию Semgrep Уникальный проект, про который хотелось бы написать отдельную статью. По сути это не столько статический анализатор кода на наличие уязвимостей, сколько фреймворк, под капотом которого находится AST и Data flow, который можно использовать по разным назначениям. Например, можно сформировать следующий запрос: Конфигурационный файл для semgrep пусть будет следующим: В результате Semgrep будет находить инъекции вроде тех, что отображены ниже на скриншоте (желтым отмечены те строки, которые semgrep посчитал уязвимыми): Примечание. На мой взгляд, большой проблемой во многих open-source инструментах, особенно в SAST, так это отсутствие унификации по части вывода результатов. Очень малая часть этих инструментов предоставляет CWE к найденным срабатываниям, из-за чего возникают проблемы на уровне менеджмента уязвимостей. На текущий момент все коммерческие решения, которые я знаю, приводят результат найденных уязвимостей к CWE и CVE. Наряду с тем кодом, разработка которого выполняется внутри команды, необходимо также проверить open-source, который подключается к проекту. Отсутствие процесса анализа сторонних компонент на наличие уязвимостей может существенно повлиять на безопасность продукта (как например, это случилось с компанией Equifax). Принципы работы, сравнение популярных инструментов SCA я приводил в отдельной статье, а здесь мы поговорим о том, какие существуют инструменты. Ссылка на Dependency Check Dependency Check - одно из самых популярных open-source решений от OWASP для проверки сторонних компонентов . Существует большое количество готовых интеграций, способов встраивания в пайплайн, но у инструмента есть куда развиваться в сторону качества. Рекомендуется к внедрению для компаний, где процессы Secure SDLC находятся на начальных этапах и у специалистов со стороны ИБ есть время для разбора ложных срабатываний. У Dependency Check нет единой платформы, в которой можно отслеживать результаты в ретроспективе, поэтому, если процессы менеджмента уязвимостей в организации не выстроены, стоит обратить внимание на Dependency Track. Ссылка на сайте Dependency Track Dependency Track - второе по популярности решение от OWASP, которое представляет из себя веб-платформу, принимающую на вход Software bill of materials (SBOM) от другого инструмента CycloneDx. Dependency Track исследует BOM, после чего обращается в общедоступные базы данных уязвимостей, например, NVD. Инструмент имеет также возможность интегрироваться со Slack, Microsoft Teams, сканировать репозитории артефактов и проверять сторонние компоненты на лицензионную чистоту. Ссылка на официальном сайте Snyk Open-source Компания Snyk кроме того, что развивает свою коммерческую платформу для сканирования open-source компонентов в проектах, также предоставляет бесплатную версию в виде SaaS-решения. Проекты можно подгружать как через репозиторий (GitHub, Bitbucket), так и через CLI. Как может выглядеть сканирование snyk для npm: Помимо NVD (основного источника информации об уязвимостях для большинства решений) существует база Sonatype OSS, поддерживаемая компанией Sonatype, у которой также есть коммерческое решение Nexus IQ. Мы, в свою очередь, взяли на вооружение Nexus IQ как основной инструмент SCA для наших заказчиков. Sonatype OSS - база данных уязвимостей, которая может быть подключена инструментами Dependency Check и Dependency Track. Кроме того, Sonatype поддерживает следующие open-source инструменты SCA, которые могут быть использованы для сканирования зависимостей и берут данные из Sonatype OSS: Nexus Vulnerability Scanner - универсальный сканер от Sonatype AuditJS - сканер JS (NPM, Angular, yarn, bower) Nancy - сканер Golang Jake - сканер Conda Chelsea - сканер Ruby Cheque - сканер C/C++ (GCC) Ahab - сканер apt, apk, yum, dnf пакетов Pants - сканер Rust (Cargo) Sonatype Depshield - сканер GitHub проектов Другие материалы по SCA: Большая подборка SCA от OWASP ClearlyDefined  Renovate - бесплатная платформа от White Source Dependabot - бот GitHub для проверки open-source в репозиториях GitHub Проект может содержать не только уязвимости, которые были допущены в собственном коде и open-source компонентах, но секреты вроде паролей, токенов, закрытых ключей. Разумеется, если в коде содержится открытый пароль от критически важной базы данных, допускать его в репозиторий нежелательно. С этой целью существует ряд инструментов, которые могут помочь отыскать открытые секреты. Здесь мы не будем долго останавливаться, ибо принцип работы везде одинаковый. Ссылка на официальном сайте git-secrets Ссылка на gitrob Ссылка на gitleaks Также есть в виде Github-action.  Ссылка на TruffleHog TruffleHog - самый известный инструмент в сообществе, осуществляющий поиск секретов как по регулярным выражениям, так и прибегая к оценки энтропии методом Шеннона. Ссылка на GitGuardian SaaS платформа для поиска секретов. Есть также коммерческая on-prem версия. В России не продается. Примечание. Для хранения секретов и сокрытия их в исходном коде и конфигурационных файлах необходимо использовать решения класса Password Vault (HashiCorp Vault, conjur, …) Ссылка на Arachni Одно из моих любимых open-source решений, в первую очередь за свою точность. Есть возможность развертывания в виде Docker-контейнера, CLI и веб-интерфейса. Жаль, что решение перестало поддерживаться разработчиками. Результаты выводятся в CWE-формате. Способ сканирования через Docker: После развертывания контейнера, запуск сканирования и выгрузка отчетов происходит через REST API по порту 7331 в виде json. Ссылка на OWASP ZAP Одно из самых популярных open-source решений, которое может быть встроено в CI/CD.  Имеет свой GUI, может быть развернуто в виде CLI или docker-контейнера. Также есть режим работы в виде прокси.  Есть даже кастомные сценарии развертывания в виде Kubernetes-оператора. Кроме того, оно очень быстрое. Проект, который Arachni анализирует 10 минут, ZAP может просканировать за пару минут, однако за такую скорость приходится, как правило, платить не самым точным результатом. Ссылка на w3af Несмотря на то, что инструмент давно не обновляется и не обозревается аналитиками (например, наиболее свежий обзор в журнале Хакер датируется 2012 годом (https://xakep.ru/2012/11/09/w3af-pentest/)), тем не менее есть официальный docker-контейнер и инструкции по встраиванию сканера в CI/CD Вот например, автор встроил разные open-source решения по безопасности в пайплайн Jenkins на AWS, включая w3af. Пример сканирования через docker: Примечание. Динамический анализ бывает не только для веб-приложений. Более полный список можно увидеть здесь. Стоит отметить про отдельный класс решений для динамического сканирования мобильных приложений, open-source инструментов и enterprise, которых весьма мало. Мы в частности занимаемся разработкой собственного инструмента DAST для мобильных приложений. Behavioral Driven Development (BDD) (или “разработка через поведение”)- подход в разработке ПО, который произошел от Test Driven Development (TDD) (“разработка через тестирование”). Несмотря на том, что эти подходы, как итог, стали применяться для разных целей и использовать разные инструменты, их применение можно найти и в сфере безопасности. Основная концепция BDD в описании пользовательских сценариев тестирования с помощью человеко-читаемоего языка  Gherkin. Посмотрим, как это выглядит сразу на примере инструментов. Ссылка на Gauntlt Guantlt - фреймворк, использующий концепцию Behavioral Driven Development. Он автоматизировать сканирование с помощью различных инструментов и позволяет описать Arachni, nmap, sslyze, sqlmap и другие инструменты на языке Gherkin.  Таким образом, Guantlt может стать “мостиком” между командами разработки, безопасности и менеджмента.  Примечание.  Аналогом Guantlt является BDD-Security, который в поддерживаемых инструментах имеет также OWASP ZAP, Tenable Nessus Scanner. В силу того, что команды разработки все чаще стали прибегать к варианту развертывания через Docker (да и в принципе Docker стал важной частью DevOps), нельзя не сказать про сканеры Docker-образов как отдельный класс решений. Отдельно стоит отметить, что основное сравнение инструментов мы приводили в статье в нашем блоге, с которой можно ознакомиться здесь. Пройдемся по некоторым из инструментов. Ссылка на Clair Инструмент для проверки слоев образа на общедоступные CVE уязвимости. У инструмента отсутствует из коробки UI для работы, поэтому необходимо подключать сторонние инструменты вроде Klar. Ссылка на Klar Утилита для взаимодействия с API Clair. Ссылка на Trivy Trivy находит уязвимости сборок ОС (поддерживаются Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) и проблемы в зависимостях (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock) В отличие от Clair умеет сканировать как в репозитории, так и локально, или на основании переданного .tar файла с Docker образом. Ссылка на Anchore Популярный инструмент для сканирования образов Docker. Есть возможность работы через REST API или CLI. Ссылка на AquaMicroscanner Инструмент от Aqua Security, который развивается параллельно вместе с Trivy.  Примечание. Сравнение инструментов по сканированию образов на общедоступные CVE можно почитать здесь: Testing docker CVE scanners. Part 1: false negatives and what they mean for your security Testing Docker CVE Scanners. Part 2: How good is package detection? Testing docker CVE scanners. Part 2.5 — Exploiting CVE scanners Testing Docker CVE scanners. Part 3: Test it yourself / Conclusions Ссылка на Dagda Dagda выделяется тем, что имеет под капотом Dependency Check, Retire.js и ClamAV для поиска вредоносных программ. Ссылка на Docker Bench Docker bench - инструмент для compliance-проверок как образов, так и контейнеров и хостов. Основной набор проверок строится на базе документа CIS Benchmarks для Docker.  Ссылка на Dockle  Инструмент для выполнения compliance-проверок, в том числе, выходящих за рамки CIS. Переходим на этап Deploy. В случае с Kubernetes, помимо образов Docker, необходимо также проверять настройки Kubernetes в силу того, что Kubernetes по умолчанию развертывается в менее безопасной конфигурации для большего удобства начинающих пользователей. Дополнительный материал для расширения подборки: My Arsenal of Cloud Native (Security) Tools by MARCO LANCINI Ссылка на Kube-bench Еще один (и не последний) инструмент от компании Aqua Security. Инструмент выполняет проверки CIS Kubernetes Benchmark для развернутых рабочих нагрузок Kubernetes (в том числе GKE, EKS and AKS) Для разных сценариев желателен разный вариант запуска команд: Ссылка на Kubernetes Auto Analyzer Инструмент работает по тому же принципу, что и Kube-bench, но в отличие от него перестал поддерживаться. Сами авторы инструмента предлагают продолжить пользоваться Kube-bench от Aqua Security. Ссылка на Kube-hunter Инструмент для имитации тестирования на проникновения Kubernetes. Может быть запущен на сервере кластера, внутри контейнера или на удаленном компьютере с указанием IP-адреса / доменного имени кластера Kubernetes.  Ссылка на KubiScan Инструмент для проверки выданных разрешений RBAC-модели Kubernetes.  Кстати, проверке выданных разрешений посвящена отдельная неплохая статья на сайте CyberARK. Ссылка на Krane  Инструмент, выполняющий статический анализ RBAC за счет индексации объектов RBAC в RedisGraph. Управление рисками RBAC происходит через настройку политик. Krane может работать как CLI, docker-контейнер или автономная служба для непрерывного анализа, а также быть встроенным в CI/CD. Ссылка на Starboard Инструмент, позволяющий нативно интегрировать инструменты безопасности в среду Kubernetes благодаря CustomResourceDefinitions (CRDs) для работы с такими инструментами как trivy,  kube-bench,  kube-hunter.  Starboard предоставляет также kubectl-совместимый инструмент командной строки и плагин Octant, который делает отчеты о безопасности доступными через знакомые инструменты Kubernetes. Ссылка на Kubeaudit Еще один инструмент, выполняющий проверки Kubernetes. Ссылка на Kubesec Последний легковесный инструмент для проверки Kubernetes в этой подборке. Ссылка на Deepfence Runtime Threat Mapper Бесплатная community-версия комплексного решения по защите облачных нагрузок. Платформа отображает рабочие нагрузки на графе, ищет аномалии в поведении с помощью агентов сканирования, интегрируется с CI/CD для сканирования образов, а также выполняет поиск уязвимостей образов в заданном Registry. Также есть интеграция с SIEM, Slack, Jira, Amazon S3 (неполный список интеграций). Ссылка на Sysdig Falco Бесплатная версия решения для защиты в режиме run-time от Sysdig, хорошо себя зарекомендовавшая в сообществе.  Можно выполнять огромное количество различных сканирований инструментами SAST, DAST, SCA, анализаторами образов Docker и конфигурации Kubernetes, но без правильно построенного процесса управления выявленными уязвимостями и распределения ответственных процесс устранения выявленных дефектов может очень сильно затянуться. Решения класса Vulnerability Management призваны помочь в этом вопросе. Как правило, это единая точка входа всех выявленных уязвимостей посредством взаимодействия через API или при помощи веб-интерфейса с целью дальнейшей визуализации и экспорта структурированной информации в дефект-трекинг. Мы в своих практиках используем коммерческое решение собственной разработки AppSec.Hub, которое помимо управления уязвимостями, умеет также создавать и экспортировать готовые DevSecOps-пайплайны в CI/CD системы. Но в этой статье мы коснемся только open-source решений. Ссылка на DefectDojo Решение для управление уязвимостями от OWASP. Есть много интеграций (22+) как с open-source сканерами (ZAP,  Trivy, nmap, Dependency Check), так и с enterprise (Veracode, Checkmarx, Twistlock). Как правило, имеет некоторые сложности при интеграции с API. Вот здесь можно увидеть пример скрипта для интеграции. Ссылка на Secure code box Open-source фреймворк, объединяющий несколько бесплатных инструментов сканирования (ZAP, NMAP, Nikto, Arachni), собранных вместе в docker-compose в связке с Kibana и Elasticsearch.  В отличие от того же DefectDojo, здесь все инструменты  развертываются вместе с решением, и отчеты о результатах сканирования подтягиваются самостоятельно (не нужно писать скрипты для автоматической отправки issue в сборщик). Также можно запускать сканирование всех заявленных инструментов из UI. На текущий момент инструменты направлены исключительно на тестирование веб-приложений. Несмотря на кажущуюся простоту развертывания и работы,  разработчики заявляют,  что это не one-button-click-solution и требуется глубокое понимание для настройки сканеров. Ссылка на Archery Еще одна open-source система управления уязвимостями. Есть поддержка Acuntetix, Nessus, Burp, Netsparker, WebInspect. В отличие от DefectDojo, о котором я упоминал ранее, решение позволяет запускать из консоли сканирование ZAP, Burp и OpenVAS. Из интересного то, что есть обработчик false positive. Ну и конечно же интеграция с CI/CD. Еще материал по vulnerability management: Faraday VulnReport  Сравнение инструментов   Говоря про безопасный DevOps нельзя не сказать про безопасность облачных провайдеров (AWS, GCP, Azure, Oracle) в силу активного перехода из on-prem в облака.  В этой подборке мы захватим лишь малую часть инструментов, посвященных безопасности публичных облаков. Подборка и приведенные инструменты не учитывают также сервисы, предоставляемые облачными провайдерами, которых также немало. Ссылка на AWS-inventor Инструмент для инвентаризации активов AWS с помощью заданных параметров учетной записи AWS. Ссылка на AWS-puclic-ips Инструмент для получении информации об общедоступных ресурсах AWS в виде ip-адресов. Ссылка на CloudSploit Инструмент для compliance-проверок публичных облаков AWS, GCP, Azure, OCI. В частности, можно провести проверку на CIS и PCI DSS. Ссылка на AWS Security Benchmark Отдельный инструмент для проверки AWS на соответствие CIS Amazon Web Services Foundations Benchmark 1.1. Ссылка на S3 Scan Инструмент, формирующий отчет обо всех S3-корзинах и установленных для них ролях. Примечание. Наверное, самая большая подборка инструментов по AWS Security: My-arsenal-of-aws-security-tools Ссылка на G-Scout Инструмент, формирующий отчет о проблемах с безопасностью GCP. Ссылка для ScoutSuite Популярный инструмент для проведения аудита безопасности публичных облаков GCP, AWS, Oracle, Azure.  Подборку продолжать можно еще долго, но я постарался привести все, что может стать отправной точкой в процессе выстраивания безопасности DevOps/SDLC. Тем не менее, это далеко не все практики. Я не коснулся также этапов фаззинга, управления секретами и процесса проверки манифестов IaC. И разумеется, правильно построенный процесс разработки не может существовать без организационных мер и налаженных отношений между командами разработки и безопасности. Здесь я могу порекомендовать познакомиться с моделями оценки BSIMM и OWASP SAMM. Чтобы охватить уже точно все, приведу также несколько подборок для самостоятельного разбора. RASP - практика, при которой инструмент безопасности интегрируется напрямую с сервером, отслеживая его работу (обращения к базе данных, файловые операции, сетевые запросы и тд.). Часто к этой практике относят инструменты класса Container Run-time Security (например Sysdig Falco). Вот также RASP для отслеживания работы веб-приложений: OpenRASP IAST - практика, совмещающая принципы работы SAST и DAST: Contrast Fuzzing - практика тестирования приложения, при которой на вход программе подаются данные, которые могут привести к неопределенному поведению : Awesome Fuzzing  IaC Security - практика тестирования декларативного описания инфраструктуры через конфигурационные файлы на соответствие требования безопасности:  Cfn Nag - Сканер AWS CloudFormation шаблонов на небезопасную конфигурацию  Checkov - Сканер Terraform, AWS CloudFormation и Kubernetes шаблонов на небезопасную конфигурацию Terrascan - Сканер Terraform шаблонов на соответствие лучшим практикам безопасности Tfsec - Сканер Terraform шаблонов на неправильную конфигурацию и несоответствие лучшим практикам безопасности AWS, Azure и GCP. Kubernetes YAML validating: Kubeval Kube-score Config-lint Copper Conftest Polaris Сравнение инструментов Compliance-as-code - практика представления требований безопасности через декларативное описание в виде кода с целью дальнейшей непрерывной оценки на соответствие: Chef InSpec Compliance Masonry OpenSCAP Security Chaos Engineering - молодая практика, основанная на нескольких принципах: определение "стабильного" состояния, создание гипотезы о последующем состоянии, введение переменных, осуществление попыток "сломать" гипотезу. После серии тестов инфраструктура оценивается на предмет доступности, безопасности и производительности. Как итог цель всего этого - получить систему, способную выдерживать экстремальные условия. Security Chaos Engineering отличается от классического Chaos Engineering лишь гипотезами, касающимися безопасности. Тесты могут состоять, например, из отключения правил Security Groups,  изменения файлов случайным образом, прослушивания портов, внедрения вредоносного трафика в VPC, случайного "убийства" процессов. При этом все это должно быть автоматизированно, а состояния системы должны непрерывно отслеживаться. Примеры инструментов: ChaoSlingr Security Monkey Kube-monkey Каналы и чаты по DevSecOps и безопасности приложений: DevSecOps Wine - канал по DevSecOps от автора статьи DevSecOps Wine Chat - новый част к каналу выше CloudSec Wine - канал про Public Cloud Security от автора статьи Mobile AppSec World  - канал о безопасности мобильных приложений DevSecOps русскоговорящее сообщество  UPD.  Так как было очень много восторженных отзывов, решил расширить подборку в виде Awesome DevSecOps на русском, включив статьи и доклады: Awesome DevSecOps на русском языке Head of AppSec