Налаштування SCA через Dependabot: автоматична безпека залежностей

Налаштування SCA через Dependabot

У проєкті з 50+ npm-пакетами регулярно спливають CVE, але руки не доходять оновлювати кожну залежність вручну. Ми стикалися з цим десятки разів: накопичується технічний борг, а безпека страждає. Одного разу ми прийшли в проєкт, де Dependabot генерував по 30 PR на день — команда просто перестала їх переглядати. Після правильного групування та автомержа кількість PR скоротилася до 5 на тиждень, а CVE виправлялися за години. Dependabot автоматизує цей процес, але без правильного налаштування він створює хаос із десятків PR. Розповідаємо, як налаштувати його так, щоб він приносив користь, а не головний біль.

Dependabot економить у середньому 70% часу на управлінні залежностями. Згідно з GitHub Docs, він підтримує понад 10 екосистем, включаючи npm, pip, Docker, Maven та інші. Інтеграція з GitHub Advisories дозволяє отримувати сповіщення про критичні CVE протягом години після публікації.

Як Dependabot допомагає з SCA?

Dependabot — вбудований інструмент GitHub для автоматичного оновлення залежностей і моніторингу вразливостей. Два режими роботи: Dependabot Security Updates (автоматичні PR при виявленні CVE) та Dependabot Version Updates (планові оновлення до останніх версій). Для SCA в першу чергу важливий перший режим, але правильне налаштування обох разом дає хорошу гігієну залежностей. Security Updates закривають вразливості за лічені години, а Version Updates запобігають drift залежностей.

Як налаштувати Dependabot для великих проєктів?

Базова конфігурація файлу .github/dependabot.yml вже дає багато, але для проєктів із десятками залежностей потрібні групування PR, автомерж та робота з приватними registry.

Групування PR — важливо для великих проєктів

Без groups Dependabot відкриває окремий PR на кожну залежність. При 50+ пакетах це спам. З групуванням:

---
groups:
  production-deps:
    dependency-type: "production"
    update-types:
      - "minor"
      - "patch"
  dev-tools:
    dependency-type: "development"
    patterns:
      - "eslint*"
      - "@types/*"
      - "jest*"
      - "vitest*"

Major version оновлення завжди створюються окремими PR — Dependabot не включає їх у групи. Це правильно: major bumps потребують окремого review.

Автомерж для patch-оновлень

Для patch-версій (x.y.Z) з пройденими тестами можна налаштувати автомерж через GitHub Actions:

---
# .github/workflows/dependabot-automerge.yml
name: Dependabot auto-merge

on:
  pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Fetch Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Auto-merge patch updates
        if: |
          steps.metadata.outputs.update-type == 'version-update:semver-patch' &&
          steps.metadata.outputs.dependency-type == 'indirect'
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Автомерж тільки для indirect (транзитивні) patch-залежностей — прямі залежності краще review вручну навіть при patch.

Робота з приватними registry

Dependabot не вміє працювати з private package registries без додаткової конфігурації. Для npm:

---
registries:
  npm-private:
    type: npm-registry
    url: https://npm.your-company.com
    token: ${{ secrets.NPM_TOKEN }}
updates:
  - package-ecosystem: "npm"
    registries:
      - npm-private

Типові помилки та як їх уникнути

Часта помилка — довірити налаштування Dependabot розробникам без досвіду SCA. Результат: неправильне групування, ігнорування приватних registry, автомерж без тестів. Наприклад, в одному проєкті автомерж зламав збірку через несумісність transitive dependencies. Рішення: завжди включати CI-перевірки перед мержем і обмежувати автомерж тільки на patch-оновлення транзитивних залежностей. Ще одна проблема — ігнорування Docker-образів. Dependabot сканує тільки Dockerfile, але не шари образів. Для повного аналізу використовуйте Trivy або Snyk.

Коли варто комбінувати Dependabot з іншими інструментами?

Dependabot чудово справляється з базовим SCA, але не закриває всі сценарії. Якщо ви використовуєте Docker-образи з безліччю шарів, приватні registry зі складною автентифікацією або потребуєте глибокого аналізу CVE (CVSS, remediation advice), комбінуйте Dependabot зі сканерами на кшталт Trivy або Snyk. Ми часто включаємо Dependabot як перший шар захисту, а для критичних проєктів додаємо щотижневе сканування контейнерів.

Чому варто довірити налаштування нам?

Наші інженери мають понад 5 років досвіду в DevOps і реалізували SCA-пайплайни для 20+ проєктів різного масштабу. Ми гарантуємо, що Dependabot буде налаштований з урахуванням вашого стеку, branch protection та CI-процесів, а також інтегрований з додатковими інструментами при необхідності. Dependabot configuration options — офіційна документація, якою ми керуємося.

Що входить у налаштування Dependabot

Строки орієнтовно

Базове налаштування: від 1 до 3 робочих днів. Повний комплекс з інтеграцією додаткових сканерів та CI: від 1 до 2 тижнів. Вартість розраховується індивідуально залежно від складності проєкту.

Зв'яжіться з нами, щоб отримати консультацію з налаштування Dependabot та повного SCA-пайплайну. Замовте аудит поточної конфігурації — ми виявимо вузькі місця та запропонуємо оптимізації. Допоможемо автоматизувати безпеку залежностей у вашому проєкті.