Risorse · 16
Garanzia della catena di fornitura del software: dai componenti al rilascio
Collegare componenti, provenienza, build, vulnerabilità e aggiornamenti a ogni rilascio effettivamente distribuito.
Aggiornato · 3 min
Obiettivi di questa guida
- Conosci le dipendenze effettivamente distribuite.
- Verifica l'origine degli artefatti.
- Assegna priorità ai difetti nel contesto.
- Testa la sostituzione e il rollback.
Verifica rapida
- La distinta base corrisponde alla versione distribuita?
- Sono incluse le dipendenze transitive?
- Chi può firmare una release?
- Una vulnerabilità è raggiungibile nel tuo utilizzo?
- Un componente critico può essere rimosso senza improvvisazioni?
Metodo passo passo
- 1
Mappa le release distribuite.
Identifica repository, dipendenze dirette e transitive, strumenti di build, immagini, servizi esterni e proprietari. Collega tutti questi elementi a una release verificabile.
Risultato: mappa di prodotto, componente, versione e proprietario.
- 2
Generare una distinta base utilizzabile
Generare una distinta base per ogni release e confrontarla con gli artefatti effettivamente distribuiti. Risolvere nomi errati, versioni mancanti e componenti interni.
Risultato: distinta base datata e validata.
- 3
Proteggere la build
Limitare i diritti di pubblicazione, isolare le fasi sensibili e conservare la provenienza, i digest e le firme. Verificare queste prove prima del deployment.
Risultato: registro di build e policy di verifica.
- 4
Gestire gli avvisi
Collegare ogni avviso di vulnerabilità al componente, alla versione, all'esposizione e all'utilizzo effettivo. Assegnare un responsabile, una scadenza, una decisione e una prova di chiusura.
Risultato: coda di gestione contestuale.
- 5
Simulare la modifica
Sostituire un componente critico in un ambiente di test, verificare i percorsi aziendali e simulare il rollback. Misurare le dipendenze che bloccano la modifica.
Risultato atteso: rapporto sulle esercitazioni di sostituzione e di fallback.
- 6
Conservare la documentazione.
Esaminare i componenti e i fornitori in occasione di rilasci importanti e dopo gli incidenti. Conservare la documentazione per un periodo che supporti l'indagine e la correzione.
Risultato atteso: revisione del calendario e della cronologia dei rilasci.
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Copertura SBOM | Release distribuite con inventario dei componenti verificato | Risoluzione delle discrepanze prima della pubblicazione |
| Provenienza verificata | Artefatti controllati prima del deployment | Blocco delle release prive delle prove previste |
| Tempo di triage | Tempo intercorso tra la notifica pertinente e la decisione documentata | Escalation dei componenti esposti |
| Reversibilità | Sostituzioni critiche testate con rollback | Rimozione delle dipendenze bloccanti |
Errori comuni
- Confusione tra l'inventario del repository e i componenti distribuiti
- Mantenimento di un SBOM senza aggiornarlo
- Classificazione di un difetto solo in base al punteggio
- Firma di un artefatto senza verificarne la provenienza della build
Domande frequenti
Un SBOM è sufficiente?
No. Aiuta a identificare i componenti, ma è necessario verificare anche la provenienza, l'integrità, l'esposizione e la capacità di aggiornamento.
Ogni vulnerabilità dovrebbe bloccare il rilascio?
Decidere in base all'utilizzo effettivo, all'esposizione, ai controlli compensativi e alla criticità aziendale, e documentare le motivazioni.
Quale framework di riferimento è utile?
Il framework NIST Secure Software Development offre pratiche di sviluppo sicuro e protezione del software lungo tutto il ciclo di vita.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
