Catene di fornitura software La porta silenziosa

Management Summary

Gli attacchi tramite dipendenze non sono più un tema marginale, ma la scorciatoia più comoda verso il cuore dell’IT moderna. La verità: la maggior parte degli ambienti conosce la propria catena di fornitura software solo in modo frammentario. I gestori di pacchetti risolvono transitivamente, il CI/CD distribuisce diligentemente, e nessuno si accorge quando un componente viene avvelenato. Chi vuole davvero ridurre il rischio ha bisogno di tre cose: SBOM completa, politiche rigorose di Supply-Chain-Security e un’operatività che applichi aggiornamenti e blocklist con coerenza – senza discuterli.

Perché le catene di fornitura sono così vulnerabili

• Le dipendenze esplodono: un singolo servizio porta rapidamente con sé centinaia di pacchetti transitivi.
• Fiducia implicita: registri e mirror vengono trattati silenziosamente come “ok”.
• Vettori di attacco: typosquatting, dependency confusion, account di maintainer compromessi, script post-install malevoli, build-image avvelenate, CI-secrets trapelati.
• Mancanza di visibilità: senza SBOM e prove di provenienza nessuno sa cosa gira davvero – e dove applicare le patch.

In breve: il problema non è il singolo “pacchetto cattivo”, ma la mancanza di prove lungo la catena.

Controlli minimi che funzionano subito

1. SBOM come documento operativo, non come PDF decorativo

   • Generate SBOM per servizio e per build (non solo per repo).
   • Versionatele nell’artifact store, collegatele a ticket/modifiche.
   • Riferimenti a licenze, stato CVE, criticità e owner.

2. Igiene dei repository & policy sui pacchetti

   • Allowlist di registri, namespace e firme.
   • Version-pinning rigoroso; niente “latest”.
   • Blocklist per librerie dannose note, fail-build automatico.
   • Secret-scanning e firme dei commit in tutti i repo.

3. Provenance & integrità

   • Prove di “chi ha costruito cosa quando” (es. attestazioni sugli artefatti).
   • Build riproducibili, hash immutabili degli artefatti, approvazioni a quattro occhi in CI/CD.
   • Diritti minimi per i build-token, durate brevi, rotazione obbligatoria.

4. Operatività di update invece di speranza negli update

   • Dependency-PR automatizzate con labeling del rischio.
   • Fix-SLO dopo esposizione (Internet vs. interno) e criticità.
   • Percorso “break-glass” per rollback rapidi con fasi canary.

KPI che rendono visibile la maturità

• Copertura SBOM: % di servizi con SBOM aggiornata (precisa per build, ≤7 giorni).
• Time-to-Upgrade: tempo mediano fino alla patch per librerie critiche (esposte a Internet vs. interne).
• Pinned-Rate: quota di dipendenze rigidamente pinnate senza wildcard.
• Quota di Provenance: % di artefatti con origine firmata e prova hash.
• Hit di Blocklist: numero di build bloccate dalla policy – sì, qui i “fallimenti” sono un buon segno.
• Secret-Leaks: ritrovamenti al mese, tempo fino alla rotazione.

Queste metriche devono stare nello stesso steering di MTTD/MTTR – altrimenti la sicurezza della supply chain resta folklore.

Piano a 90 giorni (pragmatico, senza vendor lock-in)

Giorno 0–15 – Inventario & policy

• Inventariare i servizi, segnare i percorsi critici (Auth, Payment, Admin).
• Definire la policy dei pacchetti: registri consentiti, namespace, firme, regole di pinning, blocklist.
• Verificare i CI/CD-secrets: ridurre i diritti, accorciare le durate, pianificare la rotazione.

Giorno 16–45 – Visibilità & criteri di stop

• Attivare la generazione di SBOM integrata nel build e salvarla nell’artifact store.
• Rendere obbligatori attestati di provenance e hash degli artefatti; build interrotta se mancanti.
• Attivare secret-scanning e firme dei commit; fail-build in caso di ritrovamenti/unsigned.

Giorno 46–75 – Operatività di fix & esercitazione

• Attivare update-PR automatiche; inserire labeling del rischio (criticità/exposure).
• Applicare tecnicamente i Fix-SLO (es. auto-escalation in caso di ritardi).
• Drill: ritrovamento simulato di pacchetto malevolo → blocco, rollback, post-mortem con tempi.

Giorno 76–90 – Ancorare & contratti

• Confrontare i KPI con la baseline, rafforzare le misure.
• Requisiti minimi contrattuali nella Supply-Chain-Security: obbligo di consegna SBOM, contatto di emergenza 24/7, tempi di notifica, partecipazione ai drill.
• Riportare le lessons learned in policy e pipeline.

Governance senza teatro

• Un unico source of truth: SBOM, policy-files, attestati, blocklist – centrali, versionati, a prova di revisione.
• “No evidence, no deploy”: nessuna release senza SBOM e provenance.
• Visione N-tier: anche i sub-fornitori critici devono fornire SBOM/attestati – altrimenti niente accesso ai percorsi core.
• Security come gate nello SDLC: senza gate superato niente go-live, anche se la deadline della feature incombe.

Conclusione: prove invece di sensazioni

La catena di fornitura software è sicura solo quanto sono solide le sue prove. Con SBOM pulita, policy sui pacchetti rigorosa, provenance firmata e Fix-SLO applicati, il rischio diminuisce – in modo misurabile. Open Source resta un vantaggio competitivo se fate rispettare le regole. Altrimenti è un invito.