La gestione del rischio architetturale rappresenta una delle sfide più critiche nello sviluppo del software moderno, soprattutto quando si adottano metodologie Agile che, per loro natura, tendono a posticipare le decisioni di progettazione strutturale.
L’analisi del framework AARM (Agile Architecture Risk Management), proposto dal Software Engineering Institute della Carnegie Mellon University, integrandolo con i principi del Continuous Risk Management (CRM), ne illustra le implicazioni nel dominio della cyber security.
L’obiettivo è fornire una guida operativa che permetta di identificare precocemente i rischi architetturali, di valutare i trade-off tra design pattern e quality attributes e di ridurre la superficie di attacco sin dalle fasi iniziali dello sviluppo.
L’analisi ha dimostrato che l’adozione sistematica della matrice Pattern/Quality Attribute, combinata con sessioni strutturate di Risk Storming, può prevenire l’accumulo di debito tecnico che ha ripercussioni sulla sicurezza, riducendo significativamente il costo e la complessità delle attività di remediation tardive.
Indice degli argomenti
La gestione del rischio architetturale nello sviluppo Agile
Lo sviluppo software secondo metodologie Agile ha trasformato profondamente il ciclo di vita dei sistemi, apportando indubbi benefici in termini di velocità di rilascio e adattabilità ai requisiti mutevoli.
Tuttavia, questa trasformazione ha generato una lacuna strutturale: la gestione del rischio architetturale viene sistematicamente posticipata, spesso fino a quando i problemi diventano troppo costosi o impossibili da correggere.
La ricerca condotta dal Software Engineering Institute (SEI) della Carnegie Mellon University ha dimostrato che i difetti architetturali scoperti in ritardo nel ciclo di vita di un sistema comportano costi esponenzialmente più elevati rispetto a quelli individuati nelle fasi iniziali.
Per i professionisti della sicurezza informatica, questa dinamica è ancora più rilevante:le vulnerabilità strutturali radicate nell’architettura non sono semplici bug da correggere, ma vettori di attacco sistemici che possono compromettere l’intera postura di sicurezza di un sistema.
Ecco l’analisi del framework AARM (Agile Architecture Risk Management), proposto da Rosso-Llopart e Root nel 2026, esaminandone i meccanismi fondamentali e reinterpretandoli attraverso la lente della cyber security.
L’obiettivo è duplice:
- fornire ai professionisti della sicurezza che operano in contesti Agile una comprensione approfondita del modello;
- proporre un’applicazione pratica orientata alla riduzione proattiva della superficie di attacco.
Ricordiamo che la maggior parte delle recenti normative in materia di cyber security e i framework richiedono esplicitamente un approccio risk-based integrato in tutte le fasi dellos viluppo che includa la sicurezza informatica, i test e la valutazione come componenti imprescindibili.
AARM fornisce il meccanismo operativo per tradurre questi requisiti normativi in pratiche Agile concrete.
Definizione e rilevanza per la sicurezza del rischio architetturale
Lattanze (2019) definisce il rischio architetturale come l’incapacità intrinseca di un sistema software di promuovere gli obiettivi degli stakeholder, ovvero i quality attribute.
Questa definizione, apparentemente tecnica, ha profonde implicazioni per la sicurezza: un’architettura che non supporta adeguatamente attributi quali la riservatezza, l’integrità e la disponibilità dei dati non è semplicemente subottimale, ma è insicura per design.
I quality attribute rilevanti per la sicurezza informatica includono, ma non si limitano a:
- affidabilità: grado in cui il sistema opera in modo specificato sotto condizioni definite;
- sicurezza: protezione di dati e informazioni con livelli di autorizzazione appropriati;
- disponibilità: percentuale di tempo in cui il sistema è disponibile per operare;
- manutenibilità: efficienza con cui il sistema può essere modificato;
- portabilità: facilità di trasferimento tra ambienti hardware/software.
Tutti questi attributi, secondo la classificazione ISO/IEC 25010:2023, sono influenzati direttamente dalle scelte architetturali effettuate durante lo sviluppo.
Il Framework AARM
AARM (Gomes & Pinheiro, 2022; Rosso-Llopart & Root, 2026) è un framework che consente di valutare in modo continuo il rischio architetturale durante i principali sprint di pianificazione e sviluppo.
La sua struttura si basa su quattro pilastri fondamentali, applicati in modo iterativo:
- strategia di prodotto/business: conferma degli obiettivi strategici (mission goals) per ciascun planning interval;
- prioritizzazione delle caratteristiche architetturali: definizione e validazione dei quality attribute che abilitano il valore atteso;
- risk sprint storming: valutazione collaborativa dell’impatto tattico delle scelte implementative e dei design pattern adottati;
- storie architetturali: creazione di storie che rendono visibile a tutto il team il valore delle scelte architetturali.
La peculiarità di AARM rispetto ad altri approcci risiede nella sua natura incrementale: il rischio non viene valutato una tantum, ma ad ogni sprint, garantendo che le deviazioni architetturali vengano rilevate prima che si cristallizzino in un debito tecnico irrecuperabile.
Continuous Risk Management (CRM)
Il CRM (Dorofee, 1996) fornisce il meccanismo operativo per la raccolta e la gestione delle incertezze (concerns) durante l’avanzamento Agile.
Il modello distingue tra incertezze individuali e di gruppo e le elabora attraverso una pipeline che porta alla formulazione di “Statement of Risk”, ovvero affermazioni fattuali che descrivono un rischio con la sua causa radice e la potenziale conseguenza.
Per la cyber security, questa distinzione è fondamentale: non tutte le preoccupazioni possono essere considerate dei rischi.
Un security manager deve concentrare le proprie risorse limitate sui rischi supportati da prove concrete, come la dipendenza da una libreria nota per le sue vulnerabilità, un modello architetturale che introduce un punto singolo di fallimento o l’assenza di meccanismi di isolamento tra componenti con diversi livelli di affidabilità.
Ricordiamo un principio fondamentale del CRM per la cyber security: un concern di sicurezza diventa un rischio tracciabile solo quando è supportato da uno Statement of Fact.
Un esempio
Il pattern Singleton, utilizzato per la gestione delle sessioni, introduce un Single Point of Failure (SPF) che può essere sfruttato per attacchi di tipo Session Fixation o Denial-of-Service contro il gestore delle credenziali.
La Pattern/Quality Attribute Matrix per la sicurezza: la struttura della matrice
Lo strumento centrale di AARM è la Pattern/Quality Attribute Matrix, sviluppata originariamente da Mark Richards nel 2020.
La matrice mappa i design pattern del Gang of Four rispetto agli attributi di qualità ISO/IEC 25010 e identifica, per ciascuna combinazione, se il pattern favorisce (+), degrada (-) o è neutro (=) rispetto all’attributo considerato.
Dal punto di vista della sicurezza informatica, questa matrice costituisce uno strumento di threat modeling architetturale che consente di individuare, già in fase di sprint planning, quali scelte progettuali introducono debolezze strutturali che potrebbero essere sfruttate da un attaccante.
In pratica, si tratta di spostare la revisione della sicurezza dall’analisi del codice all’analisi dell’architettura.
Analisi dei pattern critici per la cyber security
La seguente tabella sintetizza l’impatto dei principali design pattern sui quality attribute di maggiore rilevanza per la sicurezza, integrando l’analisi della matrice AARM con considerazioni specifiche per i professionisti della cyber security.
| Pattern | Pattern | Reliabil ity | Availability | Maintainability | Implicazione Sicurezza |
| Singleton | – | -(SPF) | – | – | Rischio credential management centralizzato; no isolation |
| Observer/Pub-Sub | = | – (SPF) | + | + | Event injection; mancanza di validazione sui messaggi |
| Factory Method | = | = | = | + | Riduce accoppiamento; facilita mock per security testing |
| Adapter | + | = | = | + | Wrapping controllato; rischio di bypassing dell’interfaccia |
| Proxy | + | + | + | = | Ottimo per access control, rate limiting, audit logging |
| Composite | – | –(SPF) | + | + | Dipendenze gerarchiche; propagazione errori/attacchi |
| Strategy | + | + | = | + | Isolamento algoritmi; agevole sostituzione crypto primitives |
| Chain of Resp. | – | = | = | + | Difficile audit trail; possibile bypass di controlli |
Tabella 1. Impatto dei design pattern sui quality attributes di sicurezza (+ favorisce, – degrada, = neutro, SPF = Single Point of Failure).
Integrazione con il Threat Modeling
L’utilizzo della Pattern/Quality Attribute Matrix in ottica cyber security si integra naturalmente con le metodologie di threat modeling consolidate.
In particolare, è possibile creare un ponte metodologico con STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), mappando i pattern architetturali alle categorie di minaccia che favoriscono o mitigano.
Questa integrazione trasforma il Risk Storming da un esercizio puramente architetturale a una sessione di threat modeling strutturato, in cui gli sviluppatori non si chiedono solo se “questo pattern supporta il quality attribute X?”, ma anche se “questo pattern introduce vulnerabilità alle categorie di minaccia Y e Z?”.
| Categoria STRIDE | Pattern a Rischio | Pattern Mitigante |
| Spoofing | Singleton (auth centralizzata), Observer (no validation) | Proxy (identity enforcement), Strategy (crypto agility) |
| Tampering | Chain of Responsibility (bypass), Composite (propagation) | Decorator (input validation layers), Proxy (integrity check) |
| Repudiation | Observer (no audit), Pub-Sub (no origin tracking) | Command (audit trail), Memento (state capture) |
| Info Disclosure | Facade (over-exposure), Singleton (global state) | Proxy (data masking), Adapter (interface isolation) |
| Denial of Service | Singleton (SPF), Composite (SPF gerarchico) | Strategy (circuit breaker), Factory (object pooling) |
| Elevation of Privilege | Chain of Resp. (skip controls), Observer (event injection) | Proxy (access control), Strategy (least privilege algo) |
Tabella 2. Mappatura Pattern Architetturali – Categorie di Minaccia STRIDE.
Processo operativo AARM per la cyber security: attività a livello di Planning Interval
In ogni Planning Interval (PI), il team di sviluppo deve integrare due attività di valutazione architetturale rilevanti per la sicurezza:
- revisione della Mission Security Strategy: identificazione degli obiettivi di sicurezza per l’intervallo corrente e verifica dell’allineamento con la postura di rischio complessiva del sistema;
- prioritizzazione degli attributi di sicurezza: ranking dinamico dei quality attribute di sicurezza (riservatezza, integrità, disponibilità e non ripudiabilità) in funzione delle minacce emergenti e dei requisiti normativi applicabili.
In questa fase, è necessario condurre una revisione formale dell’architettura per verificare che il sistema non si sia discostato significativamente da quello originale.
Se si rileva una deviazione, gli sviluppatori devono verificare che la nuova architettura supporti ancora i requisiti di qualità, di sicurezza, i fattori trainanti della missione e i requisiti di conformità applicabili.
Risk Sprint Storming con Focus Sicurezza
Il Risk Sprint Storming è la fase centrale di AARM. Per i team che includono professionisti della cyber security, si consiglia l’adozione di un formato specifico denominato ‘Security Architecture Monday’, da condurre il primo giorno di ogni sprint secondo lo schema operativo seguente.
Formulazione degli Statement of Risk per la sicurezza
Il CRM richiede che ogni concern sia supportato da uno Statement of Fact prima di poter essere elevato a rischio tracciabile.
Questa fase è particolarmente critica in ambito security, dove la proliferazione di ‘what-if’ non fondati distoglie risorse dalla mitigazione delle minacce reali. Un Statement of Risk ben formulato per la cyber security deve rispettare la struttura: Condizione + Conseguenza + Quality Attribute Impattato.
Di seguito, tre esempi pratici derivati dall’analisi dei pattern architetturali.
Esempio 1: Pattern Singleton
- Condizione: Il modulo di autenticazione implementa il pattern Singleton per la gestione delle sessioni attive.
- Conseguenza: Un attacco di tipo Session Hijacking o un crash del Singleton compromette simultaneamente tutte le sessioni attive.
- Quality Attribute: Reliability (–), Security (–), Availability (–).
- Statement of fact: ‘L’architettura corrente non prevede meccanismi di failover per il gestore delle sessioni; il 100% delle sessioni è gestito da una singola istanza non replicata.’
Esempio 2: Pattern Observer/Pub-Sub
- Condizione: Il sistema utilizza un’architettura event-driven basata sul pattern Observer per la comunicazione tra microservizi.
- Conseguenza: L’assenza di validazione e autenticazione degli eventi pubblicati abilita attacchi di Event Injection, compromettendo l’integrità del flusso di dati.
- Quality Attribute: Security (=→–), Reliability (–).
- Statement of fact: ‘I messaggi sul message broker non sono firmati digitalmente; non esiste un meccanismo di autorizzazione per i publisher.’
Esempio 3 – Pattern Strategy
- Condizione: Il modulo crittografico utilizza il pattern Strategy per selezionare l’algoritmo di cifratura a runtime.
- Conseguenza: Se la selezione della strategy non è controllata, un attaccante potrebbe forzare l’utilizzo di algoritmi deboli (Algorithm Downgrade Attack).
- Quality Attribute: Security (+ se controllato, – se non controllato).
- Statement of fact: ‘L’attuale implementazione non include una whitelist degli algoritmi permessi; la selezione avviene tramite parametro configurabile dall’esterno.’
Architecture Decision Records (ADR) e Sicurezza
Il tracking dei rischi architetturali dovrebbe avvenire tramite Architecture Decision Records (ADR) estesi con informazioni sulla sicurezza. Un ADR sicurezza-aware include, oltre ai campi standard, i seguenti attributi aggiuntivi:
- Security Quality Attributes impattati dalla decisione architetturale.
- Mapping Stride: categorie di minaccia favorite o mitigate.
- Compliance impact: requisiti normativi potenzialmente interessati (es. GDPR, NIS2, ISO 27001).
- Metriche di monitoraggio: indicatori che segnalano quando il rischio si sta
materializzando. - Acceptance criteria di sicurezza: condizioni misurabili che definiscono quando il rischio è stato mitigato.
Metriche architetturali con valenza di sicurezza
AARM identifica un insieme di metriche architetturali (ripreso da Nipun, 2020) che gli sviluppatori possono utilizzare per individuare le aree a rischio. Dal punto di vista della sicurezza informatica, queste metriche assumono un significato aggiuntivo in quanto indicatori del degrado della postura di sicurezza.
L’utilizzo di strumenti di analisi statica, come SonarQube o Arcan, per il rilevamento degli “architectural smells” (decisioni architetturali comunemente adottate che hanno un impatto negativo sulla qualità del sistema) dovrebbe far parte integrante della pipeline CI/CD.
Un “architectural smell” rilevato automaticamente costituisce, per definizione, un “Statement of Fact” secondo la terminologia CRM, che abilita immediatamente la formulazione di un rischio tracciabile.
Quando identificare i rischi: trigger points per la sicurezza
Rosso-Llopart e Root (2026) individuano un insieme di condizioni che dovrebbero attivare un’analisi del rischio architetturale.
Espandiamo questo elenco con trigger specifici per la sicurezza informatica.
Metodologie complementari per l’Initial Architecture Security Review
AARM presuppone l’esistenza di un’architettura iniziale di riferimento. Per i professionisti della cyber security, questa fase iniziale è fondamentale per stabilire la baseline di sicurezza del sistema.
Il framework identifica diverse metodologie applicabili in questa fase, ciascuna con specifiche peculiarità in termini di sicurezza.
STPA (System Theoretic Process Analysis)
STPA (Leveson & Thomas, 2018) analizza le possibili interazioni non sicure tra i componenti del sistema, indipendentemente dal fallimento dei singoli componenti.
Dal punto di vista della cyber security, STPA è particolarmente efficace nell’identificare scenari in cui componenti singolarmente sicuri interagiscono in modi che creano vulnerabilità sistemiche, una dinamica comune negli attacchi alla supply chain e negli attacchi che sfruttano la composizione dei servizi.
ATAM (Architectural Trade-off Analysis Method)
ATAM produce un Utility Tree che quantifica il valore architetturale di ciascun quality attribute in funzione della difficoltà di implementazione.
Per quanto riguarda la sicurezza, questo strumento permette di rendere espliciti i trade-off tra sicurezza e altri attributi (es. performance, usability), costringendo a prendere decisioni consapevoli e documentate piuttosto che a rinunce implicite ai controlli di sicurezza per ragioni di velocità di sviluppo.
ACDM (Architecture-Centric Design Method)
L’ACDM (Lattanze, 2006) include esplicitamente un’Architectural Risk Analysis come Stage 4 del processo, durante il cosiddetto Period of Uncertainty (Stadi 3-5).
In questa fase, i candidati architetturali vengono valutati in base ai rischi tecnici identificati, inclusi quelli relativi alla sicurezza. In questa fase, la matrice degli attributi architetturali viene applicata per confrontare i punti di forza e di debolezza dei pattern candidati.
Implicazioni pratiche e raccomandazioni operative
Per il Security Architect:
- integrare la Pattern/Quality Attribute Matrix nelle security review dell’architettura; aggiornare la matrice ad ogni sprint con i nuovi pattern introdotti;
- mantenere un Security Architecture Decision Record (SADR) che documenti ogni decisione architetturale con le relative implicazioni in termini di sicurezza e i rischi associati;
- condurre almeno una sessione di Security Architecture Monday per sprint,
preferibilmente il primo giorno disponibile; - stabilire delle metriche di sicurezza architetturale (coupling, complexity, pattern density) come parte della Definition of Done per ogni sprint.
Per il Security Engineer / Penetration Tester:
- utilizzare la matrice AARM come input per il threat modeling: i pattern con impatto negativo su Security e Reliability sono candidati ideali per test mirati;
- integrare i risultati della Pattern/Quality Attribute Matrix nella fase di reconnaissance architetturale di un penetration test, per identificare le aree strutturalmente deboli;
- proporre architectural security stories per le vulnerabilità strutturali identificate, trasformando i finding di sicurezza in backlog item tracciabili.
Per il Compliance Officer / CISO:
- verificare che i quality attributes di sicurezza imposti dai framework normativi applicabili (ISO 27001, NIS2, DORA, NIST CSF) siano esplicitamente inclusi nella prioritizzazione AARM;
- richiedere che gli ADR includano una sezione di compliance impact per le decisioni architetturali che toccano i dati personali, i sistemi critici o le infrastrutture essenziali;
- utilizzare i Risk Statements CRM come evidenza documentale per le attività di audit: un rischio identificato, tracciato e mitigato attraverso AARM costituisce prova di due diligence nella gestione del rischio.
Limitazioni del framework AARM
Il framework AARM presenta alcune limitazioni che i professionisti della sicurezza dovrebbero considerare prima di adottarlo:
- Maturità della matrice: la Pattern/Quality Attribute Matrix è ancora in fase di sviluppo, come riconosciuto dagli stessi autori. L’utilizzo nei contesti operativi di sicurezza richiede un’ulteriore validazione empirica, in particolare per i pattern specifici del dominio (es. microservices security patterns, zero-trust architecture patterns).
- Dipendenza dalla competenza: l’efficacia del Risk Storming dipende dalla conoscenza approfondita dell’architettura e della sicurezza da parte dei partecipanti. In assenza di una formazione adeguata, le sessioni possono generare concerns infondati o trascurare rischi strutturali significativi.
- Contesto: il framework è stato sviluppato per il contesto del Dipartimento della Difesa americano. L’adattamento a contesti civili o regolamentati da framework europei (NIS2, DORA, GDPR) richiede un mapping esplicito tra i quality attributes AARM e i controlli normativi applicabili.
- Assenza di automazione: ad oggi, non esistono strumenti che automatizzino la compilazione della Pattern/Quality Attribute Matrix attraverso l’analisi statica del codice. L’integrazione con tool esistenti (SonarQube, Dependabot, Syft) rappresenta una direzione di ricerca.
Le direzioni di ricerca future più interessanti per la comunità della cyber security includono:
- lo sviluppo di una Security Pattern Matrix estesa che includa pattern specifici per architetture zero-trust, container-based e serverless;
- l’integrazione automatica di AARM con le pipeline SAST/DAST per la generazione automatica di Statements of Risk;
- la validazione empirica del framework su casi di studio riguardanti sistemi regolamentati soggetti a NIS2 e DORA.
La gestione del rischio architetturale in contesti Agile
Il framework AARM proposto da Rosso-Llopart e Root (2026) rappresenta un contributo significativo alla gestione del rischio architetturale in contesti Agile e ha implicazioni rilevanti per i professionisti della cyber security.
La sua integrazione con il Continuous Risk Management e la Pattern/Quality Attribute Matrix fornisce un meccanismo operativo per uno shift-left della security review dall’analisi del codice all’analisi dell’architettura.
Il messaggio centrale per i professionisti della sicurezza è chiaro: le vulnerabilità strutturalmente radicate nell’architettura non sono bug da correggere con le patch, ma rischi da identificare e gestire proattivamente durante tutto il ciclo di sviluppo.
Un’architettura che non promuove i quality attribute di sicurezza è, per definizione, insicura, a prescindere dalla qualità delle singole implementazioni.
L’adozione della “Security Architecture Monday”, la manutenzione sistematica dei Security Architecture Decision Records e l’utilizzo della Pattern/Quality Attribute Matrix come strumento di threat modeling sono pratiche operative concrete che gli sviluppatori possono adottare immediatamente, a prescindere dal livello di maturità del processo Agile utilizzato.
In un panorama di minacce in continua evoluzione, la sicurezza by design non può essere un obiettivo astratto, ma deve essere un processo strutturato, iterativo e misurabile.
AARM offre esattamente questo framework, traducendo i principi architetturali in azioni concrete per una gestione proattiva del rischio di sicurezza.
Riferimenti Bibliografici
- Bass, L. et al. (2022). Software Architecture in Practice, 4th Edition. Addison-Wesley Professional.
- Dorofee, A. et al. (1996). Continuous Risk Management Guidebook. Software Engineering Institute, Carnegie Mellon University.
- DoW (2020a). Operation of the Software Acquisition Pathway. DoDI 5000.87.
- DoW (2022). Risk Management Framework for DoD Systems. DoDI 8510.01.
- Gamma, E. et al. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional.
- Gomes, C. & Pinheiro, R. (2022). Architectural Risk Management. Thoughtworks Website.
- ISO/IEC (2023). Systems and Software Engineering – Systems and Software Quality Requirements and Evaluation (SQuaRE). ISO/IEC 25010:2023.
- Lattanze, A.J. (2006). Architecture Centric Design Method. Saturn 2006 Conference. Software Engineering Institute.
- Lattanze, A.J. (2019). Managing Technical Debt with Continuous Architecture. LinkedIn.
- Leveson, N.G. & Thomas, J.P. (2018). STPA Handbook. Massachusetts Institute of Technology.
- Nipun (2020). Performance Metrics Used in Design of Software Architecture. GeeksProgramming.
- Ozkaya, I. (2021). Managing Technical Debt. Software Engineering Institute, Carnegie Mellon University.
- Richards, M. (2020). Fundamentals of Software Architecture. O’Reilly Media
- Rosso-Llopart, M. & Root, D.B. (2026). Managing Architectural Risk During Agile Development. CMU/SEI Report. Carnegie Mellon University
- Rosso-Llopart, M. (2025). Minimally Viable Architecture: Architecture Early in Development. CMU/SEI-2025-TN-001. Carnegie Mellon University.
- SEI (2023). SEI Team Leads First Independent Study on Technical Debt in Software-Intensive DoD Systems. Software Engineering Institute.
- Shostack, A. (2014). Threat Modeling: Designing for Security. Wiley.
- Uzun, B. & Tekinerdogan, B. (2024). Detecting Deviations in the Code Using Architecture View- Based Drift Analysis. Computer Standards & Interfaces, 87.
