Впровадження DevSecOps-практик у CI/CD під ключ
Впроваджуємо DevSecOps понад 7 років, на рахунку 50+ проєктів. DevSecOps — не окремий інструмент і не окрема команда. Це зсув вліво (shift left) безпеки. Перевірки, які раніше робилися вручну перед релізом або взагалі не робилися, тепер вбудовуються в повсякденний процес розробки: в pre-commit hooks, в CI/CD пайплайн, в деплой в Kubernetes. Розробник дізнається про вразливість до мерджа, а не після інциденту. Гарантуємо зниження кількості інцидентів безпеки на ранніх етапах. Статичний аналіз знаходить на 80% більше вразливостей, ніж ручне тестування на проникнення (за даними NIST). Оцінимо ваш поточний рівень безпеки — зв'яжіться з нами.
Наш підхід гарантує, що безпека стає невід'ємною частиною розробки, а не окремою перевіркою перед релізом. Ми не просто налаштовуємо інструменти — ми адаптуємо їх під ваш стек і процеси.
Чому «просто поставити Trivy» недостатньо
Найпоширеніша помилка при впровадженні DevSecOps — встановити один інструмент і вважати задачу вирішеною. Реальна картина складніша: один і той самий сервіс має кілька векторів атаки, і кожен вимагає свого інструменту.
Вектор 1 — код застосунку
SAST (SonarQube, Semgrep, CodeQL) шукає вразливі патерни у вихідниках — SQL injection, hardcoded credentials, небезпечна десеріалізація.
Вектор 2 — залежності
SCA (Software Composition Analysis) — Dependabot, Snyk, OWASP Dependency-Check аналізує npm/pip/maven залежності на відомі CVE.
Вектор 3 — контейнери
Trivy, Grype сканують Docker-образи, включаючи OS-пакети та транзитивні залежності.
Вектор 4 — IaC
Checkov, tfsec, KICS перевіряють Terraform, Kubernetes manifests, Helm charts — відкриті S3 buckets, надлишкові IAM права, відсутність encryption at rest.
Вектор 5 — секрети в коді
gitleaks, truffleHog шукають випадково закомічені API-ключі, токени, приватні ключі.
Вектор 6 — runtime
Falco детектує підозрілу поведінку в запущених контейнерах — несподіваний exec, зміна файлів /etc/passwd, network connection з несподіваного процесу.
Як впоратися з хибними спрацьовуваннями?
Будь-який security інструмент генерує false positive. Процес управління винятками критично важливий: без нього інженери починають відключати інструменти цілком.
Для кожного винятку:
- Унікальний ідентифікатор CVE/правила
- Обґрунтування: чому не застосовно або не виправно
- Дата перегляду (зазвичай +3 місяці або +6 місяців)
- Хто прийняв рішення
# semgrep inline suppression с обоснованием
password = get_password() # nosemgrep: python.lang.security.audit.hardcoded-password
# Exemption: password читается из env var, а не захардкожен. Проверено актуально. Архітектура DevSecOps пайплайну
Розподіляємо перевірки за етапами з урахуванням швидкості та важливості: Pre-commit (секунди):
---
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
- repo: https://github.com/antonbabenko/pre-commit-terraform
rev: v1.86.0
hooks:
- id: terraform_tfsec
- id: terraform_checkov
CI/CD — стадія security (паралельно, хвилини):
---
# .gitlab-ci.yml
stages: [build, security, test, deploy]
.security-base:
stage: security
needs: [build]
sast:
extends: .security-base
image: returntocorp/semgrep
script:
- semgrep --config=auto --error --json --output=semgrep.json src/
artifacts:
reports:
sast: semgrep.json
container-scan:
extends: .security-base
image: aquasec/trivy:latest
script:
- trivy image --exit-code 1 --ignore-unfixed --severity CRITICAL --format sarif --output trivy.sarif $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
artifacts:
reports:
container_scanning: trivy.sarif
iac-scan:
extends: .security-base
image: bridgecrew/checkov:latest
script:
- checkov -d terraform/ --output junitxml --output-file-path checkov.xml --soft-fail-on MEDIUM
artifacts:
reports:
junit: checkov.xml
dependency-scan:
extends: .security-base
script:
- npm audit --audit-level=high # або pip-audit, safety
Всі стадії security запускаються паралельно — не додають послідовного часу до пайплайну.
Політика реагування на знахідки
Інструменти без чіткої політики створюють шум. Потрібно заздалегідь домовитися:
| Тип | Severity | Дія |
|---|---|---|
| Секрет у коді | будь-який | Блокуємо merge, ротуємо секрет негайно |
| Критична CVE з патчем | CRITICAL | Блокуємо merge, виправляємо протягом 24 год |
| Критична CVE без патча | CRITICAL | Тікет у backlog, exemption з обґрунтуванням |
| SAST: SQL injection, RCE | HIGH | Блокуємо merge |
| SAST: порушення best practice | LOW/MEDIUM | Фіксуємо, не блокуємо |
| IaC: відкритий S3 bucket | CRITICAL | Блокуємо merge |
| IaC: відсутність тегу | LOW | Попередження |
Політика має бути закріплена в документації і всім відома заздалегідь — інакше кожне заблоковане MR буде несподіванкою для розробника. Виправлення вразливості на етапі розробки обходиться в 30 разів дешевше, ніж у продакшені (за даними NIST).
Чому runtime-моніторинг критично важливий?
Після деплою — Falco як HIDS (Host Intrusion Detection System) для Kubernetes:
---
# Приклад кастомного Falco rule
rule: Unexpected Network Connection from App Container
desc: Детектує несподівані вихідні з'єднання з app-контейнерів
condition: >
outbound and container.image.repository = "myorg/myapp" and not fd.rip in (allowed_ips)
output: >
Unexpected outbound connection (user=%user.name command=%proc.cmdline connection=%fd.name container=%container.name image=%container.image.repository)
priority: WARNING
tags: [network, myapp]
---
Falco інтегрується з Falcosidekick для відправки подій у Slack, PagerDuty, Elasticsearch.
Процес впровадження
Не впроваджуємо все одразу. Послідовність за пріоритетом:
- Тиждень 1–2: gitleaks pre-commit + Trivy в CI (найшвидший ROI)
- Тиждень 3–4: SAST (Semgrep з базовим ruleset) + dependency scanning
- Місяць 2: IaC scanning + політика обробки findings
- Місяць 3: ESO для secrets management + підпис образів
- Місяць 4+: Falco runtime detection + OPA/Kyverno policies
Кожен етап починаємо в audit mode — збираємо baseline, виправляємо існуючі порушення, тільки потім вмикаємо blocking.
Що ви отримуєте в результаті
- Аудит поточного стану CI/CD та інфраструктури
- Налаштування всіх описаних інструментів (gitleaks, Trivy, Semgrep, Checkov, Falco)
- Інтеграція у ваш пайплайн (GitLab CI, GitHub Actions або Jenkins)
- Політики безпеки для кожного типу знахідки
- Документація щодо процесу обробки винятків
- Навчання команди DevSecOps-практикам (2 воркшопи)
- Підтримка протягом 1 місяця після впровадження
Строки всього проєкту
| Масштаб | Оцінка |
|---|---|
| Стартовий набір: gitleaks + Trivy + Semgrep (1 репозиторій) | 3–5 днів |
| Повний стек: всі вектори + політика + документація (1 команда) | 2–4 тижні |
| Enterprise: кілька команд + governance + навчання | 2–3 місяці |
Вартість розраховується індивідуально після аудиту поточного стану інфраструктури та CI/CD пайплайнів. Замовте аудит безпеки вашого CI/CD та отримайте консультацію сертифікованих інженерів.







