> ## 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.
# Programma di garanzia della sicurezza
> Come CaseBender testa le modifiche, blocca le regressioni di sicurezza, protegge gli artefatti di release e comunica ai clienti le evidenze di garanzia.
## 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
Le pull request verso i branch protetti devono superare un gate di sicurezza aggregato prima del merge. Documentazione disponibile in inglese.
Secret, codice sorgente, dipendenze, licenze, infrastruttura e tutte le immagini dei servizi vengono verificati tramite strumenti indipendenti.
I workflow di release generano SBOM, provenienza, digest immutabili e firme crittografiche. Documentazione disponibile in inglese.
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:
```text theme={null}
Developer change
→ Pull request
→ Build and functional checks
→ Parallel security controls
→ Aggregate Security Gate
→ Protected-branch review and merge
→ Pre-publish image scan
→ Digest-based publication and signing
→ Deployment readiness verification
→ Scheduled reassessment
```
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
| Evento | Attività di garanzia |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pull request verso `main` o `production` | Gate di sicurezza completo per codice sorgente, dipendenze, licenze, IaC, Dockerfile e sette immagini |
| Push verso `main` | Gate di sicurezza, generazione della SBOM e workflow per gli artefatti del branch main |
| Build di container pubblicata | Scansione delle vulnerabilità prima della pubblicazione, acquisizione del digest immutabile, creazione della firma e verifica della firma |
| Pianificazione settimanale | Workflow di sicurezza completo e scansione autenticata OWASP ZAP dell'ambiente di staging quando sono configurati la destinazione e l'identità di test richiesti |
| Aggiornamento di una dipendenza | Si applicano gli stessi gate delle pull request; viene inoltre applicato GitHub Dependency Review laddove la licenza del repository lo consente |
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](https://github.com/casebender/webapp/actions/workflows/security-scan.yml); i clienti senza accesso al repository devono utilizzare le evidenze specifiche della release descritte nella [Guida alle evidenze di sicurezza](/it/security/security-evidence).
## Gate di sicurezza che blocca il merge
Il Security Gate aggregato richiede che i seguenti job vengano completati correttamente per pull request e push:
| Controllo | Ambito | Condizione di blocco |
| ------------------------ | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Gitleaks | Codice sorgente corrente e cronologia Git completa | Rilevamento di un pattern relativo a secret |
| Trivy filesystem scan | Repository e manifest delle dipendenze | Vulnerabilità HIGH o CRITICAL non accettata e con correzione disponibile |
| Trivy container scan | Immagini di web, API, ingestion, worker, workflow processor, MISP processor e search sync | Vulnerabilità HIGH o CRITICAL dell'immagine non accettata e con correzione disponibile |
| Hadolint | Tutti e sette i Dockerfile | Violazione di una policy Dockerfile |
| Trivy IaC scan | Dockerfile e configurazione Kubernetes | Configurazione di sicurezza errata con severità HIGH o CRITICAL |
| ESLint security rules | TypeScript e JavaScript del web | Errore di una regola di sicurezza |
| Semgrep | Regole per TypeScript, Next.js, OWASP, injection, XSS, secret e security audit | Rilevamento con severità ERROR o errore dello scanner |
| License policy | Dipendenze del repository | Licenza bloccante non approvata oppure report non valido/vuoto |
| `pnpm audit` | Dipendenze di produzione | Avviso HIGH o CRITICAL |
| SBOM generation | Workspace completo | Errore nella generazione CycloneDX |
| Security control tests | Fixture generate contenenti secret e codice non sicuro | Lo scanner non rifiuta una fixture nota come non sicura |
| GitHub Dependency Review | Delta delle dipendenze della pull request, quando la licenza lo consente | Nuova vulnerabilità HIGH/CRITICAL o licenza negata |
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:
| Severità | Obiettivo |
| -------- | --------- |
| Critical | 24 ore |
| High | 7 giorni |
| Medium | 30 giorni |
| Low | 90 giorni |
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)](/en/security/hardening-guide) 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)](/en/security/penetration-test-scope).
## Documentazione correlata
* [Sicurezza del codice (disponibile in inglese)](/en/security/code-security) — configurazione degli scanner, DAST, licenze e gestione delle vulnerabilità
* [Sicurezza della supply chain (disponibile in inglese)](/en/security/supply-chain) — dipendenze, immagini, SBOM, firma e provenienza
* [Guida alle evidenze di sicurezza](/it/security/security-evidence) — tipi di evidenze e relativa interpretazione
* [Architettura di sicurezza (disponibile in inglese)](/en/security/architecture) — progettazione della sicurezza dell'applicazione e del deployment
* [Ambito del penetration test indipendente (disponibile in inglese)](/en/security/penetration-test-scope) — copertura pianificata della valutazione manuale