Una vulnerabilita trovata mentre si scrive codice costa a uno sviluppatore pochi minuti per essere corretta. La stessa vulnerabilita individuata in produzione costa uno sprint. E se un attaccante la trova per primo, costa milioni. Questo e l'argomento centrale della shift-left security - spostare i controlli di sicurezza il prima possibile nel ciclo di vita dello sviluppo.

Il DevSecOps prende questa idea e la trasforma in una pratica: la sicurezza non e una fase separata alla fine, ma un processo continuo integrato in ogni fase dello sviluppo, dalla prima riga di codice al deploy in produzione.

Il costo della sicurezza tardiva

Il report Cost of a Data Breach di IBM ha costantemente dimostrato che il costo per risolvere i problemi di sicurezza cresce esponenzialmente quanto piu tardi vengono individuati:

Fase	Costo di correzione	Tempo di correzione
IDE / Sviluppo locale	Minuti	Secondi o minuti
Code review / PR	Ore	Minuti o ore
Pipeline CI/CD	Giorni	Ore o giorni
Staging / QA	Settimane	Giorni
Produzione	Mesi	Settimane o mesi
Post-breach	Milioni ($)	Mesi o anni

La conclusione e chiara: ogni fase in cui anticipi la sicurezza fa risparmiare un ordine di grandezza in costi e tempo.

La pipeline DevSecOps

Una pipeline DevSecOps matura integra controlli di sicurezza in ogni fase:

Analizziamo ogni fase con strumenti e configurazioni concreti.

Fase 1: sicurezza nell'IDE

Il ciclo di feedback piu rapido. Individua le vulnerabilita prima ancora di salvare il file.

Strumenti consigliati

• Semgrep: analisi statica leggera con regole della community per le vulnerabilita OWASP
• Snyk IDE Extension: scansione in tempo reale delle vulnerabilita delle dipendenze
• GitLens + GitLeaks: rileva i secret nel tuo editor
• ESLint Security Plugins: eslint-plugin-security per Node.js, eslint-plugin-no-unsanitized per DOM XSS

Esempio: configurazione ESLint per la sicurezza

{
  "extends": ["eslint:recommended"],
  "plugins": ["security", "no-unsanitized"],
  "rules": {
    "security/detect-object-injection": "warn",
    "security/detect-non-literal-regexp": "warn",
    "security/detect-unsafe-regex": "error",
    "security/detect-buffer-noassert": "error",
    "security/detect-eval-with-expression": "error",
    "security/detect-no-csrf-before-method-override": "error",
    "security/detect-possible-timing-attacks": "warn",
    "no-unsanitized/method": "error",
    "no-unsanitized/property": "error"
  }
}

Fase 2: Pre-commit Hooks

La seconda linea di difesa. Si eseguono automaticamente prima di ogni commit, bloccando il codice pericoloso dall'entrare nel repository.

Gitleaks: intercetta i secret prima che finiscano in Git

L'errore di sicurezza piu comune nei codebase e il commit di secret - chiavi API, password di database, token. Una volta che un secret finisce nella cronologia di git, e estremamente difficile rimuoverlo completamente (anche con i force push, fork e cache potrebbero conservarlo).

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.0
    hooks:
      - id: gitleaks

  - repo: https://github.com/semgrep/semgrep
    rev: v1.90.0
    hooks:
      - id: semgrep
        args: ['--config', 'auto']

Installa e attiva:

pip install pre-commit
pre-commit install

Ora ogni git commit scansiona automaticamente alla ricerca di secret trapelati e vulnerabilita comuni. Se viene trovato qualcosa, il commit viene bloccato.

Regole Gitleaks personalizzate

Puoi aggiungere pattern personalizzati per i secret della tua organizzazione:

# .gitleaks.toml
title = "Custom Gitleaks Config"

[[rules]]
id = "internal-api-key"
description = "Internal API key detected"
regex = '''INTERNAL_KEY_[A-Za-z0-9]{32}'''
tags = ["key", "internal"]

Fase 3: sicurezza della pipeline CI/CD

Qui avviene il lavoro pesante. La tua pipeline CI dovrebbe eseguire piu scansioni di sicurezza su ogni pull request.

SAST (Static Application Security Testing)

Gli strumenti SAST analizzano il codice sorgente senza eseguirlo, cercando pattern che indicano vulnerabilita.

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

jobs:
  sast:
    name: Static Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/typescript
            p/nodejs
            p/react
          generateSarif: true

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

Il ruleset p/owasp-top-ten di Semgrep intercetta le vulnerabilita piu comuni: SQL injection, XSS, SSRF, path traversal, deserializzazione non sicura e altro.

SCA (Software Composition Analysis)

L'SCA scansiona le tue dipendenze alla ricerca di vulnerabilita note. Questo e fondamentale - oltre l'80% del codice delle applicazioni moderne proviene da dipendenze open-source.

  dependency-scan:
    name: Dependency Audit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

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

Sicurezza dei container con Trivy

Se costruisci immagini Docker, scansionarle alla ricerca di vulnerabilita e essenziale. Trivy e lo scanner di container open-source piu popolare.

  container-scan:
    name: Container Security
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t my-app:${{ github.sha }} .

      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-app:${{ github.sha }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      - name: Upload Trivy SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

Generazione SBOM

Una Software Bill of Materials (SBOM) e un inventario completo di ogni componente nella tua applicazione. E sempre piu richiesta dai framework di conformita e dalle normative governative (l'Executive Order statunitense sulla Cybersecurity impone la SBOM per il software federale).

  sbom:
    name: Generate SBOM
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM with Syft
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.spdx.json

Fase 4: immagini Docker sicure

Un'immagine Docker di produzione dovrebbe seguire il principio del minimo privilegio. Ecco come appare un Dockerfile rafforzato:

# Build stage
FROM node:22-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:22-alpine AS runner
WORKDIR /app

# Install dumb-init before dropping root
RUN apk add --no-cache dumb-init

# Don't run as root
RUN addgroup -S app && adduser -S app -G app

# Copy only what's needed
COPY --from=builder --chown=app:app /app/dist ./dist
COPY --from=builder --chown=app:app /app/node_modules ./node_modules
COPY --from=builder --chown=app:app /app/package.json ./

# Drop to non-root user
USER app
ENTRYPOINT ["dumb-init", "--"]

# Health check
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

EXPOSE 3000
CMD ["node", "dist/server.js"]

Pratiche chiave:

1. Usa build multi-stage: lo stage builder ha le dipendenze di sviluppo; lo stage runner ha solo il codice di produzione
2. Non eseguire come root: crea un utente non-root e passa a quello
3. Usa immagini Alpine: superficie di attacco ridotta (meno pacchetti installati di default)
4. Fissa le versioni delle immagini: node:22-alpine invece di node:latest per evitare attacchi alla supply chain
5. Usa npm ci: installazioni deterministiche dal lock file, non npm install

Fase 5: gestione dei secret

I secret hard-coded sono la causa numero uno delle violazioni negli incidenti causati dagli sviluppatori.

Cosa NON fare

// NEVER do this
const API_KEY = "sk-1234567890abcdef";
const DB_PASSWORD = "supersecret123";

const client = new Client({
  connectionString: `postgres://admin:${DB_PASSWORD}@db.example.com/prod`
});

Cosa fare invece

// Use environment variables
const client = new Client({
  connectionString: process.env.DATABASE_URL
});

// Or use a secret manager
import { SecretManagerServiceClient } from '@google-cloud/secret-manager';

const client = new SecretManagerServiceClient();
const [version] = await client.accessSecretVersion({
  name: 'projects/my-project/secrets/db-password/versions/latest',
});
const dbPassword = version.payload?.data?.toString();

Gerarchia della gestione dei secret

L'OWASP Top 10: un riferimento rapido

Ogni sviluppatore dovrebbe conoscere l'OWASP Top 10. Versione sintetica:

#	Vulnerabilita	Cos'e	Prevenzione
1	Broken Access Control	Utenti che accedono a risorse non autorizzate	Nega per default, valida lato server
2	Cryptographic Failures	Crittografia debole, dati in chiaro	Usa algoritmi robusti (AES-256, bcrypt), TLS ovunque
3	Injection	SQL, NoSQL, OS command injection	Query parametrizzate, validazione degli input
4	Insecure Design	Architettura con difetti	Threat modeling, secure design patterns
5	Security Misconfiguration	Credenziali di default, bucket cloud aperti	Default rafforzati, audit automatici della configurazione
6	Vulnerable Components	CVE note nelle dipendenze	Scansione SCA, aggiornamenti regolari
7	Auth Failures	Password deboli, sessioni compromesse	MFA, rate limiting, gestione sicura delle sessioni
8	Data Integrity Failures	Aggiornamenti non firmati, CI/CD non affidabile	Code signing, SBOM, integrita della pipeline
9	Logging Failures	Nessuna traccia di audit	Logging strutturato, alerting sulle anomalie
10	SSRF	Server-side request forgery	Allowlist degli URL in uscita, validazione degli input

Workflow completo di sicurezza con GitHub Actions

Un workflow completo e pronto per la produzione che combina tutto quanto sopra:

# .github/workflows/security.yml
name: Security Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write

jobs:
  secrets-scan:
    name: Secret Detection
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  sast:
    name: Static Analysis (SAST)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten p/typescript p/nodejs

  dependency-audit:
    name: Dependency Scan (SCA)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm audit --audit-level=high
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high
        continue-on-error: true

  container-scan:
    name: Container Scan
    runs-on: ubuntu-latest
    needs: [sast, dependency-audit]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: '1'

  sbom:
    name: SBOM Generation
    runs-on: ubuntu-latest
    needs: [container-scan]
    steps:
      - uses: actions/checkout@v4
      - uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

Metriche da monitorare

Come sapere se il tuo programma DevSecOps funziona? Monitora queste metriche:

• Mean time to remediate (MTTR): quanto velocemente correggi le vulnerabilita dopo il rilevamento
• Vulnerability escape rate: percentuale di vulnerabilita che raggiungono la produzione
• False positive rate: troppi falsi positivi portano ad affaticamento da alert e avvisi ignorati
• Dependency freshness: eta media delle tue dipendenze (piu vecchie = piu probabilita di CVE note)
• SBOM coverage: percentuale di progetti con SBOM aggiornate

Per iniziare: una roadmap pratica

Non provare a implementare tutto in una volta. Un approccio graduale funziona meglio:

Conclusione

Il DevSecOps non consiste nell'aggiungere piu strumenti alla tua pipeline - si tratta di rendere la sicurezza una parte naturale del modo in cui costruisci il software. L'obiettivo non e bloccare ogni PR con avvisi di sicurezza, ma dare agli sviluppatori un feedback rapido cosi che possano correggere i problemi mentre il codice e ancora fresco nella loro mente.

Inizia con le basi: pre-commit hooks per i secret, dependency scanning nella CI e container scanning per le immagini Docker. Poi itera in base alle esigenze del tuo team.

La sicurezza non e una funzionalita che rilasci una sola volta. E una pratica che integri in ogni commit.

Checklist iniziale DevSecOps:

• Pre-commit hooks Gitleaks installati
• File .env e secret nel .gitignore
• Semgrep SAST nella pipeline CI
• Snyk o npm audit per il dependency scanning
• Trivy per la scansione delle immagini container
• Utente non-root nei Dockerfile
• Secret nelle variabili d'ambiente o nel secret manager
• Generazione SBOM a ogni release
• Consapevolezza dell'OWASP Top 10 in tutto il team