Le PMI italiane stanno facendo i conti con clienti enterprise e PA che chiedono certificazioni di sicurezza, audit periodici, evidenza di processo. Senza una pratica DevSecOps minimamente strutturata, queste richieste rallentano le vendite o le bloccano del tutto. La buona notizia: bastano sei mesi e un budget moderato per arrivare a una baseline credibile.
In questo articolo descriviamo un piano in tre fasi che abbiamo applicato con tre clienti negli ultimi due anni, partendo da "zero processo strutturato" a "baseline auditable".
Fase 1 (mesi 1-2) — Visibilita' e baseline
Obiettivo: capire dove siamo, cosa abbiamo, dove sono le falle piu' evidenti. Nessuno strumento di sicurezza serve se non sappiamo cosa proteggere.
Inventory degli asset. Lista applicazioni in produzione, ambienti (dev, staging, prod), repository di codice, container image, segreti in uso, accounts cloud. Spreadsheet sufficiente se l'organizzazione e' piccola.
Audit di partenza. Scansione automatica con strumenti free: Semgrep su tutti i repository (SAST), Trivy su tutte le container image (SCA + vulnerability), gitleaks per ricerca di segreti in repo, securityheaders.com per ogni endpoint pubblico.
Mappa dei rischi. Documento di 5-10 pagine con classificazione delle vulnerabilita' trovate (critical / high / medium / low), stima dell'esposizione, prioritizzazione del fix.
Costo Fase 1: 5-8k euro (consulente esterno 4-6 giorni se manca competenza interna).
Fase 2 (mesi 3-4) — Automazione in CI/CD
Obiettivo: trasformare scansioni occasionali in pratica continua, integrata nel flusso di sviluppo. Senza automazione, ogni miglioramento si perde dopo 30 giorni.
SAST automatico nel CI. Semgrep configurato per girare ad ogni pull request. Regole iniziali: ruleset community + 5-10 regole custom per il vostro stack. Build fallisce se vengono introdotte vulnerabilita' high/critical nuove.
SCA automatico. Dependabot (gratuito su GitHub) o Renovate per pull request automatiche di update sicuri. Soglia: review settimanale obbligatoria delle PR aperte.
Scan container nel pipeline. Trivy come step pre-push registry: container con CVE critical non si pubblica. Override esplicito + commento se necessario.
Secrets scanning. Pre-commit hook con gitleaks + scan CI di backup. Se un secret arriva in repo, viene revocato immediatamente (procedura documentata).
Security headers su tutti gli endpoint. Test automatico nei integration test: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Deploy fallisce se mancano.
Costo Fase 2: 8-12k euro (setup CI + tuning regole + training team).
Fase 3 (mesi 5-6) — Processo e cultura
Obiettivo: rendere la sicurezza parte del normale processo di sviluppo, non un'aggiunta straordinaria. Le best practice tecniche servono solo se sono applicate dal team in modo naturale.
Security champion in ogni team. Una persona per team che fa da punto di contatto tecnico per le questioni di sicurezza. Formazione 2 giornate.
Threat modeling per feature nuove. Per feature non triviali (auth, payment, dati personali), sessione di threat modeling 2 ore prima dello sviluppo. Output: documento di 1 pagina con scenari di abuso e contromisure.
Security review pre-go-live. Checklist di 20-30 punti che ogni release importante deve superare prima del deploy. Tracciamento in ticketing.
Incident response runbook. Procedura scritta per gestire un incidente di sicurezza: chi chiama chi, in che ordine, con quali criteri di comunicazione esterna. Esercizio simulato (tabletop) ogni 6 mesi.
Documentazione audit-ready. Raccolta di evidenze (log scan, configurazioni CI, security review, runbook) in un repository unico. Quando arriva un audit di un cliente o un assessment ISO, e' pronto.
Costo Fase 3: 10-13k euro (formazione + processo + documentazione).
Strumenti e licenze
Tutti gli strumenti citati hanno tier gratuito sufficiente per PMI:
- Semgrep — community open source, ottimo per partire. Versione Pro per regole avanzate.
- Trivy — open source, scan container e dipendenze.
- Gitleaks — open source.
- Dependabot — gratuito su GitHub.
- OWASP ZAP — open source DAST.
- Mozilla Observatory + securityheaders.com — gratuiti.
Per stack piu' avanzati si introducono successivamente strumenti commerciali come Snyk, GitGuardian, Wiz, ma senza fretta.
Pattern organizzativi che funzionano
Tre pattern che vediamo correlati a successi.
Champion model. Una persona per team con interesse personale per la sicurezza, dotata di tempo (10% allocato) per pratica DevSecOps. Funziona meglio del modello "security team separato" perche' mantiene la sicurezza nel team di sviluppo.
Blameless postmortem. Quando succede un incidente o un bug di sicurezza, la review e' senza attribuzione di colpe individuali. Focus su come il sistema ha permesso l'errore. Cultura che incoraggia segnalazione precoce.
Security come supporto, non come gate. Il ruolo del consulente o security champion e' aiutare i team a fare la cosa giusta, non bloccare i rilasci. Quando il blocco e' necessario, viene proposta una soluzione concreta.
Errori comuni nelle PMI
Errore 1 — Comprare strumento prima di processo. Acquisire una piattaforma costosa senza aver definito chi la usa, come e quando, e' un buco di budget. Comprate strumenti dopo aver definito il processo che li userà.
Errore 2 — Audit annuale come unica pratica. Una scansione una volta all'anno trova vulnerabilita' che resteranno aperte per 11 mesi. Meglio investire nell'automazione continua.
Errore 3 — Trascurare il team. Se il team di sviluppo percepisce la sicurezza come ostacolo, troverà modi per aggirarla. Comunicazione e formazione contano almeno quanto gli strumenti.
Cosa serve davvero alla fine dei 6 mesi
Una PMI che ha completato il piano sopra arriva ad avere:
- Visibilita' real-time su CVE e configurazioni rischiose.
- Build automatica che blocca regressioni di sicurezza.
- Processo documentato di security review pre-deploy.
- Runbook per incidenti.
- Documentazione audit-ready aggiornata.
Questo livello e' sufficiente per superare audit di clienti enterprise medi (non grandi banche, non sanita' high-risk) e per stipulare assicurazione cyber a costi ragionevoli.
FAQ
Serve un security engineer dedicato a tempo pieno?
Sotto i 15 sviluppatori: no, basta un consulente per setup iniziale + security champion interni. Sopra i 30 sviluppatori: comincia ad aver senso una posizione dedicata o un Head of Security part-time.
Quanto durera' la conformita' nel tempo?
Una pratica DevSecOps non e' "completa" — e' continuamente in evoluzione. Vulnerabilita' nuove, dipendenze nuove, regole nuove. Il budget di manutenzione e' tipicamente il 20-30% dell'investimento iniziale, annuo.
Quali certificazioni puntare?
Per PMI italiane il percorso tipico e' ISO 27001 quando un cliente grosso lo richiede esplicitamente. Prima e' over-engineering. NIS2 e' obbligatoria per alcune categorie (verificare l'applicabilita').
E se troviamo vulnerabilita' gravi in produzione durante l'audit iniziale?
Si applica un piano di remediation prioritizzato: critical entro 7 giorni, high entro 30, medium entro 90. Comunicazione interna trasparente. Se ci sono violazioni di dati personali, valutazione GDPR art. 33 (notifica al Garante entro 72 ore se rischi rilevanti).
Conclusione
DevSecOps in PMI non e' una versione ridotta di quello che fanno le big tech. E' un percorso pragmatico calibrato sulle risorse disponibili. Con 30k e sei mesi si arriva a baseline solida. Per discutere il vostro caso, apriamo un confronto tecnico.