> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # Guida alle evidenze di sicurezza > Guida per i clienti che esaminano report degli scanner, SBOM, firme, provenienza, eccezioni e stato delle valutazioni di CaseBender. ## 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 | Evidenza | Cosa dimostra | Limitazione importante | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Risultato del Security Gate | I job di sicurezza CI richiesti sono stati completati correttamente per una revisione | Copre esclusivamente i controlli automatizzati configurati | | Report/log Gitleaks | Nel codice sorgente e nella cronologia sottoposti a scansione non sono rimasti pattern corrispondenti a secret | Non può identificare ogni possibile formato di credenziale | | SARIF del filesystem Trivy | Rilevamenti relativi alle dipendenze per lo stato del repository sottoposto a scansione | I database degli avvisi e il rilevamento dei pacchetti cambiano nel tempo | | SARIF dei container Trivy | Rilevamenti relativi al sistema operativo e all'applicazione in un'immagine di servizio compilata | Si applica esclusivamente al digest sottoposto a scansione | | SARIF IaC Trivy | Rilevamenti nella configurazione Docker e Kubernetes | Non convalida tutte le impostazioni della piattaforma runtime | | SARIF Semgrep | Rilevamenti prodotti dalle regole configurate per l'analisi del codice sorgente e del taint | La copertura delle regole non equivale a una revisione manuale del codice | | JSON dell'audit delle dipendenze | Avvisi noti al registro dei pacchetti relativi alle dipendenze di produzione | Non copre i pacchetti del sistema operativo | | JSON delle licenze e risultato della policy | Licenze rilevate e decisioni della policy specifiche per pacchetto | L'interpretazione legale rimane specifica per ciascun cliente | | CycloneDX SBOM | Componenti rilevati per un repository o un'immagine | Una SBOM è un inventario, non una dichiarazione di assenza di vulnerabilità | | Firma Cosign | Un'identità del workflow ha firmato il digest di un'immagine specifica | La verifica della firma non valuta il comportamento dell'applicazione | | Attestazione SBOM | Una SBOM firmata è associata a un'immagine specifica | L'attestazione è accurata solo nella misura in cui lo è la generazione della SBOM | | Documento di provenienza in formato SLSA | Revisione del codice sorgente e metadati dell'invocazione della build | Il `subject` corrente è vuoto; il documento non è associato al digest di un'immagine né certificato in modo indipendente | | Report OWASP ZAP | Risultati ottenuti dalle route di staging autenticate raggiunte da ZAP | Non dimostra una copertura completa delle API o della logica di business | | Record di eccezione | Un rilevamento è stato intenzionalmente circoscritto, giustificato e dotato di una scadenza | Non elimina il rischio sottostante | ## Procedura di tracciabilità ### 1. Registrare il digest distribuito Utilizzare il registro o il runtime del container per acquisire il digest immutabile: ```bash theme={null} docker image inspect IMAGE:TAG \ --format='{{index .RepoDigests 0}}' ``` L'output previsto è simile al seguente: ```text theme={null} registry.example.com/casebender/web@sha256:... ``` ### 2. Verificare la firma I workflow di release di CaseBender utilizzano la firma Cosign keyless supportata da GitHub Actions OIDC: ```bash theme={null} cosign verify \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ IMAGE@sha256:DIGEST ``` 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. Verificare il blob firmato prima di fare affidamento sul suo contenuto: ```bash theme={null} cosign verify-blob \ --signature provenance.json.sig \ --certificate provenance.json.cert \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ provenance.json ``` ### 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: 1. identificatore della release e SHA del commit; 2. digest immutabili delle immagini di servizio distribuite; 3. risultato del workflow Security Gate; 4. risultati della scansione dei container per tali digest; 5. SBOM CycloneDX; 6. output della verifica della firma; 7. provenienza firmata e output della verifica; 8. record delle eccezioni attive applicabili; 9. riepilogo della remediation delle vulnerabilità; e 10. 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)](/en/security/penetration-test-scope). ## Segnalazione di un problema di sicurezza Segnalare le vulnerabilità sospette di CaseBender all'indirizzo [security@casebender.com](mailto: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 * [Programma di garanzia della sicurezza](/it/security/security-assurance) * [Sicurezza del codice (disponibile in inglese)](/en/security/code-security) * [Sicurezza della supply chain (disponibile in inglese)](/en/security/supply-chain) * [Guida all'hardening del deployment (disponibile in inglese)](/en/security/hardening-guide)