📦 Dependency Security

SCA - Software Composition Analysis

Analýza bezpečnosti závislostí a knihoven třetích stran

Co je Software Composition Analysis?

Software Composition Analysis (SCA) je automatizovaný proces identifikace a analýzy open-source komponent, knihoven a závislostí ve vaší aplikaci. SCA nástroje detekují známé bezpečnostní zranitelnosti, licenční rizika a zastaralé verze závislostí, což je kritické v době, kdy až 90% moderních aplikací obsahuje kód třetích stran.

90%
aplikací používá open-source kód
70%
zranitelností pochází ze závislostí
200+
průměrný počet závislostí v projektu

Proč je SCA kritické?

Moderní aplikace jsou postaveny na desítkách až stovkách knihoven třetích stran. Každá závislost představuje potenciální bezpečnostní riziko:

⚠️ Známé případy zranitelností v závislostech

  • Log4Shell (CVE-2021-44228): Kritická RCE zranitelnost v Log4j knihovně, postihla miliony aplikací
  • Heartbleed (CVE-2014-0160): Zranitelnost v OpenSSL umožňující krádež citlivých dat
  • Struts 2 (CVE-2017-5638): RCE zranitelnost, která vedla k útoku na Equifax (147M záznamů)
  • event-stream npm package: Supply chain útok s bitcoin minerem injektovaným do populární knihovny

Co SCA nástroje detekují?

1. Bezpečnostní zranitelnosti

SCA nástroje skenují vaše závislosti proti databázím známých zranitelností (CVE, NVD, GitHub Advisory Database, Snyk Vulnerability DB):

2. Licenční compliance

Analýza licencí open-source knihoven a detekce potenciálních konfliktů:

3. Zastaralé závislosti

Identifikace knihoven, které jsou zastaralé nebo již nejsou udržovány:

4. Software Bill of Materials (SBOM)

Kompletní inventář všech komponent ve vaší aplikaci:

Oblíbené SCA nástroje

Cloud/Commercial

Snyk Open Source

Jeden z nejpopulárnějších cloudových SCA nástrojů s rozsáhlou databází zranitelností a snadnou integrací do CI/CD.

  • Automatické PR s opravami
  • Prioritizace zranitelností podle exploitability
  • Podpora npm, Maven, pip, RubyGems, NuGet
  • IDE integrace (VS Code, IntelliJ)
  • Free tier pro open-source projekty
Cloud/Commercial

Mend (WhiteSource)

Enterprise-grade SCA řešení se zaměřením na licenční compliance a komplexní reporting.

  • Real-time alerting na nové zranitelnosti
  • Pokročilá licenční analýza
  • Policy enforcement
  • Integrace s Jira, ServiceNow
Free/Open Source

OWASP Dependency-Check

Open-source nástroj od OWASP pro detekci známých zranitelností v závislostech projektu.

  • Podpora Java, .NET, Ruby, Node.js, Python
  • CLI, Maven plugin, Gradle plugin, Jenkins plugin
  • Integrace s NVD (National Vulnerability Database)
  • HTML/XML/JSON reporting
  • Zcela zdarma a open-source
GitHub Native

GitHub Dependabot

Nativní GitHub nástroj pro automatické bezpečnostní aktualizace závislostí.

  • Automatické Pull Requesty s opravami
  • Dependabot Security Alerts
  • Version updates pro všechny ekosystémy
  • Zdarma pro všechny GitHub repozitáře
  • Integrace s GitHub Security Advisory
CLI Tool

npm audit / yarn audit

Vestavěné nástroje v npm a Yarn pro audit Node.js závislostí.

  • Okamžitá analýza package.json
  • Automatické opravy pomocí npm audit fix
  • Severity levels (low, moderate, high, critical)
  • Integrace s npm registry databází
Enterprise

JFrog Xray

Universal artifact analysis pro komplexní CI/CD pipeline security.

  • Skenování Docker images, Maven, npm, PyPI
  • Integrace s JFrog Artifactory
  • Policy-based blocking artefaktů
  • Deep scan binárních artefaktů

Praktický příklad: npm audit

Nejjednodušší způsob, jak začít s SCA v Node.js projektech:

# Spuštění auditu závislostí npm audit # Výstup zobrazí nalezené zranitelnosti: # found 3 vulnerabilities (1 moderate, 2 high) # Automatická oprava zranitelností npm audit fix # Zobrazení detailního reportu npm audit --json > audit-report.json # Audit s production dependencies pouze npm audit --production # Nastavení audit levelu v CI/CD npm audit --audit-level=high # Pokud existuje high nebo critical, příkaz selže (exit code 1)

Příklad výstupu npm audit:

┌───────────────┬──────────────────────────────────────────────────┐ │ Moderate │ Regular Expression Denial of Service │ ├───────────────┼──────────────────────────────────────────────────┤ │ Package │ minimatch │ ├───────────────┼──────────────────────────────────────────────────┤ │ Patched in │ >=3.0.5 │ ├───────────────┼──────────────────────────────────────────────────┤ │ Dependency of │ jest [dev] │ ├───────────────┼──────────────────────────────────────────────────┤ │ Path │ jest > @jest/core > micromatch > minimatch │ ├───────────────┼──────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/1673 │ └───────────────┴──────────────────────────────────────────────────┘

SBOM - Software Bill of Materials

SBOM je formální seznam všech komponent, knihoven a modulů ve vašem software. Je to jako "seznam ingrediencí" vaší aplikace.

Proč je SBOM důležité?

SBOM standardy

Generování SBOM s CycloneDX

# Instalace CycloneDX CLI pro Node.js npm install -g @cyclonedx/cyclonedx-npm # Generování SBOM v CycloneDX formátu cyclonedx-npm --output-file sbom.json # SBOM obsahuje: # - Všechny závislosti (přímé i tranzitivní) # - Verze a licence # - Hashes (checksums) pro integritu # - CPE identifikátory pro CVE lookup # Integrace do CI/CD cyclonedx-npm --output-file sbom.xml --output-format XML # Uložení SBOM jako artifact pro audit trail

✅ Best Practice: SBOM v každém releasu

Generujte a ukládejte SBOM při každém production release. To umožňuje retroaktivní analýzu, pokud je objevena nová zranitelnost v knihovně, kterou jste používali v minulosti.

Integrace SCA do CI/CD pipeline

SCA by mělo být integrováno do každé fáze vývojového cyklu:

1. Pre-commit / IDE integrace

2. CI/CD pipeline (Continuous Integration)

# GitHub Actions příklad name: Security Scan on: [push, pull_request] jobs: dependency-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Run npm audit run: npm audit --audit-level=high - name: Run Snyk uses: snyk/actions/node@master env: SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} with: args: --severity-threshold=high - name: Generate SBOM run: | npm install -g @cyclonedx/cyclonedx-npm cyclonedx-npm --output-file sbom.json - name: Upload SBOM artifact uses: actions/upload-artifact@v3 with: name: sbom path: sbom.json

3. GitLab CI/CD příklad

dependency_scanning: stage: test image: node:18 script: # npm audit - npm audit --audit-level=moderate || true # OWASP Dependency-Check - wget https://github.com/jeremylong/DependencyCheck/releases/download/v8.0.0/dependency-check-8.0.0-release.zip - unzip dependency-check-8.0.0-release.zip - ./dependency-check/bin/dependency-check.sh --project "MyApp" --scan . --format HTML --format JSON # Snyk - npm install -g snyk - snyk auth $SNYK_TOKEN - snyk test --json > snyk-report.json artifacts: reports: dependency_scanning: snyk-report.json paths: - dependency-check-report.html

4. Continuous Monitoring

SCA Best Practices

✅ Doporučené postupy

  • Automatizujte skenování: Každý commit a PR by měl projít SCA checkemi
  • Nastavte severity thresholdy: Blokujte buildy s critical/high zranitelnostmi
  • Používejte lockfiles: package-lock.json, yarn.lock, Pipfile.lock pro reprodukovatelné buildy
  • Pravidelně aktualizujte: Nečekejte na kritické CVE, aktualizujte preventivně
  • Minimalizujte závislosti: Méně závislostí = menší attack surface
  • Ověřujte integrity: Používejte checksums a signed packages
  • Monitorujte production: Runtime monitoring pro supply chain útoky
  • Vytvářejte SBOM: Pro každý release a uchovávejte historii
  • Vendor security: Kontrolujte bezpečnostní historii knihoven před přidáním
  • Private registry: Zvažte interní Artifactory/Nexus pro kontrolu artefaktů

⚠️ Časté chyby při SCA

  • Ignorování false positives: Časem ztratíte důvěru v nástroj
  • Žádný remediation proces: SCA bez akce je zbytečné
  • Skenování pouze production deps: DevDependencies také mohou obsahovat zranitelnosti
  • Automatické aktualizace bez testů: Breaking changes mohou rozbít aplikaci
  • Zapomínání na tranzitivní závislosti: 70%+ závislostí jsou tranzitivní

SCA a další DevSecOps nástroje

SCA je jen jedna vrstva security testing. Pro komplexní bezpečnost kombinujte s:

Nástroj Co testuje Kdy použít
SCA Zranitelnosti v závislostech Každý commit, před přidáním nové závislosti
SAST Zranitelnosti ve vlastním kódu Během vývoje, v CI/CD
DAST Runtime zranitelnosti v běžící aplikaci Staging/QA environment před production
Container Scanning Zranitelnosti v base images a layers Před push do registry, v runtime
IaC Security Misconfigurace v Terraform/CloudFormation Před aplikací infrastrukturních změn

Související témata