[CLIENT] Nuova Agile Technology srl (org 996003) — build completo SGSI/NIS2

Provisioning idempotente di un'azienda cliente cloud-only (Aruba/Hetzner/AI, no server in sede, PC portatili):
- Fase 1: org + classificazione NIS2 (important, sub_threshold_candidate/preliminary) + 3 membri esistenti collegati + organigramma 8 ruoli
- Fase 2: 12 asset (NIS2-rilevanti) + 4 fornitori + 10 rischi + gap analysis (80 risposte, 45%)
- Fase 3: ISMS model + SoA 111 controlli (27001/27017/27018) + 31 documenti (Manuale/10 politiche/13 procedure/7 istruzioni)
- Fase 4: 15 piani di controllo periodici + 5 corsi formazione
Documenti AI-redatti con regole fonti-certe (D.Lgs.138/2024 art.23/24/25; 24h/72h/1 mese). Sorgenti in _docs_na/.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

application/cli/_docs_na/08.html

@@ -0,0 +1,85 @@
+<!--META|doc_type=politica_sviluppo_sicuro|title=Politica di Sviluppo Software Sicuro (Secure SDLC)|status=approved|version=1.0-->
+
+<h2>1. Scopo</h2>
+<p>La presente Politica stabilisce i principi e le regole con cui <strong>Nuova Agile Technology srl</strong> 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 <strong>licenza d'uso installati sui server dei clienti</strong>, sia il <strong>SaaS multi-tenant in cloud</strong> — 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'<strong>art. 24 del D.Lgs. 138/2024</strong> (NIS2).</p>
+
+<h2>2. Ambito</h2>
+<p>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 <strong>PC portatili cifrati</strong>, senza alcun server in sede.</p>
+
+<h2>3. Riferimenti</h2>
+<ul>
+<li>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.</li>
+<li>ISO/IEC 27017:2015 – sicurezza nello sviluppo e gestione di servizi cloud.</li>
+<li>ISO/IEC 27018:2019 – protezione dei PII nei servizi cloud (privacy by design).</li>
+<li>D.Lgs. 138/2024, art. 24 (sicurezza nell'acquisizione, sviluppo e manutenzione di sistemi).</li>
+<li>Regolamento (UE) 2016/679 (GDPR), artt. 25 e 32 (privacy by design e by default, sicurezza del trattamento).</li>
+</ul>
+
+<h2>4. Ruoli e responsabilità</h2>
+<table>
+<tr><th>Ruolo</th><th>Responsabilità</th></tr>
+<tr><td>Presidente (Silvia Garretto)</td><td>Approva la Politica e assegna le risorse per la sicurezza dello sviluppo.</td></tr>
+<tr><td>RSGSI (Massimo Tagliavini)</td><td>Mantiene la Politica e ne verifica l'applicazione nei progetti.</td></tr>
+<tr><td>Resp. IT/Sicurezza (Simon Fattori)</td><td>Definisce gli standard tecnici, gestisce code review, analisi delle vulnerabilità e gestione degli accessi al codice.</td></tr>
+<tr><td>Sviluppatori (dipendenti e collaboratori)</td><td>Applicano le regole di codifica sicura, eseguono test e gestiscono le segnalazioni di vulnerabilità.</td></tr>
+<tr><td>DPO (consulente esterno)</td><td>Valida i requisiti di privacy by design quando si trattano dati personali.</td></tr>
+</table>
+
+<h2>5. Corpo – Regole e passi concreti</h2>
+<h3>5.1 Requisiti e progettazione sicura</h3>
+<ul>
+<li>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.</li>
+<li>Si applicano i principi di <strong>privacy by design e by default</strong> (GDPR artt. 25 e 32) e di minimizzazione dei dati.</li>
+</ul>
+<h3>5.2 Codifica sicura</h3>
+<ul>
+<li>Vengono seguite regole di secure coding per prevenire le vulnerabilità più comuni (injection, autenticazione/sessione, controllo accessi, gestione errori, esposizione di dati).</li>
+<li>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.</li>
+<li>Gli ambienti di sviluppo risiedono su PC portatili cifrati con accesso autenticato.</li>
+</ul>
+<h3>5.3 Gestione delle dipendenze di terze parti</h3>
+<ul>
+<li>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.</li>
+</ul>
+<h3>5.4 Test di sicurezza</h3>
+<ul>
+<li>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.</li>
+<li>Gli ambienti di test usano dati anonimizzati o sintetici: i dati personali reali dei clienti non vengono utilizzati in test.</li>
+</ul>
+<h3>5.5 Separazione degli ambienti e gestione dei cambiamenti</h3>
+<ul>
+<li>Ambienti di sviluppo, test e produzione sono separati; i rilasci seguono un processo controllato di change management con tracciabilità delle modifiche.</li>
+<li>Il codice è versionato; le modifiche sono sottoposte a revisione tra pari (code review) prima dell'integrazione.</li>
+</ul>
+<h3>5.6 Rilascio, manutenzione e gestione vulnerabilità</h3>
+<ul>
+<li>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.</li>
+<li>Per il SaaS, l'azienda gestisce direttamente il patching dell'applicazione.</li>
+<li>È attivo un canale per la ricezione e gestione delle segnalazioni di vulnerabilità; le correzioni sono prioritizzate in base alla gravità.</li>
+</ul>
+<h3>5.7 Componenti di intelligenza artificiale</h3>
+<p>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.</p>
+
+<h2>6. Controlli ISO collegati e riferimenti NIS2</h2>
+<ul>
+<li><strong>A.8.25</strong> – Ciclo di vita di sviluppo sicuro.</li>
+<li><strong>A.8.26</strong> – Requisiti di sicurezza delle applicazioni.</li>
+<li><strong>A.8.27 / A.8.28</strong> – Principi di architettura sicura e codifica sicura.</li>
+<li><strong>A.8.29</strong> – Test di sicurezza in sviluppo e accettazione.</li>
+<li><strong>A.8.30</strong> – Sviluppo affidato all'esterno.</li>
+<li><strong>A.8.31</strong> – Separazione ambienti di sviluppo, test e produzione.</li>
+<li><strong>A.8.32 / A.8.33</strong> – Gestione dei cambiamenti e dati di test.</li>
+<li>Controlli ISO/IEC 27017 e 27018 per gli aspetti cloud e PII.</li>
+<li><strong>NIS2 – D.Lgs. 138/2024, art. 24</strong>: sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi.</li>
+</ul>
+
+<h2>7. Registrazioni ed evidenze</h2>
+<ul>
+<li>Requisiti di sicurezza documentati per progetto/prodotto.</li>
+<li>Registri delle code review e dei test di sicurezza.</li>
+<li>Inventario delle dipendenze e tracciamento delle vulnerabilità/patch.</li>
+<li>Log dei rilasci e delle modifiche (change management).</li>
+</ul>
+
+<h2>8. Riesame e versionamento</h2>
+<p>La Politica è riesaminata almeno annualmente o in caso di cambiamenti tecnologici significativi, nuove minacce o requisiti contrattuali dei clienti. Versione corrente: <strong>1.0</strong>, approvata dalla Presidente. Le revisioni sono tracciate nel sistema documentale del SGSI a cura del RSGSI.</p>