Che cos'è la sicurezza delle applicazioni?
Un singolo endpoint API vulnerabile. Una libreria open-source non aggiornata. Un container mal configurato in produzione. Ognuno di questi può consegnare a un attaccante le chiavi del tuo ambiente. Il Verizon DBIR conferma che lo sfruttamento delle vulnerabilità è un vettore di accesso iniziale sempre più comune per le violazioni.
La sicurezza delle applicazioni (AppSec) comprende i processi, le pratiche e gli strumenti utilizzati per individuare, correggere e proteggere dalle vulnerabilità nelle applicazioni durante tutto il ciclo di vita dello sviluppo software (SDLC). L'ambito si estende oltre il codice applicativo per includere impostazioni di sistema, API, database, librerie di terze parti e l'infrastruttura su cui girano le applicazioni.
Application Security Testing (AST) è la disciplina che analizza il software per identificare debolezze di sicurezza, problemi di conformità e vulnerabilità sfruttabili utilizzando sia tecniche manuali sia strumenti specializzati. L'AST viene applicato durante tutto il SDLC, dalle prime linee di codice fino all'esecuzione in produzione, con un unico obiettivo: trovare e correggere le debolezze prima che vengano sfruttate dagli attaccanti.
L'AppSec non opera in isolamento. Comprendere dove si colloca all'interno del programma di sicurezza più ampio è essenziale per evitare lacune di copertura.
Perché la sicurezza delle applicazioni è importante?
L'AppSec occupa un livello specifico nella strategia di cybersecurity più ampia. Mentre la sicurezza di rete protegge i dati in transito, i perimetri e i segmenti di infrastruttura, la sicurezza delle applicazioni protegge la logica software, le interfacce e l'elaborazione dei dati che operano su quell'infrastruttura.
Queste discipline sono complementari, non intercambiabili. Un firewall blocca il traffico malevolo al perimetro. La sicurezza delle applicazioni blocca un attacco SQL injection che sfrutta una vulnerabilità nel codice. Piani strategici che confondono le due producono esposizioni non affrontate a livello applicativo, proprio dove gli attaccanti si concentrano sempre di più.
Questa convergenza continua ad approfondirsi. La documentazione OWASP per la OWASP Top 10 osserva che diversi rischi critici si manifestano solo in produzione, confermando che la sicurezza delle applicazioni non può fermarsi alla fase di build. Deve estendersi alla visibilità in runtime, dove la protezione degli endpoint, la sicurezza dei workload cloud e gli strumenti AppSec convergono in una difesa unificata.
Prima di selezionare gli strumenti, è necessario comprendere le minacce che sono progettati per affrontare.
Minacce comuni alla sicurezza delle applicazioni
La OWASP Top 10:2025 definisce i rischi più diffusi per le applicazioni web. Queste categorie determinano come i team AppSec danno priorità ai test e alle difese in runtime.
Le categorie più impattanti includono:
- Broken access control rimane il rischio principale. Difetti nella logica di autorizzazione consentono agli attaccanti di accedere a dati o funzioni al di fuori dei permessi previsti.
- Injection flaws come SQL injection e cross-site scripting (XSS) permettono agli attaccanti di inserire codice malevolo tramite campi di input non sanificati, compromettendo database e sessioni utente.
- Software supply chain failures coprono i rischi derivanti da componenti open-source vulnerabili, dipendenze compromesse e verifica insufficiente del codice di terze parti. CISA ha emesso avvisi formali su compromissioni della supply chain che colpiscono l'ecosistema npm.
- Security misconfiguration include credenziali di default, servizi non necessari e impostazioni cloud troppo permissive che espongono le applicazioni a sfruttamento.
- Cryptographic failures riguardano cifrature deboli encryption, chiavi esposte o assenza di sicurezza a livello di trasporto che lasciano i dati sensibili leggibili in transito o a riposo.
- Server-side request forgery (SSRF) consente agli attaccanti di forzare un'applicazione a effettuare richieste verso risorse interne, spesso aggirando firewall e controlli di accesso.
Ogni categoria prende di mira una parte diversa dello stack applicativo. Gli strumenti e le pratiche trattati nelle sezioni seguenti sono direttamente collegati a questi rischi.
Componenti principali della sicurezza delle applicazioni
Il tuo programma AppSec si basa su sei strumenti principali, ciascuno dei quali copre una fase distinta del SDLC.
- SAST (Static Application Security Testing) analizza il codice sorgente, bytecode o codice binario alla ricerca di vulnerabilità di sicurezza senza eseguire l'applicazione. Questo metodo white-box esamina il codice per vulnerabilità come SQL injection, cross-site scripting (XSS) e buffer overflow, indicando la linea esatta che richiede correzione. Opera nella fase di sviluppo, rappresentando il primo controllo di sicurezza nella pipeline.
- DAST (Dynamic Application Security Testing) adotta l'approccio opposto. Testa un'applicazione in esecuzione dall'esterno verso l'interno, simulando attacchi reali contro vulnerabilità che emergono solo in runtime. Questo metodo black-box non richiede accesso al codice sorgente e individua errori di autenticazione, configurazioni errate del server e vulnerabilità API durante QA, staging o produzione.
- SCA (Software Composition Analysis) esegue la scansione delle applicazioni per componenti open-source e librerie di terze parti al fine di identificare CVE noti e rischi di conformità delle licenze. Poiché la OWASP Top 10 include i Software Supply Chain Failures tra i rischi principali, SCA è diventato un controllo di base. Viene eseguito continuamente dallo sviluppo iniziale fino alla produzione.
- IAST (Interactive Application Security Testing) opera dall'interno dell'applicazione tramite un agente durante i test funzionali, combinando elementi di SAST e DAST per analizzare il codice in esecuzione in tempo reale con pochi falsi positivi. NIST 800-53 SA-11(9) richiede esplicitamente strumenti IAST per identificare difetti e documentare i risultati.
- RASP (Runtime Application Self-Protection) integra funzionalità di sicurezza direttamente nelle applicazioni, proteggendole una volta distribuite. RASP integra i test pre-deployment bloccando gli exploit in tempo reale nell'ambiente di produzione. NIST 800-53 SI-7(17) impone controlli di auto-protezione in runtime.
- WAF (Web Application Firewall) filtra e monitora il traffico HTTP tra l'applicazione web e Internet. Operando al perimetro di rete, protegge dagli exploit web più comuni utilizzando regole come la OWASP ruleset che copre SQL injection, XSS e file inclusion locale.
La tabella seguente riassume come questi strumenti differiscono lungo il SDLC:
| Strumento | Fase SDLC | Approccio | Copertura primaria |
| SAST | Sviluppo | White-box (codice sorgente) | Vulnerabilità a livello di codice: injection, XSS, buffer overflow |
| DAST | QA / Staging | Black-box (app in esecuzione) | Autenticazione, configurazioni errate, vulnerabilità API |
| SCA | Sviluppo → Produzione | Scansione delle dipendenze | CVE open-source, conformità licenze |
| IAST | Test funzionali | Basato su agente (interno all'app) | Vulnerabilità in runtime con pochi falsi positivi |
| RASP | Produzione | Inside-out (integrato) | Blocco exploit in tempo reale |
| WAF | Produzione | Outside-in (perimetro di rete) | Attacchi a livello HTTP: SQLi, XSS, file inclusion |
SAST e DAST forniscono informazioni diverse e nessuno sostituisce l'altro. In runtime, WAF opera outside-in a livello di rete, mentre RASP opera inside-out dall'interno dell'applicazione.
Comprendere cosa fa ciascuno strumento è solo metà dell'equazione; la vera domanda è come lavorano insieme lungo la pipeline di sviluppo e distribuzione.
Come funziona la sicurezza delle applicazioni
L'AppSec funziona integrando controlli di sicurezza in ogni fase del SDLC, seguendo il principio shift-left: individuare i problemi il prima possibile, quando il costo per risolverli è minore.
La OWASP DevSecOps guideline specifica questa pipeline ordinata:
- Scansione dei repository git per perdita di credenziali
- SAST (analisi statica del codice sorgente)
- SCA (scansione delle dipendenze open-source)
- IAST (test basati su agente durante QA)
- DAST (test black-box di applicazioni in esecuzione)
- Scansione Infrastructure-as-Code per configurazioni errate
- Scansione dell'infrastruttura
- Verifiche di conformità
Nella pratica, la pipeline CI/CD esegue SAST e SCA a ogni build. Quando uno sviluppatore effettua un commit, la toolchain segnala librerie di terze parti vulnerabili e difetti di codice prima che la build sia completata. Gli agenti IAST si attivano durante i test funzionali, rilevando vulnerabilità con contesto di runtime. Gli scanner DAST analizzano l'ambiente di staging prima del rilascio.
Una volta distribuite, RASP e WAF forniscono difesa in runtime. I livelli di protezione endpoint e workload cloud aggiungono monitoraggio comportamentale che gli strumenti di test AppSec non possono offrire, coprendo zero-day, configurazioni errate e minacce che emergono solo in produzione.
La sfida è che questa pipeline genera grandi dataset di vulnerabilità. I risultati di SAST, DAST e SCA contengono falsi positivi e duplicati. Gli strumenti AppSec tradizionali individuano vulnerabilità singole ma non comprendono l'architettura software né danno priorità in base al rischio aziendale, come documentato dalla Cloud Security Alliance. Questo gap sta guidando l'adozione di Application Security Posture Management (ASPM) per consolidare i risultati frammentati in una vista unica di gestione del rischio.
Quando questa pipeline funziona efficacemente, la toolchain gestisce classi di vulnerabilità note su larga scala. Ma la sola scansione è solo una dimensione di un programma di test maturo.
Metodi di test della sicurezza delle applicazioni
Un programma di test completo va oltre gli strumenti di scansione per valutare la logica applicativa, i flussi di lavoro aziendali e i percorsi di attacco che i controlli predefiniti non rilevano.
I metodi più efficaci includono:
- Penetration testing simula attacchi reali da parte di tester esperti che concatenano vulnerabilità, testano la logica di business e tentano escalation di privilegi tra i confini applicativi. La OWASP Testing Guide fornisce una metodologia strutturata che copre gestione delle identità, autenticazione, autorizzazione, gestione delle sessioni, validazione degli input e test della logica di business. Le organizzazioni eseguono tipicamente penetration test trimestralmente o dopo rilasci significativi.
- Threat modeling identifica i rischi di sicurezza nella fase di progettazione, prima che venga scritto il codice. Framework come STRIDE e PASTA aiutano i team di sviluppo a mappare i flussi di dati, identificare i confini di fiducia e dare priorità ai rischi architetturali. NIST SP 800-218 (SSDF) include il threat modeling come pratica fondamentale nel gruppo "Produce Well-Secured Software".
- Fuzz testing invia dati malformati o casuali agli input applicativi per provocare crash, memory leak ed eccezioni non gestite. I fuzzer operano a livello di protocollo, formato file o API ed espongono vulnerabilità edge-case che i test strutturati trascurano.
- API security testing prende di mira le interfacce che collegano i componenti applicativi, i microservizi e le integrazioni di terze parti. La OWASP API Security Top 10 definisce i rischi API più critici, tra cui autorizzazione a livello di oggetto compromessa, autenticazione compromessa e consumo illimitato di risorse.
- Manual code review integra SAST applicando il giudizio umano a logiche complesse, implementazioni crittografiche e modelli di autorizzazione dove gli scanner producono falsi negativi. Questo metodo è più efficace se focalizzato sui percorsi di codice ad alto rischio identificati tramite threat modeling.
Combinati con gli strumenti di scansione descritti nelle sezioni precedenti, questi metodi forniscono la profondità di copertura che genera benefici misurabili per il programma.
Vantaggi chiave della sicurezza delle applicazioni
Un programma AppSec maturo offre ritorni misurabili su postura di sicurezza, prontezza alla conformità e riduzione del rischio.
Postura di sicurezza misurabile lungo tutto il SDLC. Il framework SAMM offre un modo efficace e misurabile per le organizzazioni di analizzare e migliorare la postura di sicurezza software su cinque funzioni aziendali: Governance, Design, Implementation, Verification e Operations. Dell utilizza OWASP SAMM per concentrare le risorse e determinare quali componenti del programma di sviluppo sicuro prioritizzare.
Comunicazione strutturata verso il management. SAMM aiuta a far risuonare la strategia di sicurezza a livello dirigenziale e favorisce l'adozione dello shift-left. Per i CISO che devono giustificare i budget, framework come BSIMM offrono benchmarking tra pari che rafforza la fiducia con stakeholder interni, clienti e regolatori.
Prontezza alla conformità normativa. OWASP SAMM si mappa direttamente ai requisiti normativi tra cui l'EU Cyber Resilience Act (CRA). Le attività SAMM sono allineate ai requisiti essenziali di sicurezza dell'Allegato I del CRA, tra cui valutazione del rischio, threat modeling, gestione SBOM e incident response.
Riduzione del debito di vulnerabilità tramite pratiche standardizzate. Il NIST Secure Software Development Framework (SSDF) definisce quattro gruppi di pratiche:
- Preparare l'organizzazione
- Proteggere il software
- Produrre software ben protetto
- Rispondere alle vulnerabilità
Seguire queste pratiche riduce sistematicamente l'accumulo di debito di sicurezza che le organizzazioni portano in produzione.
Riduzione del rischio quantificabile per la reportistica al board. Le violazioni dei dati costano alle organizzazioni milioni di dollari in media, e lo sfruttamento delle vulnerabilità continua a crescere come vettore di accesso iniziale. Un programma AppSec maturo riduce direttamente l'esposizione a questa crescente categoria di violazione.
Questi benefici sono reali, ma per realizzarli è necessario superare significative barriere operative e organizzative.
Sfide della sicurezza delle applicazioni
Costruire un programma AppSec efficace significa affrontare barriere organizzative, tecniche e di risorse che possono bloccare i progressi in qualsiasi fase.
- Attriti culturali DevSecOps. Scalare l'AppSec su architetture software eterogenee, più linguaggi e cicli di sviluppo diversi rimane la principale sfida operativa. I team che vedono la sicurezza come un ostacolo anziché come funzione integrata nella delivery incontrano resistenza all'adozione.
- Proliferazione di strumenti e visibilità frammentata. Molteplici strumenti di scansione con dashboard separati e tassonomie di vulnerabilità diverse costringono il team ad aggregare e deduplicare manualmente i risultati. Gli strumenti SAST, DAST e SCA tradizionali individuano difetti singoli ma non possono prioritizzarli in base al rischio aziendale o al contesto architetturale.
- Il gap pre-deployment/runtime. I test shift-left rilevano vulnerabilità a livello di codice prima della distribuzione. Ma gli ambienti di produzione restano esposti a minacce in runtime, zero-day, configurazioni errate e compromissioni della supply chain che gli strumenti pre-deployment non possono prevenire. Il Verizon 2025 DBIR mostra che molte vulnerabilità dei dispositivi edge sfruttate sono rimaste non patchate durante il periodo di osservazione. Programmi che si affidano esclusivamente alla scansione pre-deployment lasciano la produzione cieca; NIST 800-53 impone sia controlli IAST (SA-11(9)) sia RASP (SI-7(17)) proprio perché test e protezione in runtime hanno funzioni diverse.
- Carenza di competenze come vincolo principale. Il SANS Institute identifica le persone qualificate come prerequisito fondamentale per operazioni di sicurezza efficaci. La tecnologia moltiplica la capacità umana, ma non la sostituisce. Senza personale di sicurezza esperto, le organizzazioni faticano a operativizzare gli strumenti AppSec e a rispondere ai risultati con la rapidità richiesta.
Affrontare queste sfide richiede pratiche deliberate ancorate a governance, automazione e copertura in runtime.
Best practice per la sicurezza delle applicazioni
Le seguenti pratiche affrontano direttamente queste barriere, dall'allineamento organizzativo fino alla difesa a livello di produzione.
Ancora il programma prima nella governance. La funzione Governance di SAMM, che copre Strategia & Metriche, Policy & Compliance ed Education & Guidance, è la base strutturale. Fornisce una comprensione comune della postura di sicurezza, delle minacce esistenti e della tolleranza al rischio della leadership. I materiali per i practitioner OWASP SAMM sottolineano che l'AppSec richiede stakeholder in governance, design e operations, non solo nei team di sviluppo. Prima di selezionare un framework, risolvi queste domande di allineamento:
- L'organizzazione concorda sull'approccio?
- Il framework necessita di personalizzazione per il tuo ambiente?
- Il budget è disponibile e pianificato?
Saltare questa fase causa bassa adozione e investimenti sprecati.
Implementa Security Champion e definisci i ruoli. Il modello Security Champion responsabilizza i team di sviluppo nella gestione della sicurezza, affrontando il collo di bottiglia che si crea quando i modelli di sicurezza tradizionali generano attrito in ambienti dinamici, come documentato da OWASP Cincinnati. NIST SSDF richiede alle organizzazioni di creare nuovi ruoli e modificare le responsabilità esistenti per coprire tutte le parti del framework. Senza una definizione esplicita dei ruoli, la sicurezza diventa un'aggiunta tardiva.
Automatizza la scansione delle vulnerabilità di terze parti. NIST SP 800-218 specifica l'integrazione della scansione autonoma delle vulnerabilità nella toolchain per i componenti software e richiede alle organizzazioni di verificare che i componenti commerciali e open-source acquisiti siano conformi ai requisiti durante tutto il loro ciclo di vita. Le revisioni manuali delle dipendenze open-source non sono sostenibili, rendendo la revisione di terze parti una responsabilità centrale del programma.
Standardizza la verifica con OWASP ASVS. La OWASP ASVS fornisce una base per testare i controlli tecnici di sicurezza delle applicazioni web, creando una baseline comune in tutte le fasi del SDLC.
Applica la prioritizzazione basata sul rischio. Il NIST SSDF specifica che costo, fattibilità e applicabilità devono essere considerati nella scelta delle pratiche da implementare e nella quantità di tempo e risorse da dedicare. Le linee guida SAMM + CRA rafforzano questo concetto con una formula pratica: Priorità = Criticità del rischio CRA × Gap di maturità SAMM. Senza questo filtro, i programmi si bloccano prima di produrre risultati. Non tutte le pratiche si applicano allo stesso modo a ogni organizzazione.
Estendi la protezione al runtime. Il programma AppSec è incompleto senza difesa in runtime. Abbina i test shift-left a RASP, protezione dei workload cloud e monitoraggio comportamentale degli endpoint per coprire le minacce in produzione che la scansione pre-deployment non può raggiungere.
Queste pratiche posizionano il programma per affrontare i trend che stanno ridefinendo la sicurezza delle applicazioni fino al 2026.
Tendenze della sicurezza delle applicazioni: 2025 e 2026
Diversi sviluppi stanno ridefinendo l'approccio delle organizzazioni alla sicurezza delle applicazioni, dagli attacchi guidati dall'AI alla consolidazione delle piattaforme.
- L'AI sta espandendo la superficie di attacco. I threat actor stanno prendendo di mira vulnerabilità introdotte dall'integrazione dell'AI nelle applicazioni enterprise. OWASP ha pubblicato la Securing Agentic Applications Guide v1.0 nel 2025, fornendo raccomandazioni di sicurezza per gli sviluppatori di agenti AI. Il National Cyber Security Centre del Regno Unito ha avvertito che gli attacchi prompt injection contro applicazioni AI generative potrebbero non essere mai completamente fermati, invitando le organizzazioni a concentrarsi sulla riduzione del rischio e sulla limitazione dell'impatto.
- La consolidazione delle piattaforme sta guadagnando slancio. Il Research Compass Cybersecurity 2026 di KuppingerCole prevede che XDR e CNAPP sostituiranno EDR e SIEM tools offrendo fonti dati unificate per risposte autonome. La protezione in runtime sta emergendo come elemento differenziante chiave dei CNAPP, poiché le organizzazioni richiedono monitoraggio comportamentale insieme alla scansione della postura.
- Il confine AppSec/runtime si sta restringendo. La separazione tradizionale tra test di sicurezza in fase di sviluppo e protezione in produzione si sta dissolvendo. Le organizzazioni stanno collegando l'esposizione tecnica all'impatto aziendale tramite workflow unificati che integrano risultati AppSec, telemetria di runtime e risposta SOC in un unico modello di prioritizzazione.
Questa convergenza è esattamente il punto in cui un approccio di piattaforma offre il massimo valore.
Cybersicurezza alimentata dall'intelligenza artificiale
Elevate la vostra posizione di sicurezza con il rilevamento in tempo reale, la risposta automatica e la visibilità totale dell'intero ambiente digitale.
Richiedi una demoPunti chiave
La sicurezza delle applicazioni protegge il software dal codice fino alla produzione utilizzando SAST, DAST, SCA, IAST, RASP e WAF in ogni fase del SDLC. Con l'aumento dello sfruttamento delle vulnerabilità e delle violazioni della supply chain, il solo testing pre-deployment non è sufficiente.
La protezione in runtime colma il gap critico tra la scansione della pipeline e la difesa in produzione. Costruisci il programma su OWASP SAMM e NIST SSDF, automatizza la scansione delle vulnerabilità di terze parti ed estendi il monitoraggio comportamentale ai workload in produzione.
Domande frequenti
La sicurezza delle applicazioni (AppSec) è la pratica di individuare, correggere e prevenire vulnerabilità nel software durante tutto il ciclo di vita dello sviluppo. Copre il codice sorgente, le API, le librerie di terze parti, le configurazioni di sistema e l'infrastruttura su cui vengono eseguite le applicazioni.
I programmi AppSec utilizzano una combinazione di strumenti di test (SAST, DAST, SCA, IAST) e difese in fase di esecuzione (RASP, WAF) per proteggere le applicazioni dal codice fino alla produzione.
SAST analizza il codice sorgente senza eseguire l'applicazione (test white-box), individuando vulnerabilità come SQL injection e XSS durante lo sviluppo. DAST testa un'applicazione in esecuzione dall'esterno (test black-box), rilevando problemi in fase di esecuzione come errori di autenticazione e configurazioni errate del server.
SAST ti indirizza alla riga di codice esatta. DAST mostra ciò che vede un attaccante. Nessuno dei due sostituisce l'altro; entrambi sono necessari per una copertura completa.
La sicurezza delle applicazioni protegge il livello software: logica del codice, API, elaborazione dei dati e componenti di terze parti. La sicurezza di rete protegge il livello infrastrutturale: dati in transito, perimetri e segmenti di rete tramite firewall, VPN e IDS/IPS.
Un WAF collega entrambe le discipline filtrando il traffico HTTP al perimetro di rete per proteggere le applicazioni web. La maggior parte delle organizzazioni necessita di entrambe le soluzioni che lavorano insieme, poiché un firewall non può bloccare una vulnerabilità di SQL injection nel codice.
L'OWASP Top 10:2025 elenca i fallimenti della supply chain del software tra i principali rischi. CISA ha emesso un avviso formale a settembre 2025 riguardo al worm npm Shai-Hulud, il primo attacco alla supply chain auto-propagante di successo di questo tipo.
Poiché la maggior parte delle applicazioni moderne si basa fortemente su componenti open-source, SCA offre visibilità continua sulle CVE note e sui rischi di conformità delle licenze in tutto il tuo albero delle dipendenze.
La protezione in fase di esecuzione (RASP, CWPP, monitoraggio degli endpoint) difende le applicazioni dopo il deployment, dove gli strumenti pre-deployment come SAST, DAST e SCA non hanno visibilità. NIST 800-53 SI-7(17) richiede controlli di auto-protezione delle applicazioni in fase di esecuzione perché gli ambienti di produzione affrontano zero-day, configurazioni errate e compromissioni della supply chain che i test da soli non possono prevenire.
La difesa in fase di esecuzione integra i test shift-left coprendo le minacce che emergono solo quando le applicazioni sono operative.
OWASP SAMM fornisce una valutazione strutturata su cinque funzioni aziendali: Governance, Design, Implementazione, Verifica e Operazioni. BSIMM offre un benchmarking tra pari rispetto ad altre organizzazioni.
L'approccio più efficace combina la roadmap prescrittiva di SAMM con i benchmark descrittivi di BSIMM, utilizzando OWASP ASVS come baseline standardizzata di verifica. Insieme, questi framework offrono un modo ripetibile per monitorare i progressi e identificare le lacune nel tempo.
Gli strumenti principali includono SAST (analisi statica del codice sorgente), DAST (test black-box di applicazioni in esecuzione), SCA (scansione delle dipendenze open-source), IAST (test basati su agenti durante la QA), RASP (blocco degli exploit in fase di runtime) e WAF (filtraggio del traffico HTTP al perimetro di rete).
Oltre agli strumenti di scansione, i team applicano penetration testing, threat modeling, fuzz testing e revisione manuale del codice per coprire difetti di logica di business e casi limite che gli scanner non rilevano. La maggior parte dei programmi maturi stratifica questi strumenti lungo tutto il SDLC, dall’analisi statica al momento del commit fino alla difesa in runtime in produzione.
