Skip to main content

​
Finalità

CaseBender è utilizzato dai team di sicurezza; per questo motivo, la sicurezza del prodotto è considerata un requisito di release e non una checklist da completare una sola volta. Il Programma di garanzia della sicurezza combina workflow di sviluppo protetti, test di sicurezza automatizzati, controlli su container e dipendenze, provenienza delle release, eccezioni documentate e pianificazione di valutazioni indipendenti. Questa sezione illustra:
  • quali controlli vengono eseguiti automaticamente;
  • quali rilevamenti bloccano una modifica o una release;
  • quali evidenze produce ciascun controllo;
  • come vengono gestite le eccezioni;
  • cosa possono verificare autonomamente i clienti; e
  • dove terminano le garanzie fornite dall’automazione.
La garanzia della sicurezza riduce il rischio, ma non dimostra che il software sia privo di vulnerabilità. I badge dei workflow, i report degli scanner, le SBOM e le firme costituiscono evidenze di controlli specifici, non certificazioni di sicurezza né sostituti di un penetration test indipendente.

​
La garanzia in sintesi

Modifiche protette

Le pull request verso i branch protetti devono superare un gate di sicurezza aggregato prima del merge. Documentazione disponibile in inglese.

Test multilivello

Secret, codice sorgente, dipendenze, licenze, infrastruttura e tutte le immagini dei servizi vengono verificati tramite strumenti indipendenti.

Integrità delle release

I workflow di release generano SBOM, provenienza, digest immutabili e firme crittografiche. Documentazione disponibile in inglese.

Evidenze per i clienti

I clienti possono individuare le evidenze associate a un commit, al digest di un’immagine o a una release.

​
Ciclo di vita sicuro delle modifiche

Ogni modifica proposta segue lo stesso ciclo di vita generale:
I controlli sono intenzionalmente organizzati su più livelli. Ad esempio, il rischio relativo alle dipendenze viene valutato sia attraverso il database degli avvisi del package manager sia tramite Trivy; le immagini container vengono analizzate dopo la compilazione; inoltre, controlli negativi deterministici verificano che gli scanner per secret e SAST continuino a rifiutare fixture note come non sicure.

​
Quando vengono eseguiti i controlli

La definizione del workflow, e non questa pagina, costituisce la fonte tecnica definitiva per i trigger e la configurazione esatta degli strumenti. I revisori autorizzati del repository possono consultare il workflow Security Scan; i clienti senza accesso al repository devono utilizzare le evidenze specifiche della release descritte nella Guida alle evidenze di sicurezza.

​
Gate di sicurezza che blocca il merge

Il Security Gate aggregato richiede che i seguenti job vengano completati correttamente per pull request e push: Il caricamento dei risultati degli scanner può avvenire in modalità best effort quando GitHub Code Security non è incluso nella licenza, ma la scansione locale sottostante continua a essere bloccante. I report vengono inoltre conservati come artefatti del workflow, affinché il gate non dipenda dall’acquisizione SARIF.

​
Test dinamici della sicurezza

Il job DAST settimanale utilizza OWASP ZAP su un deployment di staging dedicato. Prima dell’avvio dei test attivi, la CI verifica che:
  1. la destinazione non sia un placeholder, localhost o un indirizzo di loopback;
  2. la risposta identifichi un deployment web di CaseBender;
  3. l’identità di test configurata produca una sessione autenticata; e
  4. l’header di autenticazione venga fornito tramite secret del repository mascherati.
La scansione esegue test attivi autenticati e ne conserva il report. La mancanza della destinazione o delle credenziali causa il fallimento del job DAST, invece di eseguire silenziosamente la scansione di una pagina non pertinente. La copertura DAST è limitata dalle route e dallo stato raggiungibili dall’identità di test. Non sostituisce i test manuali relativi ad autorizzazione, isolamento dei tenant, abuso dei workflow, parser o integrazioni.

​
Garanzia dei container

CaseBender produce attualmente sette immagini di servizio. Ogni Dockerfile di produzione utilizza una build multistage e un utente runtime non root. Il percorso di garanzia dei container comprende:
  • linting dei Dockerfile;
  • pruning delle dipendenze di produzione;
  • scansione delle vulnerabilità prima della pubblicazione;
  • rilevamento di secret incorporati tramite la scansione delle immagini;
  • selezione del digest immutabile dopo la pubblicazione;
  • firma Cosign keyless tramite l’identità OIDC di GitHub; e
  • verifica della firma rispetto all’esatto digest pubblicato.
I workflow di Docker Hub e GitHub Container Registry firmano il digest effettivamente scaricato dai clienti, anziché fare affidamento esclusivamente su tag mutabili come latest.

​
Evidenze della supply chain del software

I workflow di release generano diversi record complementari:
  • CycloneDX SBOM — inventario di pacchetti e componenti per l’analisi delle dipendenze;
  • BuildKit SBOM and provenance — metadati di build emessi durante la compilazione dei container;
  • Cosign signature — identità crittografica associata a un digest di immagine immutabile;
  • SBOM attestation — associazione firmata tra un’immagine e il relativo inventario dei componenti;
  • SLSA-format provenance document — revisione del codice sorgente, identità del workflow e metadati dell’invocazione; e
  • Scanner reports — output SARIF o JSON conservato dal workflow pertinente.
Il documento autonomo in formato SLSA contiene metadati di build firmati. Il relativo subject è attualmente vuoto; pertanto, il documento non è associato crittograficamente ai sette digest delle immagini e non deve essere presentato come provenienza a livello di artefatto né come certificazione SLSA indipendente.

​
Gestione delle vulnerabilità

I rilevamenti vengono sottoposti a triage in base a severità, sfruttabilità, modalità di deployment interessata, esposizione e disponibilità di patch. Gli obiettivi predefiniti di remediation documentati dal progetto sono: Si tratta di obiettivi interni di remediation, non di livelli di servizio contrattuali, salvo che siano inclusi in un accordo con il cliente. Quando una remediation immediata non è possibile, un’eccezione deve avere un ambito circoscritto ed essere verificabile. Le eccezioni Trivy IaC correnti sono archiviate in .trivyignore.yaml e includono il rilevamento, il percorso interessato, la giustificazione e la data di scadenza. Le eccezioni relative alle licenze sono specifiche per ciascun pacchetto; la policy non sopprime globalmente un identificatore di licenza. Il file del repository non deve essere interpretato come un registro completo di ogni categoria di rischio di prodotto accettato.

​
Integrità degli strumenti e dei workflow

Anche i controlli stessi sono protetti:
  • le GitHub Actions di terze parti sono vincolate a SHA di commit immutabili;
  • i principali file binari degli scanner e le immagini container sono vincolati a una versione o a un digest;
  • le installazioni basate su lockfile utilizzano --frozen-lockfile;
  • i controlli di sicurezza negativi rilevano se uno scanner smette inaspettatamente di rifiutare input noti come non sicuri;
  • le impostazioni correnti di protezione dei branch GitHub rifiutano gli aggiornamenti diretti che non hanno prodotto gli status check richiesti; questa policy è amministrata al di fuori del repository del codice sorgente; e
  • i job aggregati non vengono completati correttamente se un job di sicurezza richiesto fallisce, viene annullato o viene inaspettatamente ignorato.

​
Euristica supplementare contro il malware

Un workflow post-merge separato monitora su main le modifiche ai file di configurazione Next.js e PostCSS alla ricerca di pattern noti di attacchi alla supply chain npm e può creare un revert automatico. Si tratta di un controllo di ripristino circoscritto e basato su pattern. Non è un gate per le pull request, un motore antivirus, un controllo EDR o una scansione completa alla ricerca di malware.

​
Responsabilità dei clienti

CaseBender può essere distribuito su infrastrutture gestite dal cliente. La garanzia del prodotto non sostituisce la gestione sicura di tale ambiente. I clienti rimangono responsabili di:
  • certificati TLS, ingress, firewall e segmentazione della rete;
  • configurazione del provider di identità, dell’MFA e dei ruoli;
  • hardening del database, di Redis, dell’object storage e del servizio di ricerca;
  • rotazione dei secret e accesso alle credenziali di deployment;
  • backup, monitoraggio, conservazione e risposta agli incidenti;
  • applicazione degli aggiornamenti supportati e revisione delle note di release; e
  • convalida dei controlli rispetto al proprio contesto normativo e alle minacce pertinenti.
Consultare la Guida all’hardening del deployment (disponibile in inglese) per le raccomandazioni operative.

​
Limiti attuali della garanzia

A luglio 2026:
  • sono implementati workflow automatizzati per SAST, SCA, secret, licenze, IaC, container, SBOM, firma e provenienza;
  • il DAST autenticato sull’ambiente di staging è configurato nella CI, ma dipende dal mantenimento di una destinazione di staging e di un’identità di test;
  • le funzionalità SARIF e Dependency Review ospitate da GitHub dipendono dalla licenza del repository, mentre i gate locali di Trivy e di audit dei pacchetti rimangono disponibili;
  • non si dichiara la disponibilità di un report completo di penetration test di terze parti né di una lettera di retest della remediation; e
  • le mappature di conformità descrivono l’allineamento dei controlli, non una certificazione indipendente.
L’ambito proposto per la valutazione indipendente è documentato in Ambito del penetration test indipendente (disponibile in inglese).

​
Documentazione correlata