Ogni organizzazione sa di avere a che fare con l'IT ombra. Il dato che rende concreto il problema è il seguente: la maggior parte delle organizzazioni utilizza oltre 1,000 applicazioni cloud e l'IT in genere ha visibilità su meno del 10% di esse. Le grandi aziende utilizzano in media 473 applicazioni SaaS; l'IT ne gestisce direttamente solo una piccola parte. L'80% dei dipendenti utilizza applicazioni non autorizzate per svolgere il proprio lavoro. I dati sono coerenti in tutti gli studi perché la dinamica che riflettono è la stessa: dipendenti e unità aziendali adottano strumenti che risolvono problemi immediati più velocemente di quanto i processi di governance IT possano valutarli e approvarli.
Il dibattito del 2026 sull'IT ombra è dominato dagli strumenti di rilevamento SaaS che scansionano i log DNS, analizzano i token SSO OAuth, verificano le note spese e tracciano il traffico di rete per individuare le applicazioni cloud utilizzate dai dipendenti senza autorizzazione. Questi strumenti risolvono il problema a livello SaaS, e lo fanno in modo abbastanza efficace. Ciò che non risolvono, e che nessuno strumento di rilevamento SaaS affronta, è l'altro problema dell'IT ombra: le applicazioni personalizzate, i programmi batch non documentati, le pipeline di dati informali e i programmi di utilità fantasma che esistono nei portfolio di applicazioni aziendali e non sono mai apparsi in alcun sistema di gestione degli asset, registro delle modifiche o inventario IT. Non si tratta di applicazioni cloud implementate dai dipendenti. Si tratta di programmi di produzione, in esecuzione su mainframe e sistemi di fascia media, che svolgono funzioni critiche per il business di cui le organizzazioni proprietarie non sono in grado di fornire un resoconto completo.
I due problemi richiedono approcci di individuazione differenti. Il problema dell'IT ombra nel SaaS richiede visibilità di rete e integrazione delle identità. Il problema dell'IT ombra a livello di codice richiede l'analisi degli artefatti software effettivi, del codice sorgente, delle librerie di caricamento e dei flussi di job JCL, per enumerare quali programmi esistono e cosa fanno. Questa guida tratta entrambi gli aspetti, con particolare attenzione alla seconda categoria, che non è stata ancora affrontata in altri ambiti.
I due problemi dell'IT ombra
L'IT ombra viene generalmente definito come la tecnologia utilizzata all'interno di un'organizzazione senza l'esplicita approvazione o conoscenza del reparto IT. Tale definizione comprende due fenomeni fondamentalmente diversi che richiedono approcci di individuazione e risposte di governance differenti.
Gli strumenti SaaS e cloud "ombra" sono applicazioni e servizi adottati da dipendenti o unità aziendali senza un'autorizzazione formale da parte del reparto IT. Ad esempio, un team di marketing che utilizza uno strumento di scrittura basato sull'intelligenza artificiale non approvato, un team finanziario che condivide fogli di calcolo tramite un account Dropbox personale o uno sviluppatore che utilizza un assistente di programmazione basato sull'IA non autorizzato, il quale invia codice sorgente proprietario a un'API esterna. Queste applicazioni esistono al di fuori dell'infrastruttura aziendale e sono rilevabili tramite segnali esterni: query DNS, autorizzazioni OAuth, voci di note spese, impronte digitali del traffico di rete.
Il software applicativo ombra , la categoria su cui si concentra specificamente questo articolo, è costituito da programmi e processi batch personalizzati creati all'interno dell'infrastruttura aziendale e mai adeguatamente documentati, inventariati o gestiti. Un esempio: un programma COBOL scritto da uno sviluppatore del reparto finanziario nel 1994 per gestire un caso limite specifico di calcolo delle imposte; un programma RPG creato da un analista aziendale per generare file EDI per uno specifico partner commerciale; un job JCL eseguito a fine mese che produce un report normativo su cui fa affidamento il team di conformità, realizzato da un collaboratore esterno che ha lasciato l'organizzazione nel 2009; un'utility Java scritta "temporaneamente" durante un progetto di integrazione di sistemi nel 2018, diventata una dipendenza permanente senza che nessuno lo avesse autorizzato.
Questi programmi non sono visibili nei log DNS perché vengono eseguiti su infrastrutture interne. Non compaiono nei record di autorizzazione OAuth perché sono precedenti a OAuth. Non sono presenti nell'inventario ufficiale delle applicazioni perché non sono mai stati formalmente sottoposti a revisione da parte della governance IT. Possono essere individuati solo esaminando l'infrastruttura stessa, le librerie di caricamento, i repository del codice sorgente, gli scheduler dei processi e i log di esecuzione che rivelano quale software è effettivamente in esecuzione nell'ambiente.
Il motivo per cui questo è importante, al di là della completezza dell'inventario, è che il 74% delle organizzazioni ha subito incidenti di sicurezza a causa di risorse sconosciute o non gestite. Il software applicativo ombra rappresenta la categoria di risorse sconosciute che né gli strumenti di rilevamento basati sulla rete né le piattaforme di visibilità SaaS sono in grado di individuare.
Perché si accumula il software applicativo ombra
Comprendere perché le applicazioni personalizzate non documentate proliferano negli ambienti aziendali spiega perché i processi di governance standard non riescono a prevenirle e perché è necessaria un'analisi retrospettiva.
L'imperativo di una soluzione immediata. Le unità aziendali si trovano ad affrontare problemi operativi specifici che richiedono soluzioni specifiche. L'applicazione approvata non gestisce i casi limite. La coda delle richieste IT è satura. Uno sviluppatore, a volte in ambito IT, a volte integrato in un team aziendale, scrive una soluzione funzionante. La soluzione viene eseguita, risolve il problema e diventa parte del flusso di lavoro operativo. Il processo di governance formale non viene mai avviato perché il problema è già stato risolto.
Il modello del temporaneo che diventa permanente. La forma più insidiosa di software applicativo ombra inizia come una soluzione esplicitamente temporanea. "Solo finché il sistema reale non sarà pronto." "Una soluzione rapida per il problema del formato dei dati." "Temporaneo mentre aspettiamo che il fornitore sistemi la sua API." Le soluzioni temporanee diventano permanenti quando le dipendenze che si accumulano attorno ad esse non vengono mai eliminate. La correzione del calcolo della data in COBOL scritta per risolvere il problema del Millennium Bug (Y2K) che viene ancora utilizzata venticinque anni dopo perché nessuno sviluppatore successivo sapeva perché esistesse o se fosse sicuro rimuoverla. Lo script "temporaneo" di normalizzazione del database che è diventato parte del batch notturno perché l'applicazione di destinazione non è mai stata effettivamente realizzata.
Il fallimento del trasferimento di conoscenze. Le applicazioni "ombra", create da singoli individui, escono dalla documentazione aziendale quando questi lasciano l'organizzazione. Il programma continua a funzionare, è integrato nei processi di produzione che dipendono da esso, ma non esiste alcuna documentazione, non è stata assegnata alcuna responsabilità e nessuno ne conosce il funzionamento in modo sufficientemente dettagliato da poterlo modificare in sicurezza. Diventa un fantasma nell'ambiente di produzione: visibile nei suoi effetti, invisibile nella sua gestione.
La pipeline di dati ombra. L'integrazione dei dati è un terreno particolarmente fertile per i software personalizzati non documentati. Quando il livello ETL ufficiale non supporta una trasformazione necessaria, o quando un processo aziendale richiede che i dati si spostino tra i sistemi più velocemente di quanto consentito dal processo di integrazione ufficiale, gli sviluppatori creano programmi non ufficiali per il trasferimento dei dati. Uno script Python che interroga il database di produzione e scrive i risultati su un'unità condivisa che viene poi utilizzata da un processo a valle. Un programma COBOL che legge dal DB2 del mainframe e scrive su un file di testo che viene poi acquisito da un'applicazione cloud. Queste pipeline di dati non ufficiali attraversano i confini dei sistemi, gestiscono dati potenzialmente sensibili e operano completamente al di fuori del framework di governance dell'integrazione.
Le quattro categorie di software applicativo ombra
Categoria 1: Applicazioni personalizzate per unità aziendali
Programmi creati da sviluppatori integrati nelle unità aziendali, quali finanza, approvvigionamento, operazioni e conformità, che risolvono problemi specifici del settore. Questi programmi in genere:
- Vengono denominati in modo informale (TAXCALC, VENDREPT, ADJBATCH) senza seguire le convenzioni di denominazione aziendali.
- Risiedono in directory o librerie gestite dall'unità aziendale anziché dall'IT
- Non è presente alcuna voce nel database di gestione della configurazione (CMDB)
- Non è stato assegnato alcun responsabile tecnico nel sistema di gestione dei servizi IT.
- Mancanza di documentazione formale, copertura dei test e cronologia del controllo delle modifiche.
La loro importanza critica viene spesso sottovalutata perché l'unità aziendale sa cosa fa il programma e lo considera "proprio". L'organizzazione IT, che non sa dell'esistenza del programma, non può valutarne la criticità. L'assenza del programma dall'inventario delle applicazioni IT implica la sua esclusione dai piani di continuità operativa (BCP), dalla pianificazione del ripristino di emergenza, dalle valutazioni di sicurezza e dall'ambito del programma di modernizzazione.
Categoria 2: Programmi fantasma
Programmi che compaiono nell'esecuzione di produzione ma la cui origine, scopo e responsabilità sono sconosciute all'organizzazione attuale. Esistono nelle librerie di caricamento e nei repository di codice sorgente, vengono richiamati da altri programmi o invocati da job JCL, producono output da cui dipendono i processi a valle, ma la memoria organizzativa del perché esistono e di chi ne è responsabile è andata perduta.
I programmi fantasma sono particolarmente pericolosi dal punto di vista della sicurezza e della conformità perché non possono essere verificati rispetto agli standard attuali, non possono essere inclusi nei programmi di scansione delle vulnerabilità che richiedono l'assegnazione della proprietà dell'applicazione e non possono essere valutati in termini di conformità normativa perché nessuno sa a quali dati accedono o quale funzione aziendale svolgano.
Categoria 3: Pipeline di dati ombra
Programmi non ufficiali che trasferiscono dati tra sistemi al di fuori dell'architettura di integrazione approvata. Questi programmi spaziano da sofisticate alternative ETL a semplici script di trasferimento file:
python
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")Questo programma, rappresentativo di uno schema riscontrato in molti ambienti aziendali, utilizza credenziali di accesso al database di produzione codificate direttamente nel codice sorgente, scrive dati di fatturazione sensibili in una posizione di rete condivisa senza crittografia ed è in esecuzione senza monitoraggio da anni dopo che il suo autore ha lasciato l'organizzazione. Non verrebbe rilevato da alcuno strumento di rilevamento SaaS perché viene eseguito su un'infrastruttura interna. Non verrebbe rilevato da un'analisi del traffico di rete perché utilizza protocolli di database standard che non producono una firma univoca. È visibile solo nel codice sorgente stesso.
Categoria 4: Lavori in batch non documentati
Flussi di job JCL e programmi pianificati che vengono eseguiti sull'infrastruttura di produzione ma non sono presenti nella documentazione ufficiale della pianificazione dei job. Questi si accumulano attraverso:
- Lavori inviati al di fuori del sistema di pianificazione standard tramite invio diretto
- Programmi richiamati dinamicamente dall'interno di altri programmi (e quindi non visibili indipendentemente negli inventari dello scheduler)
- Lavori che vengono eseguiti raramente, a fine mese, a fine anno o solo in presenza di specifiche condizioni aziendali, e che non sono mai stati inclusi nei controlli di inventario di routine.
- Posti di lavoro ereditati da sistemi precedenti che sono stati "migrati" ma mai formalmente dismessi.
I processi batch non documentati diventano punti critici di errore quando:
- Una finestra di manutenzione ha un impatto sul sistema su cui operano e nessuno sa di dover avvisare l'unità aziendale che dipende dal loro output.
- Viene eseguita una valutazione della sicurezza e questi processi vengono eseguiti come account di servizio non monitorati con privilegi elevati
- Un programma di modernizzazione pianifica la migrazione in base alla pianificazione documentata e arriva nell'ambiente di destinazione privo di elaborazione batch critica
Metodi di rilevamento per categoria di software ombra
I metodi di rilevamento appropriati per l'IT ombra SaaS sono in gran parte inapplicabili al software applicativo ombra. I metodi richiesti sono:
Analisi della libreria di caricamento. Ogni programma che sia mai stato compilato e distribuito su un mainframe o un sistema midrange esiste in una libreria di caricamento, ovvero il repository degli eseguibili. Il confronto tra i programmi presenti nella libreria di caricamento e quelli nell'inventario ufficiale delle applicazioni rivela una discrepanza: ogni modulo di caricamento presente nella libreria ma non nell'inventario è un programma "ombra". Questa analisi non richiede il codice sorgente, ma opera sugli eseguibili compilati e sui relativi metadati.
Analisi del repository del codice sorgente. I repository del codice sorgente (PDS di codice sorgente COBOL, repository Git, librerie di codice sorgente RPG) contengono ogni programma mai scritto, inclusi quelli scritti in modo informale, distribuiti in modo informale e mai registrati nei sistemi di governance IT. L'analisi dell'intero repository del codice sorgente rispetto al CMDB rivela i programmi presenti nel codice sorgente ma privi di una registrazione nei sistemi di governance.
Riconciliazione tra JCL e scheduler. Ogni flusso di job JCL eseguito in produzione, sia che venga inviato tramite lo scheduler ufficiale, inviato manualmente o richiamato da un altro job, lascia una traccia nel log di esecuzione dei job (JESLOG, SYSLOG). Il confronto tra i programmi presenti nei log di esecuzione di produzione e i programmi nell'inventario ufficiale consente di identificare i programmi eseguiti in produzione senza copertura di governance.
Analisi dinamica delle chiamate. I programmi che chiamano dinamicamente altri programmi, dove il nome del programma chiamato viene determinato in fase di esecuzione anziché in fase di compilazione, creano dipendenze che risultano invisibili all'analisi statica dello scheduler. L'analisi dinamica delle chiamate traccia quali programmi emettono istruzioni CALL con nomi di programma variabili, identifica l'intervallo di programmi che potrebbero essere chiamati e segnala i programmi raggiungibili tramite dispatch dinamico che potrebbero non comparire in alcuna mappa statica delle dipendenze.
Tracciamento del flusso di dati. Le pipeline di dati "ombra" possono essere individuate attraverso l'analisi dei modelli di accesso al file system e al database: quali programmi leggono o scrivono su quali dataset, file o tabelle di database. Un programma che legge da un database di produzione e scrive su un percorso di file al di fuori della gerarchia standard di gestione dei dati è un potenziale candidato per una pipeline "ombra".
La dimensione dell'IA ombra
La nuova frontiera del problema dell'IT ombra, che si protrae fino al 2026, è rappresentata dall'intelligenza artificiale ombra (shadow AI), ovvero l'utilizzo di strumenti e agenti di IA da parte di dipendenti e unità aziendali senza l'autorizzazione del reparto IT. Secondo il report "Cost of a Data Breach" di IBM del 2026, il 43% degli incidenti di sicurezza coinvolge dipendenti che utilizzano l'IA ombra. Gartner prevede che entro il 2030, oltre il 40% delle aziende subirà un incidente di sicurezza o di conformità legato all'utilizzo non autorizzato dell'IA ombra.
Il rischio specifico introdotto dall'IA ombra, direttamente rilevante per l'IT ombra a livello di codice, è rappresentato dal codice sorgente proprietario utilizzato dagli assistenti di programmazione basati sull'IA. Un dipendente che utilizza un assistente di programmazione basato sull'IA non autorizzato per gestire un programma COBOL legacy ha inviato il codice sorgente di tale programma a un fornitore esterno di IA. Il codice sorgente potrebbe contenere credenziali hardcoded, logica aziendale che costituisce segreto commerciale o strutture dati la cui esposizione viola i requisiti di residenza dei dati. Il metodo di individuazione di questo rischio specifico non consiste nell'analisi del traffico di rete, bensì nel rilevare quali programmi sono stati consultati da strumenti che comunicano con API di IA esterne, il che richiede un monitoraggio a livello di applicazione anziché a livello di rete.
Il problema dell'IA ombra e quello del software applicativo ombra condividono una caratteristica importante: entrambi sono invisibili agli strumenti di rilevamento basati sulla rete che dominano il mercato dell'IT ombra SaaS. Entrambi richiedono il monitoraggio a livello applicativo o l'analisi strutturale del codice per essere individuati.
Creazione dell'inventario completo delle applicazioni
Il risultato di un programma di rilevamento dell'IT ombra per il software applicativo aziendale è un inventario riconciliato che copre quattro popolazioni:
Conosciuti e documentati: Programmi presenti sia nell'inventario ufficiale che nell'ambiente di produzione effettivo. Questi programmi dispongono di una struttura di governance, responsabili assegnati, cronologia delle modifiche e piani di ripristino d'emergenza.
Noti ma non distribuiti: programmi che compaiono nell'inventario ufficiale ma non si trovano nelle librerie di caricamento o nei log di esecuzione in produzione. Questi programmi potrebbero essere destinati alla dismissione, potrebbero essere stati disattivati senza una corretta procedura formale di ritiro oppure potrebbero essere elencati in modo errato.
Programmi sconosciuti ma distribuiti (programmi shadow): programmi che compaiono nei log di esecuzione in produzione o nelle librerie di caricamento, ma non sono presenti nell'inventario ufficiale. Si tratta del principale problema di IT shadow, programmi che richiedono l'immediata assegnazione della responsabilità, una valutazione della sicurezza e la registrazione nella governance.
Dipendenze non documentate: programmi che non compaiono né nell'inventario ufficiale né nei log di esecuzione principali della produzione, ma che vengono scoperti tramite analisi dinamica delle chiamate (CALL) o tracciamento del flusso di dati come raggiungibili dai processi di produzione. Questi sono i programmi fantasma, i più difficili da trovare e i più pericolosi da non individuare.
La riconciliazione tra queste quattro popolazioni produce il piano d'azione: registrare i programmi ombra, valutarne la sicurezza, assegnarne la proprietà e determinarne la destinazione, gestirli e mantenerli, modernizzarli o dismetterli.
Come SMART TS XL Esegue la scoperta di infrastrutture IT nascoste a livello di codice.
SMART TS XLL'approccio di alla scoperta dell'IT ombra affronta le categorie a livello di codice che gli strumenti basati sulla rete non possono raggiungere.
La funzionalità di analisi statica del codice inizia con una scansione completa del repository del codice sorgente: ogni programma COBOL, modulo RPG, applicazione PL/I, servizio Java, script Python e flusso di job JCL presente nell'ambiente viene catalogato con la relativa posizione, linguaggio, dimensione e profilo di complessità preliminare. Questo inventario costituisce la base di riferimento rispetto alla quale vengono confrontati il CMDB e il registro ufficiale delle applicazioni; i programmi che compaiono nel repository del codice sorgente ma non nell'inventario ufficiale rappresentano la principale fonte di individuazione di applicazioni "ombra".
La mappatura delle dipendenze dell'applicazione risolve il problema delle chiamate dinamiche: tracciando ogni istruzione CALL in ogni programma, incluse le chiamate dinamiche in cui il nome del programma è una variabile, la mappa delle dipendenze identifica i programmi raggiungibili dai processi di produzione anche quando non compaiono mai negli inventari statici dello scheduler. Un programma fantasma che viene chiamato dinamicamente da dieci programmi di produzione appare nella mappa delle dipendenze anche se non ha una definizione di job JCL indipendente.
La funzionalità di espansione JCL traccia l'intera catena di esecuzione di ogni flusso di job JCL: risolve i riferimenti PROC, espande i parametri simbolici e crea la mappa completa dei programmi invocati da ciascun job. Quando questa mappa viene confrontata con la documentazione ufficiale della pianificazione dei job, i job e i programmi che vengono eseguiti in produzione senza essere coperti dalla documentazione vengono automaticamente individuati.
La capacità di analisi dell'impatto rende i risultati della scoperta fruibili: per ogni programma ombra scoperto, vengono elencati tutti i processi di produzione che dipendono da esso. Un programma ombra senza dipendenze è un potenziale codice morto, che può essere tranquillamente dismesso. Un programma ombra con venti dipendenze di produzione è una risorsa critica non documentata che richiede un'immediata attenzione da parte della governance. La portata dell'impatto è ciò che determina la priorità di bonifica.
La funzionalità di ricerca aziendale rende interrogabile l'intero inventario: è possibile trovare ogni programma che accede a uno specifico dataset (potenziali candidati per pipeline di dati shadow), ogni programma scritto dopo una data specifica che non ha una voce nel CMDB (applicazioni shadow recenti), ogni programma che scrive su percorsi di file esterni al di fuori della gerarchia standard di gestione dei dati. Questa funzionalità di ricerca supporta sia l'attività di individuazione iniziale sia il monitoraggio continuo che impedisce la ripresa dell'accumulo di applicazioni shadow dopo la pulizia iniziale.
Per le organizzazioni che conducono programmi di modernizzazione di sistemi legacy , l'individuazione delle applicazioni "ombra" è un passaggio imprescindibile. Un programma di modernizzazione che definisce l'ambito della migrazione basandosi sull'inventario ufficiale delle applicazioni e scopre i programmi "ombra" a metà dell'esecuzione è un programma di modernizzazione il cui ambito, tempistica e budget erano errati fin dal momento dell'impegno. L'individuazione che avrebbe dovuto avvenire prima della pianificazione si verifica ora durante l'esecuzione, quando il suo costo è massimo.
La risposta della governance: non bloccare, ma dare visibilità.
Le organizzazioni che gestiranno efficacemente l'IT ombra nel 2026 avranno imparato che il divieto generalizzato non funziona e crea incentivi perversi. La segnalazione dell'IT ombra fallisce nella maggior parte delle organizzazioni per un motivo: i dipendenti si aspettano una punizione. Quando un membro del team finanziario utilizza un sistema di tracciamento delle spese non autorizzato e lo segnala autonomamente, il team di sicurezza che reagisce con un rimprovero ha di fatto abituato quel dipendente, e chiunque con cui parli, a tacere la prossima volta.
Lo stesso principio si applica al software applicativo ombra. Uno sviluppatore che ha creato un'utility COBOL critica per l'azienda, da cui l'organizzazione dipende, non dovrebbe essere penalizzato per non aver seguito un processo di governance che potrebbe non essere stato comunicato chiaramente all'epoca. La risposta della governance alla scoperta di applicazioni ombra dovrebbe essere:
Registrazione, non rimozione. I programmi ombra scoperti nel percorso critico dei processi aziendali non sono programmi ombra da rimuovere, bensì applicazioni di produzione non documentate che richiedono una supervisione rigorosa. Registrateli, assegnate dei responsabili, valutatene il livello di sicurezza e trattateli con la stessa disciplina di governance riservata a qualsiasi altra applicazione di produzione.
Amnistia per l'autodenuncia. Un programma di governance che crea canali sicuri per le unità aziendali per divulgare le applicazioni informali che hanno sviluppato, fa emergere il software ombra più rapidamente di qualsiasi approccio di individuazione tecnica. La garanzia che la divulgazione porti a supporto della governance, assistenza nella documentazione, revisione della sicurezza e registrazione formale, anziché a provvedimenti disciplinari, elimina l'incentivo all'occultamento.
Prevenzione attraverso i processi. La causa principale dell'accumulo di applicazioni non autorizzate risiede nell'attrito della governance: il processo ufficiale per la richiesta di sviluppo di nuove applicazioni è più lento di quanto richiesto dalle esigenze aziendali. Riducendo tale attrito, una governance snella per lo sviluppo rapido, il supporto integrato della governance IT nelle unità aziendali e un'approvazione semplificata per gli strumenti interni a basso rischio, si riduce il tasso di creazione di nuove applicazioni non autorizzate senza la necessità di continue analisi tecniche.
L'inventario che pensi di avere non è l'inventario che hai
La differenza tra l'inventario delle applicazioni gestito dal reparto IT e il software effettivamente in esecuzione negli ambienti aziendali non è trascurabile. Nelle grandi organizzazioni con decenni di accumulo di applicazioni, il divario tra ciò che è documentato e ciò che è effettivamente in esecuzione può raggiungere il trenta percento del totale dei programmi. Questo trenta percento non documentato comprende programmi che elaborano dati sensibili, svolgono funzioni di conformità normativa, si trovano nel percorso critico dei processi aziendali e presentano vulnerabilità di sicurezza che nessuno ha mai esaminato perché nessuno sapeva di doverle esaminare.
Gli strumenti SaaS per la scoperta dello shadow IT affrontano efficacemente il livello cloud di questo problema. Il problema dello shadow IT a livello di codice, ovvero i programmi personalizzati, le utility fantasma, le pipeline di dati informali e i processi batch non documentati che popolano gli ambienti legacy aziendali, richiede un approccio diverso: un'analisi strutturale degli artefatti software effettivi anziché il monitoraggio del traffico di rete. L'inventario che emerge da tale analisi è spesso sorprendentemente completo. Le organizzazioni che svolgono questo lavoro scoprono costantemente che ciò che pensavano di avere in esecuzione in produzione e ciò che effettivamente è in esecuzione sono due cose significativamente diverse. Colmare questo divario è il fondamento di ogni programma di governance, sicurezza, BCP e modernizzazione che si basa sulla conoscenza di ciò che l'organizzazione effettivamente gestisce.
