Panoramica
Le evidenze di sicurezza sono particolarmente utili quando possono essere ricondotte esattamente al software che il cliente sta valutando. CaseBender identifica le build tramite il commit Git e gli artefatti container tramite il digest immutabile.
Per una verifica delle garanzie, iniziare da uno dei seguenti elementi:
- una versione di release di CaseBender;
- lo SHA del commit Git indicato dalla release;
- il digest di ciascuna immagine container distribuita; oppure
- l’esecuzione del workflow che ha prodotto gli artefatti.
I tag come latest sono riferimenti pratici, ma non costituiscono identificatori stabili delle evidenze.
Catalogo delle evidenze
Procedura di tracciabilità
1. Registrare il digest distribuito
Utilizzare il registro o il runtime del container per acquisire il digest immutabile:
L’output previsto è simile al seguente:
2. Verificare la firma
I workflow di release di CaseBender utilizzano la firma Cosign keyless supportata da GitHub Actions OIDC:
La verifica deve essere eseguita rispetto a un digest, non soltanto a un tag. Il canale del registro e l’identità del certificato devono corrispondere alla documentazione della release fornita con l’artefatto.
3. Verificare i metadati di provenienza
Esaminare nel documento di provenienza:
- il repository e la revisione del codice sorgente;
- l’identità e il trigger del workflow;
- il timestamp della build e l’attore;
- il campo
subject e se identifica l’artefatto oggetto della verifica; e
- la firma e il certificato di firma allegati.
Il documento autonomo di provenienza di CaseBender ha attualmente un subject vuoto. Può essere verificato come metadato firmato del workflow, ma al momento non può dimostrare che un determinato digest di container sia stato prodotto da tale invocazione. Per la tracciabilità a livello di artefatto, utilizzare il digest del registro, la firma dell’immagine e l’attestazione SBOM dell’immagine.
4. Esaminare la SBOM
Utilizzare la SBOM per identificare i componenti diretti e transitivi pertinenti al deployment. I clienti possono importare il JSON CycloneDX nei propri strumenti di gestione delle vulnerabilità o degli asset software.
Una SBOM deve corrispondere allo stesso commit o digest di immagine oggetto della verifica. Una SBOM a livello di repository e una SBOM a livello di immagine rispondono a domande diverse e non devono essere considerate intercambiabili.
5. Esaminare i rilevamenti e le eccezioni di sicurezza
Verificare che:
- la scansione sia stata completata e non ignorata;
- il report corrisponda alla revisione o al digest di destinazione;
- sia nota la policy di severità utilizzata dal workflow;
- sia verificato se i rilevamenti privi di correzione sono stati esclusi dalla configurazione dello scanner;
- un’eventuale eccezione si applichi esattamente al rilevamento e al percorso in questione; e
- l’eccezione rientri ancora nel proprio periodo di revisione.
Conservazione degli artefatti
Le impostazioni correnti per la conservazione nei workflow includono:
- artefatti degli scanner e degli audit: generalmente 30 giorni;
- artefatti SBOM CycloneDX del repository e materiale di firma: 1.095 giorni; e
- firme e attestazioni del registro: conservate con l’artefatto pertinente del registro, nel rispetto della policy del ciclo di vita del registro.
La conservazione nell’ambiente del cliente è controllata dal cliente stesso. I clienti soggetti a requisiti di audit più lunghi devono archiviare il pacchetto di evidenze ricevuto per ogni release distribuita.
Pacchetto di evidenze suggerito per i clienti
Per una verifica delle garanzie di una release, il pacchetto pertinente può includere:
- identificatore della release e SHA del commit;
- digest immutabili delle immagini di servizio distribuite;
- risultato del workflow Security Gate;
- risultati della scansione dei container per tali digest;
- SBOM CycloneDX;
- output della verifica della firma;
- provenienza firmata e output della verifica;
- record delle eccezioni attive applicabili;
- riepilogo della remediation delle vulnerabilità; e
- dichiarazione corrente sullo stato dei penetration test.
La disponibilità può dipendere dalle autorizzazioni del repository, dal canale del registro, dalle finestre di conservazione degli artefatti e dalle condizioni contrattuali di divulgazione. I report non elaborati possono contenere percorsi del repository, dettagli sulle dipendenze o informazioni sull’infrastruttura e potrebbero richiedere un trasferimento sicuro o l’oscuramento di dati.
Interpretazione di un risultato positivo
Un workflow verde indica che i job configurati sono stati completati conformemente alla policy codificata in quella revisione. Non significa che:
- non esistano vulnerabilità;
- sia stato testato ogni percorso dell’applicazione;
- tutta l’infrastruttura distribuita corrisponda ai template sottoposti a scansione;
- ogni dipendenza sia esente da avvisi futuri;
- una terza parte abbia convalidato il risultato in modo indipendente; oppure
- la release sia certificata rispetto a un framework di conformità.
Per i deployment che richiedono garanzie più elevate, combinare le evidenze automatizzate con la revisione dell’architettura, l’hardening dell’ambiente del cliente, la modellazione delle minacce e test manuali indipendenti.
Evidenze dei penetration test
CaseBender non dichiara attualmente la disponibilità di un report completo di penetration test di terze parti né di una lettera di retest della remediation. I test ZAP automatizzati e la funzionalità di gestione dei penetration test integrata nel prodotto non sostituiscono tali evidenze.
L’incarico pianificato, le qualifiche richieste per i tester, le regole d’ingaggio e i risultati attesi sono documentati nell’Ambito del penetration test indipendente (disponibile in inglese).
Segnalazione di un problema di sicurezza
Segnalare le vulnerabilità sospette di CaseBender all’indirizzo security@casebender.com. Includere:
- la versione interessata o il digest dell’immagine;
- la modalità di deployment;
- passaggi riproducibili;
- il comportamento previsto e quello osservato;
- il potenziale impatto; e
- eventuale materiale proof-of-concept idoneo a una gestione sicura.
Non includere credenziali attive, dati dei clienti o materiale di exploit distruttivo in un messaggio iniziale non crittografato.
Documentazione correlata
