0Pricing
Security+ Academy · Урок

DevSecOps: перенос безопасности в начало конвейеров

Встраивайте проверки SAST, DAST, сканирование контейнеров и проверку безопасности IaC в конвейеры CI/CD, чтобы средства контроля безопасности автоматически применялись при каждом коммите.

«DevSecOps: перенос безопасности в начало конвейеров» — бесплатный урок Security+ Academy на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Security+ Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Security+ Academy содержит 4 уроков всего.

Что означает перенос безопасности на ранние этапы

Перенос безопасности на ранние этапы означает интеграцию действий по обеспечению безопасности на более ранних этапах жизненного цикла разработки программного обеспечения — в IDE разработчика, при проверке кода и в конвейере CI/CD, — вместо проверки безопасности только на финальном этапе перед развёртыванием. Традиционные проверки безопасности выполнялись в конце цикла разработки, из-за чего исправления становились дорогими и занимали много времени. Обнаружение уязвимости во время разработки обходится примерно в 100 раз дешевле, чем её обнаружение в рабочей среде после взлома.

Что такое DevSecOps

DevSecOps расширяет модель DevOps, интегрируя безопасность как общую ответственность команд разработки, эксплуатации и безопасности на протяжении всего SDLC. Цель заключается в том, чтобы автоматизировать тестирование безопасности и запускать его на каждом этапе, не замедляя выпуск. Безопасность становится непрерывным свойством конвейера, а не разовой контрольной точкой. В зрелых программах DevSecOps разработчики получают обратную связь по безопасности через несколько секунд после написания кода, а не через несколько недель после ручной проверки.

SAST: статическое тестирование безопасности приложений

SAST (статическое тестирование безопасности приложений) анализирует исходный код, байт-код или двоичный код, не выполняя приложение. Инструменты SAST ищут шаблоны, указывающие на уязвимости: SQL-конкатенацию, несанитизированный вывод, использование запрещённых функций, учётные данные, жёстко заданные в коде, и небезопасное применение криптографии. SAST запускается в CI-конвейере при каждом коммите и выявляет проблемы до того, как они попадут в QA или рабочую среду. Среди популярных инструментов — Semgrep, SonarQube, Checkmarx и Veracode.

# Semgrep SAST rule example:
# Detect raw SQL string concatenation (SQL injection risk):
# rules:
#   - id: sql-injection-string-concat
#     pattern: |
#       $QUERY = '...' + $USER_INPUT
#       $DB.execute($QUERY)
#     message: 'SQL injection risk: use parameterized queries'
#     severity: ERROR
#     languages: [python]

# Running Semgrep in CI:
# semgrep --config auto --error src/
# -> Fails build if ERROR severity findings found

DAST: динамическое тестирование безопасности приложений

DAST (динамическое тестирование безопасности приложений) проверяет работающее приложение, отправляя вредоносные полезные данные и наблюдая за ответами — имитируя поведение реального Attacker. В отличие от SAST, DAST выявляет уязвимости, проявляющиеся только во время выполнения: недостатки аутентификации, проблемы управления сеансами, ошибки бизнес-логики и уязвимости внедрения в сложных потоках данных. Среди популярных инструментов DAST — OWASP ZAP (бесплатный), Burp Suite Enterprise и Acunetix. DAST запускается в промежуточной среде в составе конвейера.

# OWASP ZAP automated DAST in CI pipeline:
# docker run -t owasp/zap2docker-stable zap-baseline.py \
#   -t https://staging.myapp.com \
#   -r zap-report.html \
#   -I  (do not fail on alerts, report only)

# For blocking builds on high findings:
# zap-full-scan.py -t https://staging.myapp.com \
#   -l HIGH   (fail if HIGH or CRITICAL alerts found)

# ZAP tests for:
# SQL injection, XSS, CSRF, insecure headers,
# path traversal, broken authentication, open redirects

Сканирование образов контейнеров

Образы контейнеров создаются на основе базовых образов, содержащих пакеты ОС, среды выполнения языков и зависимости приложений — все они могут быть источниками известных уязвимостей. Инструменты сканирования образов контейнеров анализируют слои образов и выявляют уязвимые пакеты. Широко используются Trivy (бесплатный и быстрый), Grype (Anchore) и Clair. Сканирование выполняется как часть конвейера сборки образа и блокирует публикацию образов с критическими CVE в рабочие реестры.

# Trivy container scan in CI pipeline:
# trivy image --severity HIGH,CRITICAL \
#             --exit-code 1 \
#             myapp:latest

# Output example:
# library/python:3.9-slim (debian 11.6)
# ===================================
# CVE-2023-1234  CRITICAL  openssl 1.1.1n-0+deb11u3 -> 1.1.1t
# CVE-2023-5678  HIGH      libssl  1.1.1n            -> 1.1.1t

# --exit-code 1 causes pipeline to fail
# on any HIGH or CRITICAL finding -> blocks push to registry

Сканирование безопасности инфраструктуры как кода (IaC)

Сканирование безопасности IaC анализирует Terraform, CloudFormation, манифесты Kubernetes и диаграммы Helm на наличие неправильных настроек безопасности до их применения. Такие инструменты, как Checkov и tfsec, проверяют нарушения, включая: сегменты S3 без шифрования на стороне сервера, группы безопасности, разрешающие весь входящий трафик, роли IAM с разрешениями по шаблону подстановки и модули Kubernetes, работающие от имени root. Сканирование IaC предотвращает неправильные настройки облака до их попадания в любую среду.

# Checkov IaC scan example:
# checkov -d ./terraform/ --compact

# Findings example:
# FAILED: CKV_AWS_20: S3 Bucket has an ACL defined which allows public access
#   File: /terraform/s3.tf, Line: 15

# FAILED: CKV_AWS_57: S3 Bucket has server access logging disabled
#   File: /terraform/s3.tf, Line: 15

# FAILED: CKV_AWS_24: Ensure no security groups allow all ingress traffic
#   File: /terraform/sg.tf, Line: 8

# Passed checks: 47, Failed: 3, Skipped: 0

Сканирование секретов в конвейерах

Инструменты сканирования секретов проверяют исходный код и коммиты на наличие случайно включённых учётных данных. Такие инструменты, как truffleHog, GitLeaks и detect-secrets, сканируют историю git и новые коммиты в поисках шаблонов, соответствующих ключам API, строкам подключения, закрытым ключам и токенам JWT. В качестве перехватчика перед коммитом сканирование секретов блокирует коммиты, содержащие учётные данные. В качестве шлюза CI оно проверяет все файлы в репозитории при каждой отправке и помечает сборку как неуспешную, если обнаружены секреты.

# GitLeaks pre-commit hook configuration:
# .gitleaks.toml:
# [allowlist]
#   description = 'Known false positives'
#   paths = ['test/fixtures/fake_key.txt']

# Install as pre-commit hook:
# gitleaks protect --staged
# (scans staged files before commit is created)

# In CI pipeline:
# gitleaks detect --source=. --report-format=json \
#   --report-path=gitleaks-report.json
# exit code 1 = secrets found -> blocks pipeline

Моделирование угроз в SDLC

Моделирование угроз — это структурированный процесс выявления требований безопасности и недостатков проектирования до написания кода. Модель STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) помогает командам систематически перечислять угрозы для диаграммы потоков данных системы. Сеансы моделирования угроз проходят на этапе проектирования и формируют приоритетный список угроз, который определяет требования безопасности и помогает выбрать правила SAST/DAST.

# STRIDE threat categories applied to a web login API:
# S - Spoofing:       Attacker impersonates valid user
#     Control: Strong authentication, MFA
# T - Tampering:      Attacker modifies login request
#     Control: TLS, HMAC, input validation
# R - Repudiation:    User denies actions taken
#     Control: Audit logging with tamper-evident storage
# I - Info Disclosure: Password exposed in logs
#     Control: Never log sensitive fields
# D - Denial of Service: Flood login endpoint
#     Control: Rate limiting, CAPTCHA
# E - Elevation of Privilege: Bypass authorization
#     Control: Server-side authorization checks

Шлюзы безопасности: блокирующие и рекомендательные

Конвейеры DevSecOps реализуют проверки безопасности либо как блокирующие шлюзы (сборка завершается с ошибкой, развёртывание запрещается), либо как рекомендательные проверки (результаты сообщаются, а развёртывание продолжается). Результаты уровня CRITICAL и HIGH от SAST, сканирования контейнеров и обнаружения секретов обычно блокируют процесс. Результаты среднего и низкого уровня формируют уведомления или заявки без блокировки. Такой баланс не позволяет безопасности остановить весь выпуск, но гарантирует, что действительно опасные условия не попадут автоматически в рабочую среду.

Метрики безопасности в DevSecOps

Программы DevSecOps следует оценивать с помощью понятных метрик. Ключевые метрики включают: среднее время устранения (MTTR) результатов высокой степени серьёзности, плотность уязвимостей (количество результатов на 1 000 строк кода с течением времени), частоту пропуска (доля уязвимостей, обнаруженных после выпуска, по сравнению с обнаруженными до выпуска) и долю успешного прохождения шлюзов безопасности конвейера. Отслеживание этих метрик во времени демонстрирует эффективность программы и помогает принимать решения об инвестициях в дополнительные инструменты или обучение.

Культура: безопасность как общая ответственность

Самая сложная часть DevSecOps связана с культурой, а не с технологиями. Безопасность должна стать ответственностью каждого разработчика, а не только команды безопасности. Для этого необходимы: обучение разработчиков безопасности (осведомлённость о безопасном программировании), представители безопасности в командах разработки, разборы инцидентов без поиска виноватых, когда уязвимости достигают рабочей среды (с акцентом на улучшение процессов, а не на наказание), и поддержка руководства, позволяющая поступаться скоростью, когда этого требует реальный риск для безопасности. Технологии без изменения культуры приводят к появлению инструментов сканирования, которые разработчики учатся игнорировать.

Быстрая проверка

Проверьте своё понимание концепций CompTIA Security+ (SY0-701) из этого урока.

Итоги урока

В этом уроке Вы узнали, что DevSecOps интегрирует SAST, DAST, сканирование секретов, сканирование контейнеров и сканирование IaC в качестве автоматизированных шлюзов конвейера; блокировка результатов высокой степени серьёзности не позволяет опасным условиям попасть в рабочую среду; а сдвиг безопасности влево значительно снижает стоимость исправлений, поскольку уязвимости выявляются во время разработки, а не после развёртывания. Далее мы рассмотрим средства физической безопасности для объектов и центров обработки данных.

Часто задаваемые вопросы

Урок «DevSecOps: перенос безопасности в начало конвейеров» бесплатный?

Да — полный текст урока «DevSecOps: перенос безопасности в начало конвейеров» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Security+ Academy, подпишись на CoddyKit PRO. Курс Security+ Academy содержит 4 уроков всего.

Чему я научусь в уроке «DevSecOps: перенос безопасности в начало конвейеров»?

Встраивайте проверки SAST, DAST, сканирование контейнеров и проверку безопасности IaC в конвейеры CI/CD, чтобы средства контроля безопасности автоматически применялись при каждом коммите. Ты практикуешь Security+ Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Security+ Academy?

Предыдущий опыт не требуется. Security+ Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.

Сколько времени занимает урок «DevSecOps: перенос безопасности в начало конвейеров»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Security+ Academy?

Да. Каждый урок Security+ Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Проверка входных данных и кодирование выходных данных
  2. Безопасное управление секретами и переменными окружения
  3. Безопасность зависимостей и анализ состава программного обеспечения
  4. DevSecOps: перенос безопасности в начало конвейеров
← Назад к Security+ Academy