In Italia, nell’ultimo anno gli attacchi informatici sono aumentati del 15% (Clusit). La superficie di attacco è cresciuta esponenzialmente nel corso del tempo, i dati hanno acquisito valore strategico e gli attaccanti sono diventati sempre più rapidi e organizzati. Per questo, la difesa non può basarsi su approcci tradizionali e deve essere integrata in tutto il ciclo di sviluppo del software. È qui che entra in gioco il concetto di secure code.
I componenti chiave della sicurezza delle applicazioni
È evidente che la sicurezza non possa essere un pensiero accessorio o qualcosa da gestire al termine di un progetto software. Al contrario, deve essere parte integrante dell'intero Software Development LifeCycle (SDLC) e, possibilmente, fondarsi su metodologie moderne come DevSecOps, che mirano a integrare la sicurezza in ogni fase dello sviluppo, dalla progettazione al rilascio.
Esiste un software sicuro al 100%?
Per affrontare correttamente questo tema, bisogna però chiarire cosa si intenda con l’espressione secure code. In senso assoluto, un codice privo di qualsiasi vulnerabilità presente o futura è poco più di un’utopia perché il software vive in un ecosistema in continua evoluzione. Nuove vulnerabilità vengono scoperte ogni giorno, il software va aggiornato (operazione che potrebbe favorire ulteriori minacce), mutano i requisiti normativi e gli attaccanti diventano sempre più competenti e smart.
In un progetto di sviluppo software, inoltre, bisogna anche considerare l’equilibrio tra sicurezza, performance e costi. Applicare ogni misura di sicurezza possibile al codice renderebbe molte applicazioni lente, troppo costose o impossibili da rilasciare nei tempi richiesti dal business. In altri termini, un approccio all-in alla sicurezza del codice non è sostenibile.
Ciò che rende sicuro il software è il processo
Parlare di secure code significa costruire applicazioni sicure in modo ragionato, ovvero in funzione del contesto in cui il software andrà a operare. Un’applicazione interna o con dati a bassa sensibilità, per esempio, avrà esigenze di protezione ben diverse rispetto a un gestionale sanitario o a un sistema di pagamento online.
Integrare misure di sicurezza nel codice applicativo è dunque una parte di un processo più ampio, che potremmo sintetizzare in questo modo:
- Analisi dei requisiti di sicurezza dell’applicazione, funzionali (autenticazione, crittografia, validazione input…) e non funzionali (performance, usabilità sotto vincoli di sicurezza…);
- Threat modeling, ovvero modellazione delle minacce cui l’applicazione è soggetta, tenendo conto di utenti, ambienti, attori ostili e possibili vettori di attacco. Questa fase è fondamentale perché serve a definire le priorità di intervento, evitando di dedicare a tutte le minacce lo stesso tempo e le stesse risorse;
- Selezione delle misure di sicurezza. Sulla base dei rischi identificati, si scelgono le misure concrete da adottare e si capisce dove adottarle: validazione input, gestione sicura delle sessioni, logging sicuro;
- Scrittura del codice. Il codice viene scritto includendo le protezioni necessarie, secondo linee guida condivise e policy di sicurezza coerenti;
- Testing del codice attraverso test statici (SAST), dinamici (DAST) e, sempre più spesso, anche penetration test, per individuare vulnerabilità prima del rilascio.
Quando questo processo viene integrato senza attriti nei workflow di sviluppo (con strumenti, policy e cultura condivisa) si ottiene un modello virtuoso e, soprattutto, un applicativo che, con tutte le premesse del caso, si può definire sicuro.
Integrare la sicurezza nel codice: metodo e riferimenti condivisi
Completate l’analisi dei requisiti, la modellazione delle minacce e la selezione delle misure più adatte, arriva il momento in cui bisogna tradurre le decisioni in codice. Qui non basta il buon senso del singolo sviluppatore, le sue competenze o la sensibilità del team: serve un metodo condiviso, strutturato e coerente nel tempo.
La centralità delle best practice condivise
Per integrare le misure di sicurezza nel codice, ogni team (interno o esterno) deve seguire una base di best practice comuni. Questo non solo aiuta a evitare vulnerabilità note, ma garantisce uniformità tra i progetti aziendali.
In assenza di riferimenti precisi, ogni applicazione rischia di essere un caso a sé, e se dovessero emergere nuove minacce (si pensi a una dipendenza comune compromessa), l’azienda non potrebbe avere una visione chiara di quali software siano esposti e quali no. Ogni verifica diventerebbe un’indagine a sé, con dispendio di tempo, risorse e attenzione, anche solo per l’assessment preliminare.
I riferimenti non mancano, da ISO 27001 a OWASP
Fortunatamente, le aziende non sono obbligate a sviluppare un loro framework di secure coding. Nel tempo, sono nati diversi riferimenti internazionali proprio su questo tema, tra cui:
- CERT Secure Coding Standards, sviluppati dal Software Engineering Institute della Carnegie Mellon University, che coprono linguaggi come C, C++, Java e Perl;
- NIST SSDF (Secure Software Development Framework), un framework adattabile a diverse metodologie di sviluppo e ispirato al concetto di security by design;
- ISO/IEC 27034, standard internazionale per l’Application Security. La norma si occupa proprio di fornire una piattaforma per l’integrazione della sicurezza nelle pratiche di gestione dei sistemi software, dalla progettazione al deployment;
- OWASP Secure Coding Practices, una guida orientata all’azione, pensata per aiutare gli sviluppatori a scrivere codice sicuro nel contesto di applicazioni web, ma utile anche in scenari differenti. La guida OWASP è organizzata per aree tematiche (validazione degli input, autenticazione, gestione delle sessioni, controllo degli accessi, gestione degli errori…) e fornisce indicazioni pratiche, facilmente applicabili nei workflow di sviluppo moderni. È pensata per essere un riferimento operativo, da tenere sottomano durante lo sviluppo vero e proprio e dopo aver identificato cosa applicare e in che modo.
Dal punto di riferimento all’azione concreta
Avere una guida o uno standard di riferimento è fondamentale, ma tradurre i principi in attività concrete richiede il loro adattamento alla realtà aziendale, ovvero ai processi, ai ruoli e agli strumenti di cui dispone. In termini pratici, ciò significa:
- Formalizzare policy di secure coding aziendali, basate su riferimenti affermati (come OWASP), ma adattate al contesto specifico dell’organizzazione e al modo in cui “realizza” il software;
- Integrare controlli automatici nel ciclo di sviluppo tramite strumenti SAST (Static Application Security Testing) e scansioni delle dipendenze, avendo cura di integrarli correttamente nelle pipeline CI/CD;
- Creare checklist e template di progetto, per aiutare i team a non dimenticare aspetti critici come la gestione degli errori, l’hardening delle configurazioni o la validazione degli input;
- Prevedere momenti di formazione continua, perché la sicurezza non è statica e le minacce evolvono con grande rapidità.
Se volete trasformare i principi del secure coding in pratiche operative, il nostro team è pronto ad affiancarvi con servizi di sviluppo software sicuro e integrazione DevSecOps: contattateci per valutare insieme la soluzione migliore per la vostra realtà.
