Un framework per l'integrazione della sicurezza delle applicazioni nell'ingegneria del software (FIASSE) basato sul Securable Software Engineering Model (SSEM)
# Un Framework per Integrare la Sicurezza delle Applicazioni nell'Ingegneria del Software (FIASSE) [](https://creativecommons.org/licenses/by-sa/4.0/) **Nota:** Questo repository è un lavoro in corso. I contributi sono benvenuti! ## Panoramica TL;DR: si prega di leggere il [DOC](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md). Esplora il [sito web FIASSE](https://fiasse.org). Visita le [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) per contribuire. Questo repository contiene risorse e materiali per l'OWASP Framework for Integrating Application Security into Software Engineering (FIASSE). FIASSE (pronunciato /feiz/ come 'phase') è un framework indipendente dal fornitore che promuove un **approccio basato sui principi e incentrato sullo sviluppatore** per la creazione di software **securable**. Riconosce che la sicurezza è un processo dinamico e continuo come lo sviluppo. Introduce il Securable Software Engineering Model (SSEM) come un **linguaggio di progettazione comune** che utilizza termini consolidati dell'ingegneria del software per integrare la sicurezza nell'architettura, nella progettazione e nell'ingegneria del software, incorporando la sicurezza nei principi che plasmano il codice stesso. Il framework consente ai team di sviluppo di aggiungere valore informatico in modo resiliente, riducendo la probabilità di impatto materiale da eventi informatici durante l'intero ciclo di vita del codice. FIASSE è un framework creazionale. Affronta il modo in cui la sicurezza viene implementata nel software, collegando direttamente le decisioni ingegneristiche a risultati securable. Non è un framework di assurance, un modello di maturità, né un sostituto di cataloghi di controlli o metriche di vulnerabilità. Integra tali approcci e allevia la pressione a valle su assurance e conformità. ## Scopo Fornire linee guida pratiche che **rendano capaci gli sviluppatori** di creare software securable senza richiedere una profonda competenza in materia di sicurezza, e guidare i professionisti della sicurezza nell'integrare efficacemente la loro esperienza di sicurezza nell'ingegneria del software. FIASSE raggiunge questo obiettivo attraverso una **prospettiva di Ingegneria del Software**, riducendo il carico cognitivo e favorendo la collaborazione tra team di sviluppo e di sicurezza. ## In cosa è diverso? Mentre i progetti focalizzati sull'assurance come l'OWASP Top 10 evidenziano cosa evitare (una block list), OWASP FIASSE fornisce un insieme di attributi e pratiche positive da seguire (una allow list). Questo approccio sfrutta le competenze esistenti di ingegneria del software per costruire software securable, invece di richiedere agli sviluppatori di apprendere tecniche di exploit o adottare una mentalità focalizzata sulle vulnerabilità. L'enfasi è sull'abilitare una codifica pratica e sicura attraverso principi ingegneristici familiari. Definendo chiaramente il ruolo pratico della sicurezza all'interno del processo di sviluppo, questo framework garantisce che il valore aziendale venga catturato efficacemente. Stabilire aspettative di sicurezza esplicite prima che il codice venga scritto riduce la probabilità che difetti di sicurezza vengano scoperti e debbano essere corretti in seguito. Un'adozione efficace dovrebbe migliorare le metriche di assurance esistenti, ridurre il turnover dei risultati, produrre correzioni più durature e abbreviare i tempi di remediation. ## Valori Fondamentali FIASSE è orientato da quattro valori fondamentali. Ciascuno esprime una preferenza relativa: entrambi i lati hanno valore, ma quando è necessario fare delle scelte, FIASSE favorisce il lato sinistro. - **Attributi Securable rispetto ai Controlli di Sicurezza**: preferire le qualità ingegneristiche che consentono a un sistema di essere costruito e mantenuto difendibile rispetto ai controlli di sicurezza aggiunti a posteriori per compensare debolezze. - **Partecipazione rispetto alla Valutazione**: preferire un coinvolgimento strutturato tra sicurezza e sviluppo durante tutto il ciclo di vita rispetto a una valutazione eseguita dopo che il lavoro è stato completato. - **Primi Principi dell'Ingegneria rispetto al Gergo della Sicurezza**: preferire un fondamento sui primi principi consolidati dell'ingegneria del software rispetto al gergo specifico della sicurezza o alle euristiche avversariali. - **Valore Aziendale rispetto all'Attività di Sicurezza**: preferire una sicurezza che sostenga la creazione di valore dell'organizzazione rispetto a una sicurezza perseguita come fine a se stessa. ## Principi Chiave - **Il paradigma securabile**: Non esiste uno stato statico di "sicuro". Un sistema dichiarato sicuro oggi potrebbe essere vulnerabile domani. FIASSE reindirizza l'obiettivo ingegneristico da "è sicuro?" a "è costruito in modo che la sicurezza possa essere mantenuta?" attraverso la resilienza adattiva, la sicurezza evolutiva e il miglioramento continuo. - **Aggiungere valore informatico in modo resiliente**: La direttiva primaria dell'ingegneria del software in un contesto aziendale. Il software deve soddisfare i requisiti funzionali sostenendo al contempo le qualità securabili che gli consentono di resistere al cambiamento, allo stress e agli attacchi che seguono ogni cambiamento. - **Missione di sicurezza: ridurre l'impatto materiale**: La missione della sicurezza è ridurre la probabilità di un impatto materiale di un evento informatico. L'eliminazione completa delle violazioni non è un obiettivo aziendale praticabile, quindi le strategie di sicurezza devono allinearsi agli obiettivi aziendali e alla propensione al rischio. - **La relazione qualità-sicurezza**: La sicurezza non può superare la qualità del software. Le qualità che rendono il software facile da comprendere, modificare, testare e osservare sono le stesse qualità che rendono possibile proteggerlo. L'investimento nella qualità ingegneristica è un investimento nella sicurezza. - **Sicurezza incentrata sullo sviluppatore**: Mettere in grado gli ingegneri del software di costruire sistemi securabili utilizzando principi di ingegneria del software familiari, anziché richiedere loro di adottare la mentalità di un penetration tester. - **SSEM come linguaggio di progettazione comune**: Utilizzare termini consolidati dell'ingegneria del software (ad es. Analizzabilità, Modificabilità, Testabilità) per definire e discutere gli attributi di sicurezza. Ciò rende la sicurezza accessibile agli sviluppatori e fornisce ai professionisti della sicurezza una base condivisa per la valutazione. - **Allineare la sicurezza agli obiettivi di sviluppo e aziendali**: Sicurezza e sviluppo sono complementari, non antagonisti. L'AppSec partecipa precocemente all'SDLC, in particolare durante la raccolta dei requisiti e la pianificazione delle funzionalità, affinché le aspettative siano esplicite prima che il codice venga scritto. - **Il principio di trasparenza**: I sistemi sono progettati in modo che le parti autorizzate possano comprendere lo stato interno e il comportamento. Logging strutturato, strumentazione e tracce di audit sono integrati nel codice anziché essere forniti solo da strumenti esterni. - **Il principio della minima sorpresa**: I sistemi si comportano in modi intuitivi e prevedibili per utenti, sviluppatori e amministratori. La prevedibilità agevola l'analisi, riduce il carico cognitivo e rende chiari i confini di fiducia. - **I requisiti come cittadini di prima classe nell'AppSec**: Funzionalità di sicurezza, scenari di minaccia e criteri di accettazione della sicurezza vengono forniti attraverso il processo dei requisiti. Le vulnerabilità sono comunemente riconducibili a un'aspettativa che non è mai stata specificata, quindi tale lacuna appartiene al processo dei requisiti. ## Principi di ingegneria La sezione 4 del framework fornisce agli sviluppatori principi che si applicano direttamente a livello di codice: - **Il principio di controllo dei confini**: La flessibilità all'interno di un sistema è un bene ingegneristico da preservare. Il controllo a ogni confine di fiducia è un requisito di sicurezza da applicare. - **Gestione canonica dell'input**: Canonicalizzare, validare e sanificare l'input nel punto di ingresso. Il **principio di parsing canonico** analizza l'input esterno in un tipo interno canonico al confine e fallisce in modo sicuro quando l'analisi non riesce. - **Il principio di integrità isolata**: I valori critici per l'integrità, come prezzi, ruoli e stato degli oggetti, derivano da fonti autorevoli lato server. Non vengono mai accettati direttamente da un client. - **Programmazione resiliente**: Le pratiche di programmazione difensiva impongono un'esecuzione prevedibile. Queste includono tipizzazione forte, validazione dell'input ai confini di fiducia, codifica dell'output, gestione completa degli errori, gestione sicura delle risorse, fallimento controllato e sicuro, e privilegio minimo a livello di codice. - **Gestione delle dipendenze**: Applicare gli attributi SSEM durante la selezione, l'integrazione, il monitoraggio e la manutenzione delle dipendenze per tutta la durata della relazione. ## Il modello di ingegneria del software securabile (SSEM) SSEM definisce gli attributi che rendono il software proteggibile. I team stabiliscono obiettivi per ciascun attributo, valutano i sistemi rispetto a essi e migliorano in modo incrementale. Gli attributi sono organizzati in tre categorie: | **Manutenibilità** | **Affidabilità** | **Resilienza** | |:--------------------|:-------------------:|----------------:| | Analizzabilità | Riservatezza | Disponibilità | | Modificabilità | Responsabilità | Integrità | | Testabilità | Autenticità | Resilienza | | Osservabilità | | | SSEM non ha un attributo Autorizzazione per scelta progettuale. L'autorizzazione è una funzionalità di sicurezza che viene raccolta come requisito e implementata in base a criteri di accettazione. Gli attributi sopra elencati sono ciò che rende tale funzionalità proteggibile. L'Appendice A del framework descrive approcci per misurare ciascun attributo. ## Contenuti del Repository - [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md): il framework FIASSE completo e la specifica SSEM in un unico documento. - [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework): il framework suddiviso in un file per sezione. Questi file di sezione sono la fonte di verità per il framework. L'[indice del codice](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) separa le sezioni che si applicano direttamente al codice dalle sezioni su processo, ruoli e adozione. [llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt) fornisce un indice per i modelli linguistici. - [skills/](https://github.com/owasp/fiasse/blob/main/skills): FIASSE e SSEM confezionati come skill per agenti di coding AI (vedi sotto). - TODO: Guide all'implementazione per la metodologia FIASSE - Gli esempi sono stati spostati in [Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement) ## Per Iniziare 1. Consulta la documentazione nella directory [docs](https://github.com/owasp/fiasse/blob/main/docs). Inizia dal [framework completo](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md), oppure usa l'[indice del codice](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) per trovare le sezioni che si applicano al codice in questione. 2. Discuti i concetti e i principi con i tuoi team e nelle [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) 3. Inizia ad applicare i principi nelle tue pratiche di ingegneria del software come la raccolta dei requisiti, le merge review e il prompt engineering. 4. Segui i passaggi di adozione nella Sezione 8 del framework: valuta le pratiche attuali, integra la terminologia SSEM, identifica gli influencer chiave, educa e forma i team, adotta strumenti AppSec agentici come sollievo di capacità, favorisci la collaborazione e monitora e migliora continuamente. - Bonus: installa il plugin corrispondente al tuo IDE o agente da riga di comando basato su AI preferito (ad es. GitHub Copilot, Claude Code, OpenCode, ecc.) e usa i prompt forniti per generare codice proteggibile. Cerca "Securability Engineering" o "FIASSE" nella libreria dei prompt. - FIASSE è incluso anche come parte dell'[OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook). ## Skill per Agenti di Coding AI La directory [`skills/`](https://github.com/owasp/fiasse/blob/main/skills) confeziona FIASSE/SSEM come skill pronte all'uso per agenti di coding AI che supportano il formato [Agent Skills](https://code.claude.com/docs/en/skills) (ad es. Claude Code). Copia la directory della skill di cui hai bisogno nel percorso delle skill del tuo agente. - **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)**: un riferimento compatto e completamente autonomo che copre tutti e dieci gli attributi SSEM e i principi fondamentali (No Static State of Secure, Isolated Integrity, Canonical Input Handling, Boundary Control, Least Astonishment). Pensato come impostazione predefinita per la generazione e la revisione quotidiana del codice. - **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)**: una skill approfondita per lavori ad alto contenuto di contesto e architettonicamente complessi, come la progettazione dei confini di fiducia, i sistemi di autenticazione, i flussi di dati multi-servizio o l'architettura delle dipendenze. Indirizza alla specifica sezione del framework inclusa (in `skills/securable-code/framework/`) rilevante per il codice in questione, scambiando contesto aggiuntivo con il ragionamento completo del framework di origine. Usa `securability` per impostazione predefinita; ricorri a `securable-code` quando le decisioni di progettazione sono sufficientemente non ovvie da giustificare la lettura del framework stesso. ## Riepilogo Questo repository definisce il software rendibile sicuro (securable) come software costruito per rimanere difendibile: strutturato in modo da poter essere compreso, modificato, testato e rafforzato man mano che il mondo attorno ad esso cambia. Sottolinea che la sicurezza è un processo continuo, non un risultato statico. Introduce il Securable Software Engineering Model (SSEM), che inquadra la sicurezza come un insieme intrinseco di qualità di un software ben progettato. A tal fine, presenta le categorie di attributi di Manutenibilità, Affidabilità (Trustworthiness) e Robustezza (che include la Resilienza). FIASSE sostiene l'integrazione delle pratiche di sicurezza nel flusso di lavoro di sviluppo laddove hanno il maggiore impatto. Questo segna il passaggio da un approccio "sicurezza come ripensamento" o "shift left" a un modello proattivo e collaborativo. I product owner, gli sviluppatori e i professionisti della sicurezza lavorano insieme fin dalle prime fasi della progettazione, in particolare attraverso la definizione dei requisiti di sicurezza, la modellazione collaborativa delle minacce e i criteri di accettazione della sicurezza. Ciò stabilisce aspettative chiare per le attività sul codice e i test. Le revisioni di merge fungono da guardrail, non da cancelli. Ogni merge produce un Securability Report consultivo, e il gating è una decisione politica con un percorso di override. I risultati della validazione e della produzione sono trattati come intelligence empirica che punta a monte, verso la fase che avrebbe potuto prevenirli. Agli ingegneri del software vengono fornite indicazioni su come bilanciare flessibilità e controllo. Viene inoltre fornito loro un modello definitivo per prendere decisioni in materia di sicurezza. In definitiva, ciò consente a tutti gli stakeholder di contribuire alla costruzione di sistemi più robusti, affidabili e intrinsecamente rendibili sicuri. FIASSE si differenzia dagli approcci esistenti perché non richiede agli sviluppatori di diventare esperti di sicurezza o di adottare una mentalità adversarial. Nomina i comuni anti-pattern dell'AppSec, come lo "Shoveling Left" dell'output grezzo degli strumenti sugli sviluppatori e la formazione basata sull'exploit-first, e li sostituisce con l'Actionable Security Intelligence Principle. Questo approccio mira a ridurre il carico cognitivo sugli sviluppatori garantendo al contempo che i professionisti della sicurezza possano avere la certezza che le loro preoccupazioni siano affrontate attraverso attributi specifici del codice e dei processi di ingegneria del software. FIASSE intende essere aperto, accessibile e collaborativo. ## Roadmap Milestone iniziali per il progetto FIASSE: - **Fondazione del progetto** - Istituzione della governance del progetto, delle linee guida per i contributi e dei canali di comunicazione. - **Specifiche principali** - Pubblicazione formale del framework FIASSE e della specifica SSEM, con dettaglio degli attributi principali e delle strategie di integrazione. - **Adozione e risorse educative** - Un Primer SSEM per introdurre il modello e la sua applicazione. - Una raccolta di casi d'uso iniziali e pattern di adozione per illustrare i benefici pratici. - Sviluppo continuo di guide all'implementazione, esempi e altri materiali educativi. Ulteriori milestone saranno sviluppate con il team del progetto. Il contributo della community è benvenuto tramite [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions). ## Risorse complementari Questo repository è complementare al [sito web FIASSE](https://fiasse.org). Il progetto [OWASP FIASSE](https://owasp.org/www-project-fiasse/) fa parte della [OWASP Foundation](https://owasp.org/), un'organizzazione no-profit focalizzata sulla missione di eliminare il software non sicuro. La OWASP Foundation fornisce una ricchezza di risorse e framework che si allineano ai principi di FIASSE. Questo framework è incentrato sulla Securable Software Engineering ed è complementato da altri progetti OWASP: - Verifica delle funzionalità di sicurezza e una libreria pronta all'uso di requisiti di sicurezza: [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) - Maturità dell'assicurazione: [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/) - Conformità della sicurezza del prodotto: [OWASP Product Security Capability Framework (PSCF)](https://owasp.org/www-project-product-security-capability-framework/) OWASP ospita inoltre numerosi progetti che documentano requisiti e funzionalità di sicurezza, come [OWASP Mobile Application Security](https://mas.owasp.org/). La [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/) è una risorsa completa per varie altre risorse OWASP. Un'altra ottima risorsa per requisiti di riferimento e pratiche di assurance è [OpenCRE](https://opencre.org/), che raccoglie e mappa vari framework di sicurezza. I cataloghi di controlli come NIST SP 800-53, ISO/IEC 27001 Annex A e PCI DSS supportano la gestione del rischio, l'assicurazione e la valutazione esterna. FIASSE non li sostituisce. Li tratta come input per la raccolta dei requisiti, dove un controllo del catalogo viene tradotto in un requisito di sicurezza con criteri di accettazione prima che lo sviluppo lo implementi. Il [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final) del NIST definisce un insieme fondamentale di pratiche di sviluppo sicuro del software organizzate in quattro gruppi. FIASSE non definisce un tale insieme di pratiche. Si allinea con l'SSDF enfatizzando l'integrazione della sicurezza nel ciclo di vita dello sviluppo del software. Il [Software Security Code of Practice](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance) del NCSC definisce gli esiti desiderati e alcune strategie chiave. FIASSE si concentra su principi e strategie di primo livello per ottenere esiti rendibili sicuri, destinati ai team di Development e Assurance per allinearsi alle strategie aziendali. SSEM specifica gli attributi utilizzati per produrre gli esiti desiderati, e la metodologia FIASSE fornisce una guida pratica per implementare questi attributi nelle pratiche di ingegneria del software. Gli standard di codifica sicura [CERT](https://www.cert.org/) della Carnegie Mellon University sono un insieme di regole a livello di linguaggio che forniscono sia esempi di "cosa non fare" mostrando pattern di codice vulnerabile, sia esempi di "cosa fare". FIASSE integra queste regole fornendo un approccio basato su principi che aiuta i programmatori a comprendere il "perché?" dietro il codice rendibile sicuro. Il Software Factory Security Framework ([SF2](https://sf2framework.com/)) "fornisce ai leader della sicurezza un approccio strategico per scalare le capacità di sicurezza migliorando al contempo i risultati aziendali". È un framework a livello organizzativo che integra l'attenzione di FIASSE sulle pratiche di ingegneria del software. ## Contributing I contributi per migliorare la documentazione e gli esempi sono benvenuti. Consulta le nostre [linee guida per i contributi](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md) per i dettagli. ## License Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) - consulta il file [LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt) per i dettagli. ## Acknowledgments Questo progetto è uno sforzo collaborativo della community OWASP. Ringraziamo tutti i contributori per il loro prezioso contributo e la loro dedizione al miglioramento della sicurezza del software. È disponibile una [lista dei contributori](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md) che hanno partecipato a questo progetto. Alcuni contributori iniziali hanno contribuito a plasmare i concetti iniziali e a fare red team sulle idee.
