Впровадження DevSecOps-практик у CI/CD під ключ

Безпека часто залишається «на потім» — перевірки перед релізом вручну, вразливості виявляються після інциденту. Ми впроваджуємо DevSecOps-практики під ключ: вбудовуємо SAST, SCA, сканування контейнерів та IaC прямо у ваш CI/CD, щоб розробники бачили проблеми до мерджа. Наша команда адаптує інструменти під ваш стек і супроводжує проєкт — від аудиту до підтримки.
Часті запитання

Впровадження 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. Тиждень 1–2: gitleaks pre-commit + Trivy в CI (найшвидший ROI)
  2. Тиждень 3–4: SAST (Semgrep з базовим ruleset) + dependency scanning
  3. Місяць 2: IaC scanning + політика обробки findings
  4. Місяць 3: ESO для secrets management + підпис образів
  5. Місяць 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 та отримайте консультацію сертифікованих інженерів.

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1393
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1368
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    815
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1139