Безпека DevOps pipeline стала критичним диференціатором для організацій, що розгортають програмне забезпечення у великих масштабах. OWASP Top 10 CI/CD Security Risks визначає найнебезпечніші вразливості в сучасних pipeline'ах, від недостатнього контролю потоку до компрометованих залежностей збірки. Цей посібник охоплює основні практики DevSecOps, які інтерв'юери очікують від кандидатів у 2026 році.

Shift-Left Security

DevSecOps інтегрує перевірки безпеки на кожному етапі життєвого циклу доставки програмного забезпечення. Замість того, щоб розглядати безпеку як останній бар'єр перед продакшеном, практики shift-left виявляють вразливості під час розробки, коли виправлення коштують менше та впроваджуються швидше.

Розуміння Поверхні Атаки CI/CD

Сучасні CI/CD pipeline'и представляють складну поверхню атаки, що охоплює репозиторії вихідного коду, раннери збірки, реєстри артефактів та цілі розгортання. Компрометація tj-actions/changed-files у березні 2025 року витікла секрети з понад 23 000 репозиторіїв шляхом ін'єкції шкідливого коду у широко використовуваний GitHub Action. Атака TanStack на початку 2026 року опублікувала понад 170 отруєних npm пакетів з дійсним підтвердженням SLSA Build Level 3, демонструючи, що навіть криптографічні атестації можуть бути обійдені, коли зловмисники контролюють процес збірки.

Ці інциденти підкреслюють три критичні контрольні точки:

Цілісність джерел: Правила захисту гілок, підписані коміти та обов'язкові перевірки коду запобігають несанкціонованим змінам у pipeline збірки
Ізоляція збірки: Ефемерні раннери, мінімальні дозволи та верифікація артефактів обмежують радіус ураження компрометованих залежностей
Гігієна секретів: Короткотривалі облікові дані, OIDC федерація та сканування секретів усувають статичні токени, які шукають зловмисники

Інтерв'юери часто просять кандидатів простежити межі довіри у типовому pipeline розгортання. Сильна відповідь відображає кожен етап, де зловмисник міг би ін'єктувати код або ексфільтрувати облікові дані.

SAST та SCA: Раннє Виявлення Вразливостей

Static Application Security Testing (SAST) аналізує вихідний код на предмет вразливостей безпеки без виконання програми. Software Composition Analysis (SCA) ідентифікує відомі вразливості у сторонніх залежностях. Запуск обох при кожному pull request виявляє більшість типових проблем безпеки до злиття коду.

yaml

# .github/workflows/security.yml
name: Security Scan

on:
  pull_request:
    branches: [main]

jobs:
  sast:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Run CodeQL
        uses: github/codeql-action/analyze@v3
        with:
          languages: javascript,typescript
          queries: security-extended

  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: fs
          scan-ref: .
          severity: HIGH,CRITICAL
          exit-code: 1

Наведений workflow запускає CodeQL для SAST та Trivy для SCA. Налаштування exit-code: 1 на Trivy призводить до невдачі збірки при появі вразливостей високого або критичного рівня. GitHub Advanced Security та GitLab Ultimate включають вбудовані можливості SAST, що інтегруються з їхніми відповідними workflow merge request.

Керування Секретами з Федерацією OIDC

Довготривалі облікові дані, що зберігаються в CI/CD платформах, залишаються найбільш експлуатованим вектором атаки при компрометації pipeline. GitHub Actions OIDC замінює статичні секрети короткотривалими токенами, що видаються хмарним провайдером під час виконання.

yaml

# .github/workflows/deploy.yml
name: Deploy to AWS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # Необхідно для OIDC
      contents: read
    steps:
      - uses: actions/checkout@v4
      
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: us-east-1
          # AWS_ACCESS_KEY_ID та AWS_SECRET_ACCESS_KEY ніде не зберігаються
      
      - name: Deploy to ECS
        run: aws ecs update-service --cluster prod --service api --force-new-deployment

Політика довіри ролі AWS IAM обмежує, які репозиторії та гілки можуть прийняти роль:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

Умова обмежує видачу облікових даних до гілки main конкретного репозиторію. Azure та GCP пропонують еквівалентні можливості федерації OIDC. Для секретів, які повинні існувати, HashiCorp Vault та хмарні опції, такі як AWS Secrets Manager, забезпечують централізовану ротацію та журналювання доступу.

Готовий до співбесід з DevOps?

Практикуйся з нашими інтерактивними симуляторами, flashcards та технічними тестами.

Відкрий DevOps

Безпека Контейнерів та Генерація SBOM

Образи контейнерів вносять залежності, що виходять за межі коду програми. Базові образи, системні пакети та інструменти збірки несуть потенційні вразливості. Сканування образів під час процесу збірки та генерація Software Bill of Materials (SBOM) забезпечує видимість у всьому ланцюгу залежностей.

yaml

# GitLab CI container security
container_scanning:
  stage: test
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:7
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    CS_DOCKERFILE_PATH: Dockerfile
  script:
    - /analyzer run
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json
      cyclonedx: gl-sbom.cdx.json

Артефакт SBOM у форматі CycloneDX дозволяє downstream споживачам перевіряти нововиявлені вразливості без перебудови. Фреймворки безпеки ланцюга постачання, такі як SLSA, вимагають генерації SBOM як базового контролю.

Динамічне Тестування Безпеки Додатків на Staging

Інструменти DAST тестують працюючі додатки на предмет вразливостей, які статичний аналіз не може виявити, включаючи дефекти автентифікації, вразливості ін'єкцій та помилки конфігурації безпеки. Запуск DAST проти середовища staging перед продакшен розгортанням виявляє проблеми, які виживають на попередніх етапах.

yaml

# .gitlab-ci.yml
dast:
  stage: dast
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/dast:5
  variables:
    DAST_WEBSITE: https://staging.example.com
    DAST_AUTH_URL: https://staging.example.com/login
    DAST_USERNAME: $DAST_USER
    DAST_PASSWORD: $DAST_PASSWORD
    DAST_AUTH_VERIFICATION_URL: https://staging.example.com/dashboard
  script:
    - /analyze
  artifacts:
    reports:
      dast: gl-dast-report.json
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

OWASP ZAP надає безкоштовну альтернативу для команд без GitLab Ultimate. Автентифіковані сканування тестують функціональність за стінами входу, де зазвичай знаходяться чутливі операції. Для середовищ Kubernetes, тестування безпеки API валідує конфігурації ingress та політики service mesh.

Сканування Безпеки Infrastructure as Code

Terraform, маніфести Kubernetes та Helm charts визначають інфраструктуру, яку атакують зловмисники. Сканування IaC виявляє помилки конфігурації до потрапляння в хмарні середовища.

yaml

# Checkov IaC scanning in GitHub Actions
iac-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    
    - name: Run Checkov
      uses: bridgecrewio/checkov-action@v12
      with:
        directory: terraform/
        framework: terraform
        soft_fail: false
        output_format: sarif
        output_file_path: checkov.sarif
    
    - name: Upload SARIF
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: checkov.sarif

Checkov валідує конфігурації Terraform відповідно до бенчмарків безпеки, включаючи CIS та SOC2. Вивід SARIF інтегрується з вкладкою GitHub Security для уніфікованого відстеження вразливостей. Команди, що використовують Ansible, можуть додати ansible-lint з правилами безпеки до того ж етапу pipeline.

Зміцнення Ланцюга Постачання GitHub Actions

Прив'язка дій до повних SHA комітів запобігає атакам на основі тегів, де мейнтейнери або компрометовані акаунти force-push злоякісні версії до існуючих тегів. Кампанія Megalodon у травні 2026 надіслала понад 5700 шкідливих комітів до тисяч репозиторіїв за одне шестигодинне вікно.

yaml

# Pin to commit SHA, not tag
steps:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
  
  # Avoid mutable tags like @v4 or @latest
  # Bad: uses: actions/checkout@v4

Dependabot оновлює дії, прив'язані до SHA, коли виходять нові версії. OWASP DevSecOps Guideline рекомендує додаткові контролі:

Обмеження дозволів workflow до мінімально необхідних за допомогою блоків permissions:
Вимкнення тригерів pull_request_target або обмеження їх до позначених PR від collaborators
Використання GITHUB_TOKEN з дозволами тільки на читання за замовчуванням на рівні організації
Увімкнення обов'язкових перевірок статусу та захисту гілок на гілках за замовчуванням

Поширені Питання DevSecOps на Співбесідах

Інтерв'юери оцінюють як технічну глибину, так і практичний досвід. Ці питання часто з'являються на співбесідах з безпеки DevOps.

П: Як запобігти комітам секретів до репозиторію?

Pre-commit хуки з інструментами, такими як detect-secrets або gitleaks, сканують staged зміни перед комітом. Правила push на стороні сервера в GitHub Enterprise або GitLab блокують коміти, що містять шаблони, що відповідають відомим форматам секретів. Сканування секретів також повинно виконуватися в CI як запасний варіант, оскільки розробники можуть обходити локальні хуки.

П: Поясніть різницю між SAST, DAST та SCA.

SAST аналізує вихідний код без виконання, знаходячи помилки, такі як шаблони SQL injection та захардкоджені облікові дані. SCA ідентифікує відомі вразливості у залежностях, зіставляючи версії пакетів з базами CVE. DAST тестує працюючі додатки, надсилаючи шкідливі запити та спостерігаючи за відповідями. Зрілий pipeline запускає всі три: SAST та SCA при кожному PR, DAST на staging перед продакшен релізами.

П: Що таке принцип найменших привілеїв у CI/CD?

Завдання збірки повинні мати лише дозволи, необхідні для виконання їхнього конкретного завдання. Завдання, що розгортає на staging, не потребує продакшен облікових даних. OIDC федерація забезпечує це, видаючи облікові дані, обмежені конкретними репозиторіями, гілками та завданнями workflow. OWASP CI/CD Top 10 перераховує неадекватне управління ідентифікацією та доступом як головний ризик, оскільки компрометовані завдання з надмірними дозволами драматично розширюють поверхню атаки.

П: Як верифікувати цілісність образів контейнерів?

Підписи content trust (Docker Content Trust, Sigstore cosign) забезпечують криптографічну верифікацію того, що образи були зібрані довіреними pipeline. SBOM атестації документують компоненти всередині образів. Admission controllers в Kubernetes відхиляють непідписані образи або образи з відомими критичними вразливостями. Сканування registry виявляє вразливості, що з'являються після часу збірки.

П: Опишіть атаку на ланцюг постачання CI/CD та як їй запобігти.

Атака tj-actions/changed-files компрометувала широко використовуваний GitHub Action, ін'єктуючи код, що ексфільтрував секрети до контрольованих зловмисником endpoint'ів. Заходи запобігання включають: прив'язку дій до SHA комітів замість тегів, використання Dependabot для оновлення прив'язаних версій, обмеження того, які дії можуть виконуватися через політики на рівні організації, та моніторинг виконання workflow на предмет несподіваних мережевих з'єднань або доступу до облікових даних.

Починай практикувати!

Перевір свої знання з нашими симуляторами співбесід та технічними тестами.

Створити безкоштовний обліковий запис

Побудова Дорожньої Карти DevSecOps для Технічних Співбесід

Кандидати, які демонструють структурне мислення щодо впровадження безпеки, виділяються. Практичне розгортання DevSecOps пріоритезує контролі з високим впливом та низькими зусиллями:

Негайне увімкнення сканування секретів та захисту гілок, оскільки обидва безкоштовні та блокують найпоширеніші вектори атак
Додавання SAST та SCA до перевірок pull request у першому спринті, виявляючи вразливості до злиття
Міграція від статичних облікових даних до OIDC федерації, усуваючи найнебезпечніші секрети з CI/CD платформ
Впровадження сканування контейнерів та генерації SBOM як частини збірки образів
Розгортання сканування IaC для Terraform, Kubernetes та хмарних конфігурацій
Додавання DAST для додатків з автентифікацією або обробкою чутливих даних
Встановлення runtime моніторингу з Falco або еквівалентом для продакшен кластерів Kubernetes

Інтерв'юери цінують кандидатів, які визнають компроміси. Сканування безпеки додає затримку pipeline. Хибні спрацьовування створюють втому від алертів. Зріла практика DevSecOps налаштовує пороги, приймає розраховані ризики з компенсуючими контролями та постійно вимірює середній час до виправлення.