Консалтинг DevSecOps
DevSecOps — подход, при котором проверки безопасности — обычная, по возможности автоматическая часть конвейера поставки ПО (CI/CD-пайплайна) и эксплуатации. Мы встраиваем в процесс поставки сканирование кода, зависимостей и контейнеров, управление секретами (паролями, API-ключами, сертификатами и другими конфиденциальными данными доступа) и проверки конфигурации облака, чтобы находки были видны и отслеживались уже при разработке.
- Фокус
- Безопасность пайплайнов, цепочка поставок ПО, контейнеры и IaC, управление секретами, конфигурация облака
- Среды
- Публичное облако, локальные облачные провайдеры, ЦОД, гибридные среды
- Ориентиры
- OWASP SAMM, NIST SSDF, SLSA, CIS
- Первый шаг
- Бесплатная первичная консультация или бесплатная оценка с фокусом на безопасности
Когда нужен DevSecOps?
Чем раньше обнаружена проблема безопасности, тем проще её исправить. Поэтому мы переносим проверки ближе к началу процесса разработки и встраиваем их в него.
- Тестирование безопасности проводится разом перед релизом. Если находки видны раньше и небольшими порциями, график релизов соблюдать проще.
- Пароли и ключи хранятся в разных местах. Пароли и ключи доступа нужно держать в централизованном хранилище секретов, отслеживать доступ к ним и регулярно их обновлять.
- Анализ влияния новой уязвимости занимает много времени. Актуальный перечень (SBOM), показывающий, какие версии компонентов работают в каком приложении, сокращает это время.
- Облачные аккаунты со временем разрослись. Права доступа, сетевые правила и настройки журналирования нужно проверить на соответствие стандарту.
- Подготовка свидетельств для аудита и заказчиков отнимает время. Когда проверки выполняются автоматически, а их результаты сохраняются, свидетельства становятся побочным продуктом повседневной работы.
- Корпоративные заказчики спрашивают, из чего состоит ваше ПО. Всё чаще от вас ждут документированного списка используемых компонентов с открытым кодом и их состояния безопасности.
Что мы делаем в рамках DevSecOps?
Направления от разработки до эксплуатации, которые делают проверки безопасности автоматическими и измеримыми.
Безопасность конвейера поставки
Анализ кода (SAST) и зависимостей (SCA) при каждом изменении, динамические тесты (DAST) по расписанию; находки — в инструментах разработчика.
Безопасность контейнеров и IaC
Сканирование и подпись образов, проверка подписи при деплое; выявление ошибок в настройках Terraform и Kubernetes до релиза.
Управление секретами и доступом
Перенос паролей и ключей в централизованное хранилище, их регулярная автоматическая ротация, доступ по принципу минимальных привилегий.
Безопасная конфигурация облака
Анализ структуры аккаунтов и сетевой архитектуры, усиление защиты по рекомендациям CIS Benchmarks и непрерывный аудит конфигурации.
Безопасность цепочки поставок ПО
Перечень компонентов (SBOM) для каждого релиза, подписанные релизы и записи о том, где и как собран релиз (provenance), по фреймворку SLSA.
Мониторинг и реагирование на инциденты
Сбор логов безопасности, значимые оповещения и мониторинг среды выполнения; шаги реагирования — в регламентах эксплуатации (runbook).
Сначала высокие риски, затем автоматизация.
Начинаем с самых рискованных мест, затем автоматизируем проверки и встраиваем их в ежедневную работу команды. Какие находки блокируют релиз, решаем вместе.
Что мы учитываем?
Мы проектируем проверки, сопоставляя их с признанными фреймворками:
- Модель зрелости OWASP SAMM
- NIST SSDF (SP 800-218): фреймворк безопасной разработки
- Уровни SLSA для цепочки поставок ПО
- OWASP Top 10 и ASVS
- Руководства по усилению защиты CIS Benchmarks
Оценка рисков и текущего состояния
Изучаем конвейер поставки, облачные аккаунты, права доступа и имеющиеся средства защиты.
Результат: Приоритизированный перечень рисков и базовый срез текущих находокПриоритетные исправления
Устраняем находки высокого приоритета: открытые секреты, избыточные права и ресурсы, доступные из интернета.
Результат: Статус исправления и проверки приоритетных находокВстраивание проверок в пайплайн
Добавляем в пайплайны сканирование, политики и контрольные точки качества (quality gates), отсеиваем лишние оповещения.
Результат: Автоматические проверки безопасностиМониторинг и реагирование
Вводим в работу журналы безопасности, оповещения и шаги реагирования на инциденты.
Результат: Правила оповещений, регламенты эксплуатацииНепрерывное улучшение
Регулярно отчитываемся о находках, отслеживаем тенденции и обучаем вашу команду безопасной разработке.
Результат: Отчёты и обучениеЧто остаётся у вас по итогам DevSecOps-проекта.
Проверки работают в вашем конвейере поставки; свидетельства и процессы задокументированы и находятся у вас.
Отчёт о рисках и находках
Приоритизированные находки, их возможное влияние, ответственные и рекомендуемые шаги по устранению.
Шаблоны безопасных пайплайнов
Повторно используемые шаблоны со сканированием, контрольными точками качества, SBOM и подписью.
Система управления секретами
Конфигурация хранилища, политики доступа и процедуры ротации ключей.
Наборы политик
Политики безопасности для Kubernetes и IaC, описанные как код.
Регламенты реагирования на инциденты
Пошаговые процедуры реагирования, коммуникации и отката.
Обучение безопасной разработке
Практические занятия для команд разработки и эксплуатации.
Сначала процесс, потом инструменты.
Мы анализируем ваши текущие инструменты и закрываем пробелы решениями с открытым исходным кодом или корпоративными продуктами.
Тестирование безопасности приложений
- SonarQube
- Semgrep
- CodeQL
- ZAP
- Snyk
- GitLab Security
Зависимости и SBOM
- OWASP Dependency-Check
- Dependency-Track
- Syft
- Grype
Контейнеры, IaC и подпись
- Trivy
- Cosign
- Checkov
- Kyverno
- OPA Gatekeeper
Управление секретами и поиск утечек
- HashiCorp Vault
- AWS Secrets Manager
- Azure Key Vault
- External Secrets
- Gitleaks
- TruffleHog
Мониторинг и обнаружение
- Falco
- Wazuh
- Elastic Security
- Microsoft Sentinel
- OpenSearch
Старт безопасной поставки с учётом вашего масштаба.
Малый и средний бизнес, небольшие команды разработки
Начинают с управления секретами, анализа зависимостей и базового усиления защиты облака; цель — заметный эффект малым набором инструментов.
Команды, работающие с корпоративными заказчиками
Подготовка к вопросам заказчиков о безопасности и к аудитам с помощью SBOM, подписанных релизов и пайплайнов, формирующих свидетельства.
Корпоративные ИТ-подразделения и службы ИБ
Подключение имеющихся средств защиты к конвейеру поставки, политики безопасности как код и общие стандарты для всех команд.
Чтобы первая встреча была продуктивной.
Ничто из этого не обязательно; всё, что у вас есть, сделает первый разговор более предметным.
Что можно подготовить, если есть
- Список репозиториев кода и пайплайнов
- Список облачных аккаунтов и сред
- Используемые средства защиты и результаты последних сканирований, если есть
- Наиболее критичные приложения и типы обрабатываемых ими данных
- Требования к безопасности со стороны аудиторов или заказчиков
О DevSecOps
Источники и стандарты
- OWASP SAMM (откроется в новой вкладке)Модель зрелости безопасности ПО
- NIST SP 800-218 (SSDF) (откроется в новой вкладке)Фреймворк безопасной разработки ПО
- SLSA (откроется в новой вкладке)Фреймворк безопасности цепочки поставок ПО
- CycloneDX (откроется в новой вкладке)Стандарт SBOM
- CIS Benchmarks (откроется в новой вкладке)Рекомендации по безопасной настройке систем
Давайте вместе посмотрим на безопасность вашей поставки.
На бесплатной первичной консультации мы обсуждаем вашу текущую ситуацию и цели, а своим первым впечатлением и возможными следующими шагами делимся на той же встрече.
- Техническая беседа со специалистами по вашей теме
- Первое впечатление о вашей ситуации и возможные подходы
- Если уместно, следующий шаг: оценка, проектное предложение или консалтинг
- При необходимости — соглашение о неразглашении до встречи
- Ответ на запрос в течение 4 рабочих часов
DevSecOps: примеры из практики
На наглядных сценариях показываем, как проверки безопасности работают в конвейере поставки (CI/CD-пайплайне).
Защищённый конвейер поставки
Сканирование секретов, кода, зависимостей и работающего приложения — штатные шаги пайплайна. Находки показываются разработчику прямо в запросе на слияние.
Поиск секретов
До попадания в репозиторий код проверяется на утечки паролей, ключей и токенов.
- $ gitleaks git --staged -v
- ✓ no leaks found
Статический анализ кода (SAST)
Код проверяется на типичные ошибки, такие как SQL-инъекции и небезопасная конфигурация.
- $ semgrep scan --config p/owasp-top-ten
- Ran 512 rules on 284 files: 1 finding.
- ! tainted-sql-string · orders/views.py:88
Анализ зависимостей (SCA)
Компоненты с открытым исходным кодом сверяются с базами известных уязвимостей.
- $ grype dir:. --fail-on high
- jackson-databind 2.13.2 → 2.13.4.1 High CVE-2022-42003
Шлюз качества
Пока находки высокой критичности не устранены, слияние не выполняется; исправление проверяется в том же запросе.
- ! Quality Gate: FAILED
- → fix commit pushed
- ✓ Quality Gate: PASSED
Динамическое тестирование (DAST)
Развёрнутое в тестовой среде приложение сканируется снаружи в рабочем состоянии.
- $ zap-baseline.py -t https://staging.example.local
- FAIL-NEW: 0 WARN-NEW: 2 PASS: 61
- Gitleaks
- Semgrep
- Grype
- SonarQube
- ZAP
Анализ влияния уязвимостей с помощью SBOM
SBOM — это перечень компонентов; сам по себе он не говорит о том, что версия безопасна. Его ценность в том, что при объявлении новой уязвимости затронутые приложения находятся сразу.
Перечень компонентов
Для каждой версии автоматически формируется список пакетов и их версий внутри образа (SBOM).
- $ syft registry.example.local/orders:3.2.0 -o cyclonedx-json > sbom.json
- ✓ Cataloged contents: 412 packages
Централизованный учёт
SBOM собираются на одной платформе; можно узнать, какое приложение использует какую версию компонента.
- PUT /api/v1/bom · orders 3.2.0
- ✓ 412 components processed
Новая уязвимость
Когда для компонента публикуется критическая уязвимость, затронутые проекты выводятся из реестра.
- ! CVE-2021-44228 · log4j-core · CVSS 10.0
- affected: orders 3.2.0 (log4j-core 2.14.1)
- not affected: payments-api, inventory-service
Исправление
Компонент обновляется до безопасной версии, пайплайн запускается снова и формируется новый SBOM.
- log4j-core 2.14.1 → 2.17.1
- ✓ orders 3.2.1 built, scan clean
Закрытие
SBOM новой версии загружается в реестр; запись об уязвимости закрывается, по процессу составляется отчёт.
- orders 3.2.1 · log4j-core 2.17.1
- ✓ CVE-2021-44228 closed
- Syft
- CycloneDX
- Dependency-Track
Подпись образов и проверка при развёртывании
Подпись показывает не то, что образ безопасен, а то, что он получен из ожидаемого пайплайна и после этого не изменялся. Кластер не запускает образ без проверки подписи.
Запись о сборке
Образ собирается в пайплайне; фиксируется, из какого кода и в какой среде он собран (provenance).
- $ docker buildx build --provenance=true --push -t registry.example.local/payments-api:1.9.0 .
Подпись
Образ получает бесключевую подпись, привязанную к идентичности пайплайна; подпись хранится рядом с образом в реестре образов.
- $ cosign sign --yes registry.example.local/payments-api@sha256:9f2c…
- tlog entry created with index: 1048…
- ✓ Pushing signature to: registry.example.local/payments-api
Аттестация SBOM
SBOM прикрепляется к образу в виде подписанной аттестации (attestation).
- $ cosign attest --yes --type cyclonedx --predicate sbom.json registry.example.local/payments-api@sha256:9f2c…
Проверка при развёртывании
В кластер допускаются только образы, подписанные ожидаемой идентичностью; правило применяется на входе в кластер.
- verifyImages: registry.example.local/*
- ✓ payments-api@sha256:9f2c… signature verified
Неподписанный образ
Неподписанный образ или образ с подписью другой идентичности в кластер не допускается; причина фиксируется.
- $ kubectl apply -f test-pod.yaml
- ! admission webhook "mutate.kyverno.svc-fail" denied the request: failed to verify image
- Docker Buildx
- Cosign (Sigstore)
- Kyverno
- SLSA
Управление секретами
Секреты — это конфиденциальные данные доступа: пароли, API-ключи, сертификаты. Они хранятся не в коде и не в файлах конфигурации, а в хранилище секретов с журналированием доступа.
Обнаружение
Секреты, оставшиеся открытыми в репозиториях и файлах конфигурации, находятся и вносятся в список.
- $ gitleaks git --report-path report.json
- ! leaks found: 3
Перенос в хранилище
Секреты переносятся в централизованное хранилище; доступ задаётся по идентичности приложения и принципу минимальных привилегий.
- $ vault kv put secret/payments-api/prod db_host=…
- ✓ Success! Data written to: secret/payments-api/prod
Краткоживущие учётные данные
Приложение получает собственную временную учётную запись в базе данных; по истечении срока она удаляется.
- $ vault read database/creds/payments-api
- lease_duration 1h
- username v-k8s-payments-api-7Hq2…
Ротация
Ключи, которые должны оставаться долгоживущими, автоматически обновляются по расписанию.
- rotation_period: 720h
- ✓ last rotation: 3 days ago
Журнал аудита
В журнале аудита фиксируется, какая идентичность и когда прочитала какой секрет.
- $ vault audit list
- file/ file n/a
- Gitleaks
- HashiCorp Vault
- Kubernetes