04 - SCA - Software Composition Analysis e Dependency Vulnerabilities

SCA: Cos'è la Software Composition Analysis

SCA (Software Composition Analysis) e la pratica di analizzare le dipendenze open source di un progetto per identificare vulnerabilità note, problemi di licenza e rischi nella supply chain del software. Con oltre il 90% del codice moderno che utilizza componenti open source, la sicurezza delle dipendenze e diventata un aspetto critico.

A differenza di SAST che analizza il codice scritto dal team, SCA si concentra sul codice importato: librerie npm, pacchetti pip, dipendenze Maven, gem Ruby e qualsiasi altro componente di terze parti. Una singola vulnerabilità in una libreria diffusa può esporre migliaia di applicazioni, come dimostrato dagli incidenti Log4Shell e XZ Utils.

In questo articolo esploreremo gli strumenti SCA principali, la gestione delle dipendenze transitive, il tracking delle licenze e le strategie per mantenere le dipendenze aggiornate.

Il Problema delle Dipendenze Transitive

Un progetto tipico ha decine di dipendenze dirette, ma ognuna di queste porta con se le proprie dipendenze (transitive). Un progetto Node.js con 50 dipendenze dirette può avere 500-1000 dipendenze transitive nel node_modules.

Le vulnerabilità nelle dipendenze transitive sono particolarmente insidiose perchè il developer potrebbe non essere consapevole della loro esistenza. SCA analizza l'intero albero delle dipendenze, incluse quelle transitive, per garantire una copertura completa.

Snyk: SCA Integrato per Developer

Snyk e una piattaforma SCA moderna che si integra direttamente nel workflow del developer. Offre un piano gratuito per progetti open source e una developer experience eccellente con integrazione IDE, CLI e CI/CD.

Snyk CLI: Analisi da Terminale

# Installare Snyk CLI
npm install -g snyk

# Autenticarsi
snyk auth

# Analizzare le dipendenze del progetto
snyk test

# Analizzare e monitorare (registra nel dashboard)
snyk monitor

# Analizzare un Dockerfile
snyk container test node:18-alpine

# Analizzare codice IaC
snyk iac test terraform/

# Output in formato JSON per automazione
snyk test --json --severity-threshold=high > snyk-results.json
      

Integrazione Snyk in GitHub Actions

# .github/workflows/snyk.yml
name: Snyk Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install dependencies
        run: npm ci

      - name: Snyk Test
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high --fail-on=all

      - name: Snyk Monitor
        if: github.ref == 'refs/heads/main'
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: monitor
      

Dependabot: Aggiornamenti Automatici di GitHub

Dependabot e il servizio integrato di GitHub che monitora le dipendenze e crea automaticamente pull request per aggiornare le versioni vulnerabili. La configurazione e semplice e avviene tramite un file YAML nel repository.

# .github/dependabot.yml
version: 2
updates:
  # Dipendenze npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Europe/Rome"
    open-pull-requests-limit: 10
    reviewers:
      - "security-team"
    labels:
      - "dependencies"
      - "security"
    ignore:
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]
    groups:
      dev-dependencies:
        dependency-type: "development"
        update-types:
          - "minor"
          - "patch"

  # GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  # Docker
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
      

OWASP Dependency-Check

OWASP Dependency-Check e uno strumento SCA open source che identifica le dipendenze del progetto e verifica se hanno vulnerabilità note nel National Vulnerability Database (NVD). Supporta Java, .NET, Node.js, Python, Ruby e molti altri ecosistemi.

# .github/workflows/dependency-check.yml
name: OWASP Dependency Check
on:
  push:
    branches: [main]
  schedule:
    - cron: "0 6 * * 1"  # Ogni lunedi alle 6:00

jobs:
  dependency-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: OWASP Dependency Check
        uses: dependency-check/Dependency-Check_Action@main
        with:
          project: "my-application"
          path: "."
          format: "HTML"
          args: >
            --failOnCVSS 7
            --enableRetired
            --nvdApiKey ${{ secrets.NVD_API_KEY }}

      - name: Upload Report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: dependency-check-report
          path: reports/
      

Database di Vulnerabilità

Gli strumenti SCA si basano su database di vulnerabilità note per identificare le dipendenze problematiche. I principali database sono:

Gestione delle Licenze Open Source

Oltre alle vulnerabilità, SCA analizza le licenze delle dipendenze per garantire la compliance legale. Alcune licenze open source (come GPL e AGPL) hanno requisiti di copyleft che possono avere implicazioni significative per software commerciale.

• Permissive (MIT, Apache 2.0, BSD): libero utilizzo, poche restrizioni
• Weak Copyleft (LGPL, MPL): modifiche alla libreria devono essere rilasciate con la stessa licenza
• Strong Copyleft (GPL, AGPL): tutto il software derivato deve essere rilasciato con la stessa licenza
• Proprietarie/Non-standard: richiedono revisione legale caso per caso

Strategie di Aggiornamento delle Dipendenze

Mantenere le dipendenze aggiornate e una sfida continua. Ecco le strategie che raccomandiamo:

1. Patch Automatiche per Vulnerabilità Critiche

Configurare Dependabot o Renovate per creare automaticamente PR per aggiornamenti di sicurezza. Le patch di sicurezza (minor/patch version) possono essere merge automaticamente se i test passano, riducendo il tempo di esposizione.

2. Aggiornamenti Raggruppati Settimanali

Raggruppare gli aggiornamenti non critici in una singola PR settimanale per ridurre il rumore e facilitare la review. Dependabot supporta i gruppi nativamente.

3. Major Version con Pianificazione

Gli aggiornamenti major version (breaking changes) devono essere pianificati e testati manualmente. Ignorare i major updates automatici e dedicare tempo specifico nello sprint.

4. Lock File e Reproducibilita

Utilizzare sempre i lock file (package-lock.json, yarn.lock, Pipfile.lock) per garantire build riproducibili e usare npm ci invece di npm install nella CI.

SCA nella Pipeline: Workflow Completo

# .github/workflows/sca-complete.yml
name: SCA Complete Workflow
on:
  push:
    branches: [main]
  pull_request:

jobs:
  vulnerability-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install dependencies
        run: npm ci

      - name: npm audit
        run: npm audit --audit-level=high

      - name: Snyk vulnerability scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: License check
        run: npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"
      

Best Practice per SCA

1. Scansione ad ogni build: ogni pipeline deve includere un controllo SCA, non solo i build notturni
2. Monitoraggio continuo: registrare i progetti in Snyk/Dependabot per ricevere alert quando vengono scoperte nuove CVE
3. Policy di licenze: definire e automatizzare le policy di licenze accettabili
4. Dipendenze minime: valutare criticamente ogni nuova dipendenza. Meno dipendenze significa meno superficie di attacco
5. Pin delle versioni: utilizzare versioni esatte nei lock file, non range
6. Audit regolari: revisione trimestrale delle dipendenze per rimuovere quelle non utilizzate

Conclusioni

SCA e un pilastro fondamentale di DevSecOps, particolarmente critico nell'era del software open source. La combinazione di vulnerability scanning, license compliance e aggiornamenti automatizzati protegge il progetto dalle minacce nella supply chain del software.

Nel prossimo articolo esploreremo Container Security, analizzando come proteggere le immagini Docker, implementare image scanning con Trivy e Grype, e configurare runtime protection per i container in produzione.