1. Scopo

La presente procedura stabilisce come Nuova Agile Technology srl integra la sicurezza nel ciclo di vita dello sviluppo software (Secure SDLC), governa i cambiamenti ai propri sistemi, gestisce le vulnerabilità tecniche e le patch, e presidia logging e monitoraggio. L'obiettivo è garantire che i prodotti — sia in licenza d'uso installati sui server dei clienti (on-premise), sia il SaaS multi-tenant in cloud — siano progettati, sviluppati, rilasciati e mantenuti in modo da ridurre vulnerabilità e proteggere i dati, e che ogni cambiamento avvenga in modo controllato e tracciabile. Soddisfa i requisiti di sicurezza nell'acquisizione, sviluppo e manutenzione previsti dall'art. 24 del D.Lgs. 138/2024 (NIS2).

2. Ambito

Si applica a tutte le attività di analisi, progettazione, codifica, test, rilascio e manutenzione del software, e ai relativi cambiamenti, vulnerabilità, patch e log su: ambienti cloud (Aruba IT, Hetzner DE), configurazioni di rete e di sicurezza, servizi SaaS multi-tenant e prodotti on-premise presso i clienti, dipendenze e librerie di terze parti, pipeline di build/deploy, integrazioni con piattaforme AI via API (es. LLM Anthropic) ed endpoint (PC portatili cifrati). Riguarda tutto il personale tecnico (9 dipendenti, 2 collaboratori esterni a P.IVA) ed eventuali fornitori che contribuiscono allo sviluppo. L'attività si svolge esclusivamente da PC portatili cifrati, senza alcun server in sede.

3. Riferimenti

• ISO/IEC 27001:2022 – Annex A: A.5.7 (threat intelligence), A.8.7 (protezione dai malware), A.8.8 (gestione delle vulnerabilità tecniche), A.8.9 (gestione della configurazione), A.8.15 (logging), A.8.16 (monitoraggio), A.8.25–A.8.33 (sviluppo sicuro, requisiti applicazioni, architettura e codifica sicura, test, sviluppo esterno, separazione ambienti, gestione cambiamenti, dati di test), A.5.17 (autenticazione).
• ISO/IEC 27017:2015 e ISO/IEC 27018:2019 – sicurezza dello sviluppo, dei cambiamenti e delle vulnerabilità nei servizi cloud e protezione dei PII (privacy by design).
• D.Lgs. 4 settembre 2024, n. 138 (NIS2): art. 24 (sicurezza nell'acquisizione/sviluppo/manutenzione, gestione delle modifiche e divulgazione delle vulnerabilità) e art. 25 (notifica incidenti significativi).
• Regolamento (UE) 2016/679 (GDPR), artt. 25 e 32 (privacy by design e by default, sicurezza del trattamento).
• Procedura di Gestione degli Incidenti dell'Azienda.

4. Ruoli e responsabilità

5. Sviluppo sicuro (Secure SDLC)

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 e dipendenze

• Si seguono 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.
• 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.3 Test di sicurezza e separazione degli ambienti

• 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 (mai PII reali dei clienti).
• Ambienti di sviluppo, test e produzione sono separati (A.8.31); il codice è versionato e le modifiche sono sottoposte a code review tra pari prima dell'integrazione.

5.4 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. Gestione dei cambiamenti

1. Richiesta (RFC). Il richiedente apre una richiesta di cambiamento descrivendo obiettivo, sistemi coinvolti, impatto atteso e urgenza.
2. Valutazione di impatto e rischio. Simon Fattori classifica il cambiamento (standard a basso rischio / normale / emergenza) e ne valuta gli effetti su sicurezza, dati personali e continuità; i cambiamenti rilevanti sono registrati nel modulo "Rischi" ove pertinente.
3. Autorizzazione. I cambiamenti standard a basso rischio sono approvati da Simon Fattori; quelli normali ad alto impatto richiedono l'autorizzazione della Direzione. Va sempre definito un piano di rollback.
4. Test in ambiente separato. Le modifiche software sono validate in ambienti di sviluppo/test separati dall'esercizio (A.8.31), con test funzionali e di sicurezza (A.8.29) prima del rilascio.
5. Attuazione. Il cambiamento è applicato in una finestra concordata; per il SaaS si privilegiano rilasci controllati. Per i prodotti on-premise, l'azienda fornisce ai clienti note di rilascio e indicazioni di aggiornamento, nel rispetto degli obblighi contrattuali di supply chain.
6. Verifica post-cambiamento. Si verifica il corretto funzionamento e l'assenza di effetti collaterali; in caso di esito negativo si attiva il rollback.
7. Chiusura. Esito e documentazione sono registrati; eventuali anomalie alimentano non conformità e azioni correttive.

6.1 Cambiamenti di emergenza

Per cambiamenti urgenti (es. mitigazione di una vulnerabilità critica), l'attuazione può precedere l'autorizzazione formale, ma deve essere documentata a posteriori entro il giorno lavorativo successivo e ratificata dalla Direzione.

7. Gestione delle vulnerabilità e delle patch

7.1 Identificazione

• Simon Fattori monitora con continuità le fonti di vulnerabilità: bollettini dei fornitori cloud, avvisi CSIRT/ACN, advisory delle librerie/dipendenze usate dai prodotti, scansioni periodiche e avvisi automatici delle piattaforme (A.5.7, A.8.16).
• Si mantiene un inventario aggiornato dei componenti software e delle dipendenze per correlare rapidamente le vulnerabilità ai sistemi interessati.

7.2 Valutazione, prioritizzazione e tempi di rimedio

• Ogni vulnerabilità è valutata per gravità (es. punteggio CVSS), esposizione e impatto su dati e servizi, e registrata se rilevante nel modulo "Rischi".
• Si assegna una priorità con relativi tempi target di rimedio, ad esempio: critiche entro 48–72 ore, alte entro 7 giorni, medie entro 30 giorni, basse alla successiva finestra pianificata. [I valori esatti sono da confermare nel piano di trattamento del rischio e negli SLA interni.]

7.3 Rimedio (applicazione delle patch)

• L'applicazione delle patch segue la gestione dei cambiamenti (test in ambiente separato e piano di rollback); per le vulnerabilità critiche si attiva il percorso di cambiamento di emergenza. Dove la patch non è immediatamente disponibile si adottano misure compensative (restrizione accessi, isolamento, disattivazione della funzione vulnerabile).
• Aggiornamenti automatici abilitati su sistema operativo (Windows Update, aggiornamenti macOS, gestore pacchetti Linux) e browser dei portatili; applicazioni (editor, strumenti di sviluppo, client VPN, antimalware, estensioni browser) tenute aggiornate; software non supportato rimosso o sostituito; riavvio del portatile almeno settimanale e quando richiesto.
• Per i prodotti SaaS e on-premise si monitorano le dipendenze (librerie, container, runtime), si aggiornano le immagini e si ricostruiscono gli artefatti; sui servizi cloud (Aruba, Hetzner) si applicano gli aggiornamenti delle console e dei servizi gestiti annotando le finestre di manutenzione.
• Per i prodotti on-premise, l'azienda rilascia la patch e informa tempestivamente i clienti impattati con le istruzioni di aggiornamento (obblighi contrattuali di supply chain), verificandola in ambiente di prova prima del rilascio per evitare regressioni.

7.4 Verifica, chiusura e registrazione

• Si verifica l'effettiva risoluzione (riscansione/test) e si chiude la vulnerabilità; gli scostamenti dai tempi target sono registrati come non conformità con azione correttiva.
• Patch, date e versioni sono tracciate nel registro aggiornamenti/asset; nessuna vulnerabilità critica nota resta non gestita oltre lo SLA interno.
• Se una vulnerabilità è stata sfruttata, si attiva la Procedura di Gestione degli Incidenti. In caso di dubbio su un aggiornamento fallito o su una vulnerabilità segnalata si contatta il Resp. IT/Sicurezza Simon Fattori, senza disinstallare patch di sicurezza per "far funzionare" un'applicazione.

8. Logging e monitoraggio

In assenza di server in sede, i log dei servizi cloud sono la principale fonte di visibilità. Il logging è attivo su tutti i servizi critici (posta, console Aruba/Hetzner, repository, piattaforme AI, password manager, prodotti SaaS), con orari di riferimento coerenti (Europe/Rome o UTC documentato) per correlare gli eventi.

1. Verifica giornaliera rapida. Controllo degli avvisi di sicurezza automatici dei fornitori (nuovi accessi, login da nuovi dispositivi/paesi, blocchi MFA); ogni avviso è da valutare, non da ignorare.
2. Revisione settimanale degli accessi. Esame dei log di autenticazione dei servizi critici cercando login falliti ripetuti, accessi da località/orari inusuali, accessi notturni non giustificati, sessioni o dispositivi non riconosciuti.
3. Controllo dei cambiamenti privilegiati. Verifica di modifiche a ruoli/permessi, creazione di account, generazione/rotazione di chiavi API e token; ogni cambiamento deve essere riconducibile a una richiesta legittima.
4. Log dei prodotti SaaS. Controllo degli audit log applicativi per accessi anomali ai dati dei clienti ed errori ricorrenti.
5. Correlazione degli eventi. A fronte di un'anomalia si ricostruisce la sequenza tra servizi diversi usando orari allineati, per distinguere un evento singolo da una catena.
6. Conservazione e protezione dei log. I registri non sono modificabili dagli utenti finali e sono conservati per un periodo adeguato secondo le impostazioni dei fornitori [da verificare rispetto alla policy di retention interna].
7. Documentazione della revisione. Si annotano data, servizi controllati, anomalie rilevate ed esito (chiusa come falso positivo o escalata a incidente) nel registro delle revisioni.

In presenza di accesso non autorizzato confermato o sospetto, chiave compromessa o attività anomale sui dati dei clienti, si avvia la Procedura di Gestione degli Incidenti (referente: Simon Fattori); per incidenti che possono ricadere sotto NIS2 si rispettano i tempi di notifica al CSIRT Italia (pre-allarme 24h, notifica 72h, relazione finale 1 mese).

9. 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 – architettura 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; A.8.32 / A.8.33 – gestione dei cambiamenti e dati di test.
• A.8.8 – gestione delle vulnerabilità tecniche; A.8.7 – protezione dai malware; A.8.9 – gestione della configurazione; A.5.7 – threat intelligence; A.8.16 – monitoraggio; A.8.1 – endpoint.
• A.8.15 – logging; A.5.17 – informazioni di autenticazione.
• Controlli cloud di ISO/IEC 27017 e ISO/IEC 27018 per gli aspetti cloud e PII.
• NIS2 – D.Lgs. 138/2024, art. 24: sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi, gestione delle modifiche e delle vulnerabilità. Una vulnerabilità sfruttata o un cambiamento fallito che causino un incidente significativo attivano gli obblighi di notifica dell'art. 25 (early warning 24 ore, notifica completa 72 ore, relazione finale 1 mese).

10. Registrazioni ed evidenze

• Requisiti di sicurezza documentati per progetto/prodotto; registri delle code review e dei test di sicurezza; inventario delle dipendenze.
• Richieste di cambiamento (RFC) e autorizzazioni; esiti di test e rilasci; note di rilascio per i clienti on-premise; documentazione dei cambiamenti di emergenza e relativa ratifica.
• Registro delle vulnerabilità con gravità, priorità e tempi di rimedio; report delle scansioni e degli aggiornamenti applicati; registro aggiornamenti/asset; comunicazioni di patch ai clienti on-premise.
• Registro delle revisioni dei log/accessi con anomalie ed esiti; non conformità e azioni correttive per cambiamenti falliti o ritardi di rimedio.

11. Riesame e versionamento

La procedura è riesaminata almeno annualmente o a fronte di cambiamenti tecnologici significativi, nuove minacce, modifiche del processo di rilascio o degli strumenti di scansione, cambiamenti del parco software o requisiti contrattuali dei clienti. Versione corrente: 2.0, approvata dalla Presidente. Le revisioni sono tracciate nel sistema documentale del SGSI a cura del RSGSI.