Verifica cosa entra nel rilascio

Chiedi se la dipendenza serve

Un agente può suggerire un pacchetto che sembra risolvere un problema. Il suggerimento è una proposta, non una prova che il pacchetto esista o sia adatto. Verifica registry, editore, nome del pacchetto e versione esatti prima dell’installazione.

Per un’esportazione CSV fittizia, il runtime potrebbe già offrire il comportamento necessario. Un nuovo pacchetto può comunque essere appropriato, ma aggiunge manutenzione e percorsi di esecuzione. Confronta il lavoro di implementazione con le responsabilità continuative della dipendenza.

Esamina la licenza e il runtime compatibile. Controlla l’attività di manutenzione e gli avvisi di sicurezza pertinenti. Un nome familiare può riferirsi a un pacchetto diverso in un altro registry. Un’installazione riuscita mostra solo che l’installazione è terminata.

Esamina il comportamento di installazione e build

Le dipendenze possono eseguire codice durante installazione o build. Limita credenziali e accesso di rete in questi ambienti. Non esporre segreti di produzione a un job che elabora una pull request non attendibile.

Usa un lockfile versionato quando l’ecosistema lo prevede. Richiedi che la build lo rispetti. Esamina le modifiche al lockfile insieme al sorgente, inclusi pacchetti transitivi inattesi. Fissare le versioni migliora la riproducibilità, ma non rende sicura una versione vulnerabile.

L’SSDF del NIST copre la protezione del software e le pratiche di sviluppo lungo il ciclo di vita. Usa questa prospettiva più ampia quando progetti l’ambiente di build. Leggi il framework.

Distingui inventario e provenienza

Una software bill of materials, o SBOM, registra i componenti del software. Aiuta a individuare i rilasci interessati quando un componente presenta un problema. Non dimostra da sola che i componenti siano sicuri.

La provenienza riguarda come è stato prodotto un artefatto. SLSA definisce un formato di provenance per informazioni sulla build e i suoi input. La verifica deve collegare queste informazioni a un produttore attendibile e all’artefatto da usare. Un file chiamato «provenance» non basta. SLSA provenance.

Per il servizio di esportazione, registra una catena esaminabile:

1. Il commit revisionato identifica il sorgente accettato.
2. La build identifica input e ambiente di esecuzione.
3. L’artefatto ha un digest stabile.
4. Le verifiche identificano l’artefatto o il sorgente esaminato.
5. Il deployment registra l’artefatto inserito nell’ambiente di destinazione.

Evita di ricompilare in modo diverso dopo l’approvazione senza un processo di verifica definito. Un tag modificabile come latest può riferirsi in seguito a un’immagine diversa.

Decidi cosa significa una segnalazione

Una vulnerabilità rilevata richiede contesto: versione interessata, comportamento raggiungibile, esposizione, correzione disponibile e conseguenza. Registra le prove alla base di ogni eccezione temporanea. Assegna responsabile, scadenza e condizione di revisione.

Non disattivare un intero scanner perché una segnalazione non è applicabile. Non dichiarare un risultato senza problemi se la scansione non è terminata. Un timeout, un pacchetto non gestito o una fonte di avvisi indisponibile costituiscono prove mancanti.

Infine, pianifica gli aggiornamenti dopo il rilascio. Nuovi avvisi possono riguardare l’artefatto accettato ieri. Il responsabile del servizio ha bisogno di un inventario, un processo di risposta e capacità per produrre un rilascio corretto.

Prosegui con la gestione continua delle vulnerabilità per collegare scansioni ripetute e correzioni verificate in produzione.