Що таке SCA і як перевіряти залежності на відомі ризики

Зачіпка

SCA відповідає на дуже практичне питання: які чужі компоненти є в нашому проєкті і чи відомі для них ризики.

Це не магічна кнопка “зробити безпечно”. Це dependency radar. Він показує, де у бібліотеках, пакетах або container layers є відомі проблеми, щоб команда могла прийняти нормальне рішення: оновити, замінити, прийняти ризик або перевірити глибше.

Проблема / Контекст

Сучасний застосунок майже завжди складається з власного коду і великої кількості сторонніх компонентів. У Node.js це npm або pnpm пакети. У Python - PyPI. У backend і infra можуть бути container images, системні пакети, Terraform modules, GitHub Actions і ще багато дрібних деталей.

Команда часто бачить тільки direct dependencies у package.json. Але реальний production artifact містить також transitive dependencies. Саме там нерідко з’являються CVE, старі версії або ліцензійні сюрпризи.

SCA бере інвентар залежностей і порівнює його з базами відомих вразливостей, advisory feeds, policy rules і даними про ліцензії. На виході команда отримує findings, а не готову істину. Далі потрібен triage.

Чому це важливо

Без SCA команда дізнається про dependency risk випадково: з новин, від клієнта, після incident або під час ручної перевірки перед релізом. Це повільно і нервово.

З SCA ризики стають видимими раніше:

• pull request додає нову vulnerable dependency;
• Dependabot або Renovate відкриває update;
• release scan знаходить critical CVE у container image;
• security team бачить, які findings повторюються;
• команда може пов’язати SBOM із реальним triage.

Але є пастка. Якщо SCA просто кричить на кожну CVE, люди швидко перестають слухати. Хороший процес відрізняє “критично й досяжно” від “є запис у базі, але в нашому продукті шлях не використовується”.

Схема в голові

Уяви SCA як перевірку складу продукту перед відправкою. Спершу треба знати, що лежить у коробці. Потім перевірити, чи є для цих деталей відомі проблеми. Потім вирішити, що робити.

Практична схема:

1. lockfile або artifact дає список компонентів;
2. SBOM робить цей список переносним і прив’язаним до release;
3. SCA порівнює компоненти з advisory базами;
4. triage враховує severity, exploitability і reachability;
5. dependency update або mitigation потрапляє в нормальний workflow.

Важливо: SCA має дивитися на те, що реально їде в production. Скан source tree корисний, але якщо production - це container image, перевірте image теж.

Як це зробити

1. Почніть із правильного джерела

Для Node.js мінімум - scan lockfile:

npm audit --production
pnpm audit --prod

Для container-based deploy додайте image scanner, наприклад Trivy або інший інструмент, який бачить OS packages і application dependencies. Якщо у вас уже є SBOM, використовуйте його як стабільний input для security review.

2. Додайте SCA в CI/CD

Перший рівень - pull request check:

name: dependency-scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npm audit --production --audit-level=high

Це не ідеальний enterprise setup, але він ловить очевидні high-risk зміни. Далі можна підключити GitHub dependency review, GitLab dependency scanning, Snyk, Trivy, osv-scanner або інший інструмент під ваш стек.

3. Не плутайте severity з дією

Severity важлива, але вона не відповідає на всі питання. Для triage дивіться:

• чи компонент є у production;
• direct це dependency чи transitive;
• чи використовується вразлива функція;
• чи є exploit;
• чи є fixed version;
• чи є тимчасова mitigation;
• чи ламає update сумісність.

Critical reachable vulnerability у production dependency - кандидат на блокер. Medium finding у dev-only пакеті може піти в backlog. Важливо, щоб це було правилом, а не настроєм людини в п’ятницю ввечері.

4. Налаштуйте update workflow

SCA без update workflow швидко перетворюється на червоний список. Потрібні:

• автоматичні dependency PR;
• власник triage;
• правило для emergency update;
• окремий backlog для non-blocking findings;
• періодичний review винятків;
• зв’язок із SBOM для release evidence.

5. Документуйте винятки

Іноді finding справді не впливає на продукт. Наприклад, вразлива частина бібліотеки не пакується в production або кодовий шлях недосяжний. Це можна прийняти, але не мовчки.

Для винятку запишіть: CVE, компонент, версію, чому ризик прийнято, хто власник і коли перегляд. Виняток без дати перегляду майже гарантовано стане боргом.

Типові помилки

• сканувати тільки direct dependencies;
• ігнорувати container image;
• блокувати всі findings без triage;
• не блокувати нічого, бо “SCA шумить”;
• не оновлювати lockfile після dependency update;
• тримати suppressions без власника;
• не відрізняти dev-only пакет від production dependency;
• думати, що SCA замінює code review або threat modeling.

Висновок / План дій

SCA робить dependency risk видимим. Але користь з’являється тільки тоді, коли scan підключений до реального artifact, triage rules зрозумілі, а оновлення залежностей не є героїчним ручним процесом.

Почни з малого:

1. визнач, що саме їде в production;
2. запусти SCA на lockfile і container image;
3. додай PR check для high і critical findings;
4. налаштуй dependency update PR;
5. веди backlog для non-blocking risks;
6. документуй винятки з датою перегляду;
7. зв’яжи SCA з SBOM для release evidence.

Офіційні джерела:

• https://owasp.org/www-community/Component_Analysis
• https://owasp.org/www-project-dependency-check/
• https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
• https://docs.gitlab.com/user/application_security/dependency_scanning/
• https://www.cisa.gov/sbom