1. Scopo
La presente Politica stabilisce i principi e le regole con cui Nuova Agile Technology srl integra la sicurezza in tutte le fasi del ciclo di vita dello sviluppo software (Secure Software Development Life Cycle). L'obiettivo è garantire che i prodotti realizzati — sia quelli in licenza d'uso installati sui server dei clienti, sia il SaaS multi-tenant in cloud — siano progettati, sviluppati, testati e mantenuti in modo da ridurre vulnerabilità, proteggere i dati personali trattati e soddisfare i requisiti di sicurezza nell'acquisizione, sviluppo e manutenzione previsti dall'art. 24 del D.Lgs. 138/2024 (NIS2).
2. Ambito
La Politica si applica a tutte le attività di analisi, progettazione, codifica, test, rilascio e manutenzione dei software dell'azienda, a tutto il personale tecnico (9 dipendenti e 2 collaboratori esterni a P.IVA) e a eventuali fornitori che contribuiscono allo sviluppo. Copre il codice sorgente, le dipendenze di terze parti, le pipeline di build/deploy, gli ambienti di sviluppo e test, e le componenti di intelligenza artificiale integrate tramite API esterne (es. LLM Anthropic). L'attività si svolge esclusivamente da PC portatili cifrati, senza alcun server in sede.
3. Riferimenti
- ISO/IEC 27001:2022 – Annex A, controlli A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.30, A.8.31, A.8.32, A.8.33.
- ISO/IEC 27017:2015 – sicurezza nello sviluppo e gestione di servizi cloud.
- ISO/IEC 27018:2019 – protezione dei PII nei servizi cloud (privacy by design).
- D.Lgs. 138/2024, art. 24 (sicurezza nell'acquisizione, sviluppo e manutenzione di sistemi).
- Regolamento (UE) 2016/679 (GDPR), artt. 25 e 32 (privacy by design e by default, sicurezza del trattamento).
4. Ruoli e responsabilità
| Ruolo | Responsabilità |
|---|
| Presidente (Silvia Garretto) | Approva la Politica e assegna le risorse per la sicurezza dello sviluppo. |
| RSGSI (Massimo Tagliavini) | Mantiene la Politica e ne verifica l'applicazione nei progetti. |
| Resp. IT/Sicurezza (Simon Fattori) | Definisce gli standard tecnici, gestisce code review, analisi delle vulnerabilità e gestione degli accessi al codice. |
| Sviluppatori (dipendenti e collaboratori) | Applicano le regole di codifica sicura, eseguono test e gestiscono le segnalazioni di vulnerabilità. |
| DPO (consulente esterno) | Valida i requisiti di privacy by design quando si trattano dati personali. |
5. Corpo – Regole e passi concreti
5.1 Requisiti e progettazione sicura
- I requisiti di sicurezza e privacy sono definiti già in fase di analisi, considerando il modello di minaccia, la separazione tra tenant nel SaaS e l'isolamento delle istanze on-premise.
- Si applicano i principi di privacy by design e by default (GDPR artt. 25 e 32) e di minimizzazione dei dati.
5.2 Codifica sicura
- Vengono seguite regole di secure coding per prevenire le vulnerabilità più comuni (injection, autenticazione/sessione, controllo accessi, gestione errori, esposizione di dati).
- I segreti (credenziali, chiavi API, incluse quelle dei servizi AI) non sono mai inseriti nel codice né nei repository: si usano meccanismi di gestione segreti dedicati.
- Gli ambienti di sviluppo risiedono su PC portatili cifrati con accesso autenticato.
5.3 Gestione delle dipendenze di terze parti
- Le librerie e i componenti open source sono censiti e tenuti aggiornati; si monitorano gli avvisi di vulnerabilità note e si applicano le patch in tempi proporzionati al rischio.
5.4 Test di sicurezza
- Sono previsti test funzionali e di sicurezza prima del rilascio; per le componenti più esposte si eseguono verifiche statiche/dinamiche e, ove opportuno, test di penetrazione.
- Gli ambienti di test usano dati anonimizzati o sintetici: i dati personali reali dei clienti non vengono utilizzati in test.
5.5 Separazione degli ambienti e gestione dei cambiamenti
- Ambienti di sviluppo, test e produzione sono separati; i rilasci seguono un processo controllato di change management con tracciabilità delle modifiche.
- Il codice è versionato; le modifiche sono sottoposte a revisione tra pari (code review) prima dell'integrazione.
5.6 Rilascio, manutenzione e gestione vulnerabilità
- Per i prodotti in licenza installati presso i clienti si forniscono aggiornamenti di sicurezza e indicazioni di installazione sicura; le responsabilità di patching condivise con il cliente sono documentate.
- Per il SaaS, l'azienda gestisce direttamente il patching dell'applicazione.
- È attivo un canale per la ricezione e gestione delle segnalazioni di vulnerabilità; le correzioni sono prioritizzate in base alla gravità.
5.7 Componenti di intelligenza artificiale
L'uso di API LLM esterne è valutato per i rischi su confidenzialità dei dati inviati e affidabilità degli output; i dati personali e riservati inviati ai servizi AI sono minimizzati e protetti coerentemente con i contratti e i DPA dei fornitori.
6. Controlli ISO collegati e riferimenti NIS2
- A.8.25 – Ciclo di vita di sviluppo sicuro.
- A.8.26 – Requisiti di sicurezza delle applicazioni.
- A.8.27 / A.8.28 – Principi di architettura sicura e codifica sicura.
- A.8.29 – Test di sicurezza in sviluppo e accettazione.
- A.8.30 – Sviluppo affidato all'esterno.
- A.8.31 – Separazione ambienti di sviluppo, test e produzione.
- A.8.32 / A.8.33 – Gestione dei cambiamenti e dati di test.
- Controlli ISO/IEC 27017 e 27018 per gli aspetti cloud e PII.
- NIS2 – D.Lgs. 138/2024, art. 24: sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi.
7. Registrazioni ed evidenze
- Requisiti di sicurezza documentati per progetto/prodotto.
- Registri delle code review e dei test di sicurezza.
- Inventario delle dipendenze e tracciamento delle vulnerabilità/patch.
- Log dei rilasci e delle modifiche (change management).
8. Riesame e versionamento
La Politica è riesaminata almeno annualmente o in caso di cambiamenti tecnologici significativi, nuove minacce o requisiti contrattuali dei clienti. Versione corrente: 1.0, approvata dalla Presidente. Le revisioni sono tracciate nel sistema documentale del SGSI a cura del RSGSI.