Každá organizace ví, že má stínové IT. Číslo, které problém konkretizuje: většina organizací provozuje více než 1 000 cloudových aplikací a IT oddělení má obvykle přehled o méně než 10 procentech z nich. Velké podniky průměrně provozují 473 SaaS aplikací; IT přímo spravuje pouze zlomek. Osmdesát procent zaměstnanců používá k vykonávání své práce neschválené aplikace. Čísla jsou v každé studii konzistentní, protože dynamika, kterou odrážejí, je konzistentní: zaměstnanci a obchodní jednotky zavádějí nástroje, které řeší okamžité problémy rychleji, než je procesy správy IT dokážou vyhodnotit a schválit.
Diskusi o stínovém IT v roce 2026 dominují nástroje pro vyhledávání SaaS, které skenují protokoly DNS, analyzují tokeny SSO OAuth, auditují výkazy výdajů a síťový provoz otisků prstů, aby našly cloudové aplikace, které zaměstnanci používají bez autorizace. Tyto nástroje řeší vrstvu problému SaaS a řeší ji poměrně dobře. Co neřeší a co žádný nástroj pro vyhledávání SaaS neřeší, je další problém stínového IT: aplikace vytvořené na míru, nedokumentované dávkové programy, neformální datové kanály a fiktivní utility, které existují v portfoliích podnikových aplikací a nikdy se neobjevily v žádném systému správy aktiv, protokolu změn ani inventáři IT. Nejedná se o cloudové aplikace nasazené zaměstnanci. Jsou to produkční programy běžící na mainframech a systémech střední třídy, které vykonávají kritické obchodní funkce, za které organizace, které je vlastní, nemohou plně pokrývat.
Tyto dva problémy vyžadují odlišné přístupy k objevování. Problém stínového IT v SaaS vyžaduje viditelnost v síti a integraci identity. Problém stínového IT na úrovni kódu vyžaduje analýzu skutečných softwarových artefaktů, zdrojového kódu, načítacích knihoven a toků úloh JCL, aby se vyjmenovaly existující programy a jejich funkce. Tato příručka se zabývá oběma kategoriemi, se zvláštním zaměřením na druhou kategorii, kterou se zbytek oboru nezabýval.
Dva problémy stínového IT
Stínové IT je obvykle definováno jako technologie používaná v organizaci bez explicitního souhlasu nebo znalostí IT. Tato definice zahrnuje dva zásadně odlišné jevy, které vyžadují různé přístupy k objevování a různé reakce správy a řízení.
Stínové SaaS a cloudové nástroje jsou aplikace a služby, které si osvojují zaměstnanci nebo obchodní jednotky bez formálního zadávání IT požadavků. Marketingový tým používající neschválený nástroj pro psaní s umělou inteligencí. Finanční tým sdílející tabulky prostřednictvím osobního účtu Dropbox. Vývojář používající neautorizovaného asistenta pro kódování s umělou inteligencí, který odesílá proprietární zdrojový kód do externího API. Tyto aplikace existují mimo infrastrukturu organizace a jsou zjistitelné prostřednictvím externích signálů: dotazů DNS, autorizací OAuth, položek výkazů výdajů, otisků síťového provozu.
Stínový aplikační software , kategorie, na kterou se tento článek konkrétně zaměřuje, zahrnuje zakázkové programy a dávkové procesy, které byly vytvořeny v rámci vlastní infrastruktury organizace a nikdy nebyly řádně zdokumentovány, inventarizovány ani řízeny. Program v jazyce COBOL napsaný vývojářem ve finančním oddělení v roce 1994 pro zpracování specifického okrajového případu výpočtu daně. RPG program vytvořený obchodním analytikem pro generování souborů EDI pro konkrétního obchodního partnera. Úloha JCL, která se spouští každý měsíc a vytváří regulační zprávu, na které závisí tým pro dodržování předpisů, vytvořená dodavatelem, který organizaci opustil v roce 2009. Utilita Java napsaná „dočasně“ během projektu systémové integrace v roce 2018, která se stala trvalou závislostí, aniž by o tom někdo rozhodl.
Tyto programy nejsou viditelné v protokolech DNS, protože běží na interní infrastruktuře. Neobjevují se v autorizačních záznamech OAuth, protože jsou starší než OAuth. Nejsou v oficiálním inventáři aplikací, protože nikdy nebyly formálně odeslány ke kontrole IT governance. Jsou objevitelné pouze prozkoumáním samotné infrastruktury, knihoven pro načítání, úložišť zdrojového kódu, plánovačů úloh a protokolů provádění, které odhalují, jaký software v daném prostředí skutečně běží.
Důvod, proč je to důležité, přesahuje úplnost inventáře: 74 procent organizací zaznamenalo bezpečnostní incidenty způsobené neznámými nebo nespravovanými aktivy. Stínový aplikační software představuje kategorii neznámých aktiv, která nemohou najít ani síťové nástroje pro vyhledávání, ani platformy pro sledování SaaS.
Proč se hromadí software Shadow Application Software
Pochopení toho, proč se v podnikových prostředích šíří nedokumentované vlastní aplikace, vysvětluje, proč standardní procesy správy a řízení tomu nedokážou zabránit a proč je nutné retrospektivní zjišťování.
Imperativ okamžitého řešení. Obchodní jednotky čelí specifickým provozním problémům, které vyžadují specifická řešení. Schválená aplikace se nezabývá okrajovým případem. Fronta IT požadavků je omezena nahromaděnými nevyřízenými záležitostmi. Vývojář, někdy v IT, někdy integrovaný do obchodního týmu, napíše řešení, které funguje. Řešení běží, řeší problém a stává se součástí provozního pracovního postupu. Formální proces správy a řízení nikdy neprobíhá, protože problém je již vyřešen.
Vzorec „dočasné, které se stalo trvalým“. Nejzákeřnější forma stínového aplikačního softwaru začíná jako explicitně dočasné řešení. „Jen do doby, než bude připraven skutečný systém.“ „Rychlé řešení problému s formátem dat.“ „Dočasné, dokud čekáme, až dodavatel opraví své API.“ Dočasná řešení se stanou trvalými, když závislosti, které se kolem nich hromadí, nejsou nikdy odstraněny. Oprava výpočtu data v COBOLu napsaná pro nápravu Y2K, která je stále volána i po dvaceti pěti letech, protože žádný další vývojář nevěděl, proč existuje nebo zda je bezpečné ji odstranit. „Dočasný“ skript pro normalizaci databáze, který se stal součástí noční dávky, protože cílová aplikace nebyla nikdy skutečně sestavena.
Selhání přenosu znalostí. Stínové aplikace vytvořené konkrétními jednotlivci zanechávají zdokumentované znalosti organizace, když tito jednotlivci odejdou. Program pokračuje v provozu, je integrován do produkčních procesů, které na něm závisí, ale neexistuje žádná dokumentace, není přiřazeno žádné vlastnictví a nikdo neví, co dělá dostatečně podrobně, aby to mohl bezpečně změnit. V produkčním prostředí se stává duchem: viditelný ve svých účincích, neviditelný ve své správě.
Stínový datový kanál. Integrace dat je obzvláště úrodnou půdou pro nedokumentovaný vlastní software. Pokud oficiální vrstva ETL nepodporuje potřebnou transformaci nebo pokud obchodní proces vyžaduje, aby se data mezi systémy přesouvala rychleji, než umožňuje oficiální integrační proces, vývojáři vytvářejí neoficiální programy pro přesun dat. Skript v Pythonu, který se dotazuje produkční databáze a zapisuje výsledky na sdílený disk, který si vyzvedne následný proces. Program v COBOLu, který čte z mainframe DB2 a zapisuje do plochého souboru, který cloudová aplikace přijímá. Tyto neoficiální datové kanály překračují hranice systému, zpracovávají potenciálně citlivá data a fungují zcela mimo rámec správy integrace.
Čtyři kategorie stínového aplikačního softwaru
Kategorie 1: Vlastní aplikace pro obchodní jednotky
Programy vytvořené vývojáři integrovanými do obchodních jednotek, financí, nákupu, provozu a dodržování předpisů, které řeší problémy specifických domén. Tyto programy obvykle:
- Jsou pojmenovány neformálně (TAXCALC, VENDREPT, ADJBATCH) bez dodržování podnikových konvencí pojmenování.
- Žijí v adresářích nebo knihovnách spravovaných obchodní jednotkou, nikoli IT
- Nemají žádný záznam v databázi pro správu konfigurace (CMDB).
- V systému správy IT služeb nemám přiřazeného technického vlastníka.
- Chybí formální dokumentace, pokrytí testy a historie řízení změn
Jejich kritičnost je často podceňována, protože obchodní jednotka ví, co program dělá, a považuje ho za „svůj“. IT oddělení, které o existenci programu neví, nemůže jeho kritičnost hodnotit. Absence programu v inventáři aplikací IT oddělení znamená, že chybí v BCP, plánování obnovy po havárii, bezpečnostních posouzeních a rozsahu modernizačního programu.
Kategorie 2: Programy typu „ghost“
Programy, které se objevují v produkčním prostředí, ale jejichž původ, účel a vlastnictví nejsou současné organizaci známé. Existují v knihovnách pro načítání a úložištích zdrojových kódů, jsou volány jinými programy nebo vyvolávány úlohami JCL, produkují výstupy, na kterých závisí následné procesy, ale organizační paměť o tom, proč existují a kdo je za ně zodpovědný, byla ztracena.
Ghost programy jsou obzvláště nebezpečné z hlediska bezpečnosti a dodržování předpisů, protože je nelze posoudit podle současných standardů, nelze je zahrnout do programů skenování zranitelností, které vyžadují přiřazení vlastnictví aplikace, a nelze je posoudit z hlediska souladu s předpisy, protože nikdo neví, k jakým datům přistupují nebo jakou obchodní funkci slouží.
Kategorie 3: Stínové datové kanály
Neoficiální programy, které přesouvají data mezi systémy mimo schválenou integrační architekturu. Ty sahají od sofistikovaných alternativ ETL až po jednoduché skripty pro přenos souborů:
krajta
# 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")Tento program, reprezentativní pro vzorec nalezený v podnikových prostředích, používá pevně zakódované přihlašovací údaje k produkční databázi, zapisuje citlivé fakturační údaje do sdíleného síťového umístění bez šifrování a běží bez monitorování již léta poté, co jeho autor opustil organizaci. Neobjevil by se v žádném nástroji pro vyhledávání SaaS, protože běží na interní infrastruktuře. Neobjevil by se v analýze síťového provozu, protože používá standardní databázové protokoly, které nevytvářejí žádný rozlišitelný podpis. Je viditelný pouze v samotném zdrojovém kódu.
Kategorie 4: Nedokumentované dávkové úlohy
Toky úloh JCL a plánované programy, které běží na produkční infrastruktuře, ale chybí v oficiální dokumentaci k plánování úloh. Tyto se hromadí prostřednictvím:
- Úlohy odeslané mimo standardní plánovač úloh prostřednictvím přímého odeslání
- Programy volané dynamicky z jiných programů (a proto nejsou nezávisle viditelné v inventářích plánovačů)
- Úlohy, které se provádějí zřídka, na konci měsíce, na konci roku nebo pouze tehdy, když nastanou specifické obchodní podmínky, a nikdy nebyly zachyceny v rámci běžných auditů zásob
- Úlohy zděděné z předchozích systémů, které byly „migrovány“, ale nikdy formálně vyřazeny z provozu
Nedokumentované dávkové úlohy se stávají kritickými body selhání, když:
- Údržbové období má vliv na systém, na kterém běží, a nikdo neví, jak informovat obchodní jednotku, která je na jejich výstupech závislá.
- Provádí se bezpečnostní posouzení a tyto úlohy se spouštějí jako nemonitorované servisní účty se zvýšenými oprávněními.
- Modernizační program vymezuje rozsah migrace na základě zdokumentovaného harmonogramu úloh a do cílového prostředí dorazí bez kritického dávkového zpracování.
Metody objevování podle kategorie stínového softwaru
Metody vyhledávání vhodné pro SaaS shadow IT jsou do značné míry nepoužitelné pro shadow aplikační software. Požadované metody jsou:
Analýza knihovny pro načítání. Každý program, který byl kdy zkompilován a nasazen na mainframe nebo systém střední třídy, existuje v knihovně pro načítání, což je úložiště spustitelných souborů. Porovnání programů v knihovně pro načítání s programy v oficiálním inventáři aplikací odhaluje mezeru: každý modul pro načítání, který se objevuje v knihovně, ale nikoli v inventáři, je stínový program. Tato analýza nevyžaduje žádný zdrojový kód, pracuje s kompilovanými spustitelnými soubory a jejich metadaty.
Procházení repozitářů zdrojového kódu. Repozitáře zdrojového kódu (PDS zdrojového kódu COBOL, repozitáře Git, knihovny zdrojového kódu RPG) obsahují všechny programy, které kdy byly napsány, včetně programů, které byly napsány neformálně, neformálně nasazeny a nikdy nebyly registrovány v systémech IT governance. Procházení celého repozitáře zdrojového kódu v CMDB odhalí programy, které existují ve zdrojovém kódu, ale nemají žádný záznam o governance.
Odsouhlasení JCL a plánovače. Každý proud úloh JCL, který se spouští v produkčním prostředí, ať už je odeslán prostřednictvím oficiálního plánovače, odeslán ručně nebo vyvolán jinou úlohou, zanechává stopu v protokolu provádění úloh (JESLOG, SYSLOG). Porovnání programů, které se objevují v protokolech provádění produkčního prostředí, s programy v oficiálním inventáři identifikuje programy, které běží v produkčním prostředí bez pokrytí governance.
Dynamická analýza CALL. Programy, které dynamicky volají jiné programy, kde je název volaného programu určen za běhu, nikoli při kompilaci, vytvářejí závislosti, které jsou pro statickou analýzu plánovače neviditelné. Dynamická analýza CALL sleduje, které programy vydávají příkazy CALL s proměnnými názvy programů, identifikuje rozsah programů, které by mohly být volány, a označuje programy dosažitelné prostřednictvím dynamického odesílání, které se nemusí objevit v žádné statické mapě závislostí.
Trasování toku dat. Stínové datové kanály lze zjistit analýzou vzorců přístupu k souborovému systému a databázi: které programy čtou nebo zapisují do kterých datových sad, souborů nebo databázových tabulek. Program, který čte z produkční databáze a zapisuje do cesty k souboru mimo standardní hierarchii správy dat, je kandidátem na stínový kanál.
Stínová dimenze umělé inteligence
Rozšířením problému stínového IT v roce 2026 je stínová umělá inteligence, zaměstnanci a obchodní jednotky používající nástroje a agenty umělé inteligence bez autorizace IT. Podle zprávy IBM o nákladech na únik dat z roku 2026 se 43 procent bezpečnostních incidentů týká pracovníků používajících stínovou umělou inteligenci. Společnost Gartner předpovídá, že do roku 2030 více než 40 procent podniků zažije bezpečnostní incident nebo incident splňující předpisy spojený s neoprávněnou stínovou umělou inteligencí.
Specifické riziko, které stínová umělá inteligence představuje a které přímo souvisí se stínovou IT na úrovni kódu: proprietární zdrojový kód vstupující do programovacích asistentů s umělou inteligencí. Zaměstnanec, který používá neautorizovaného programovacího asistenta s umělou inteligencí k pomoci se starším programem v COBOLu, odeslal zdrojový kód tohoto programu externímu poskytovateli umělé inteligence. Zdrojový kód může obsahovat pevně zakódované přihlašovací údaje, obchodní logiku, která představuje obchodní tajemství, nebo datové struktury, jejichž zveřejnění porušuje požadavky na umístění dat. Metodou odhalování tohoto specifického rizika není analýza síťového provozu, ale detekce, ke kterým programům přistupovaly nástroje komunikující s externími API umělé inteligence, což vyžaduje monitorování na úrovni aplikace, nikoli monitorování na úrovni sítě.
Problém stínové umělé inteligence a problém stínové aplikační softwarové technologie sdílejí důležitou charakteristiku: oba jsou neviditelné pro síťové nástroje pro vyhledávání, které dominují na trhu stínových IT v oblasti SaaS. Oba vyžadují k odhalení buď monitorování na úrovni aplikací, nebo strukturální analýzu kódu.
Vytvoření kompletního inventáře aplikací
Výstupem stínového programu pro vyhledávání IT dat pro podnikový aplikační software je sladěný inventář, který zahrnuje čtyři populace:
Známé a zdokumentované: Programy, které se objevují jak v oficiálním inventáři, tak i ve skutečném produkčním prostředí. Tyto programy mají systém správy a řízení, přiřazené vlastníky, historii změn a plány obnovy po havárii.
Známé, ale nenasazené: Programy, které se objevují v oficiálním inventáři, ale nelze je nalézt v knihovnách pro načítání nebo v protokolech produkčního spuštění. Jedná se o kandidáty na vyřazení, mohly být vyřazeny z provozu bez řádného formálního vyřazení nebo mohly být uvedeny nesprávně.
Neznámé, ale nasazené (stínové programy): Programy, které se objevují v protokolech spouštění produkčních systémů nebo načítají knihovny, ale nemají žádný záznam v oficiálním inventáři. Jedná se o klíčové stínové IT zjištění, programy, které vyžadují okamžité přiřazení vlastnictví, posouzení zabezpečení a registraci v systému governance.
Nedokumentované závislosti: Programy, které se neobjevují ani v oficiálním inventáři, ani v primárních produkčních protokolech, ale jsou zjištěny pomocí dynamické analýzy CALL nebo trasování toku dat jako dosažitelné z produkčních procesů. Jedná se o fiktivní programy, které je nejtěžší najít a které je nejnebezpečnější nechat neobjeveny.
Usmíření mezi těmito čtyřmi populacemi vede k akčnímu plánu: registrace stínových programů, posouzení jejich bezpečnostní situace, přidělení vlastnictví a určení jejich nakládání, správa a údržba, modernizace nebo ukončení provozu.
Jak SMART TS XL Provádí zjišťování IT na úrovni kódu ze stínového prostředí.
SMART TS XLPřístup společnosti ke stínovému IT objevování řeší kategorie na úrovni kódu, ke kterým síťové nástroje nemohou dosáhnout.
Schopnost statické analýzy kódu začíná kompletním procházením zdrojového repozitáře: každý program v COBOLu, RPG modul, PL/I aplikace, Java služba, Python skript a JCL stream úloh v prostředí je katalogizován s uvedením umístění zdroje, jazyka, velikosti a předběžného profilu složitosti. Tento inventář je základní linií, s níž se porovnává CMDB a oficiální registr aplikací. Programy, které se objevují ve zdrojovém repozitáři, ale nikoli v oficiálním inventáři, jsou primárním nálezem stínových aplikací.
Mapování závislostí aplikací řeší problém dynamického volání: trasováním každého příkazu CALL v každém programu, včetně dynamických volání, kde je název programu proměnnou, mapa závislostí identifikuje programy, které jsou dosažitelné z produkčních procesů, i když se nikdy neobjevují v inventářích statických plánovačů. Fantomový program, který je dynamicky volán deseti produkčními programy, se objeví v mapě závislostí, i když nemá žádnou nezávislou definici úlohy JCL.
Funkce rozšíření JCL sleduje kompletní řetězec provádění každého proudu úloh JCL: řešení odkazů PROC, rozšiřování symbolických parametrů a vytváření úplné mapy programů, které každá úloha volá. Po porovnání této mapy s oficiální dokumentací k plánu úloh se automaticky zobrazí úlohy a programy, které běží v produkčním prostředí bez dokumentace.
Díky analýze dopadů jsou zjištění z objevů prakticky využitelné: pro každý objevený stínový program se vyjmenují všechny produkční procesy, které na něm závisí. Stínový program bez závislých programů je kandidátem na mrtvý kód, který lze bezpečně vyřadit. Stínový program s dvaceti produkčními závislými programy je kritickým nedokumentovaným aktivem, které vyžaduje okamžitou pozornost správy a řízení. Rozsah dopadu určuje prioritu nápravy.
Funkce podnikového vyhledávání umožňuje dotazování celého inventáře: nalezení každého programu, který přistupuje ke konkrétní datové sadě (potenciální kandidáti na kanál stínových dat), každého programu napsaného po určitém datu, který nemá záznam v CMDB (nedávné stínové aplikace), každého programu, který zapisuje do externích cest k souborům mimo standardní hierarchii správy dat. Tato vyhledávací funkce podporuje jak počáteční vyhledávání, tak průběžné monitorování, které zabraňuje obnovení akumulace stínových aplikací po počátečním vyčištění.
Pro organizace provádějící starší modernizační programy je vyhledávání stínových aplikací nezbytným krokem. Modernizační program, který vymezuje rozsah migrace na základě oficiálního inventáře aplikací a odhaluje stínové programy v průběhu jejich provádění, je modernizační program, jehož rozsah, časový harmonogram i rozpočet byly v okamžiku závazku nesprávné. K odhalení, které mělo proběhnout před plánováním, nyní dochází během provádění, kdy jsou jeho náklady nejvyšší.
Reakce správy věcí veřejných: Ne blokování, ale viditelnost
Organizace, které v roce 2026 efektivně spravují stínové IT, zjistily, že plošný zákaz nefunguje a vytváří zvrácené pobídky. Reporting stínového IT ve většině organizací selhává z jednoho důvodu: zaměstnanci očekávají trest. Když člen finančního týmu použije neschválený systém sledování výdajů a sám to nahlásí, bezpečnostní tým, který reaguje napomenutím, vyškolil tohoto zaměstnance a všechny, s nimiž mluví, aby příště mlčeli.
Stejný princip platí i pro software stínových aplikací. Vývojář, který vytvořil kriticky důležitý nástroj v COBOLu, na kterém je organizace závislá, by neměl být trestán za to, že neprošel procesem správy a řízení, který v dané době nemusel být jasně komunikován. Reakce správy a řízení na objevování stínových aplikací by měla být:
Registrace, nikoli odstranění. Stínové programy, u kterých se zjistí, že se nacházejí v kritické cestě obchodních procesů, nejsou stínové programy, které je třeba odstranit, ale jsou to nedokumentované produkční aplikace, které vyžadují ochranu v rámci governance. Zaregistrujte je, přiřaďte vlastníky, vyhodnoťte jejich bezpečnostní stav a zacházejte s nimi se stejnými pravidly governance jako s jakoukoli jinou produkční aplikací.
Amnestie za sebeprozrazení. Program správy a řízení, který vytváří bezpečné kanály pro obchodní jednotky, aby mohly zveřejňovat neformální aplikace, které vytvořily, odhaluje software rychleji než jakýkoli přístup technického odhalování. Jistota, že zveřejnění vede k podpoře správy a řízení, pomoci s dokumentací, bezpečnostní kontrole a formální registraci, spíše než k disciplinárnímu řešení, odstraňuje motivaci k utajování.
Prevence prostřednictvím procesu. Hlavní příčinou hromadění stínových aplikací je tření v řízení: oficiální proces žádosti o vývoj nových aplikací je pomalejší, než vyžaduje daný obchodní problém. Snížení tohoto tření, odlehčená a rychlá správa vývoje, integrovaná podpora IT řízení v obchodních jednotkách a zjednodušené schvalování nízkorizikových interních nástrojů snižují míru vytváření nových stínových aplikací, aniž by bylo nutné průběžně technicky zjišťovat informace.
Zásoby, o kterých si myslíte, že je máte, nejsou tím, co máte
Rozdíl mezi inventářem aplikací, který udržuje IT oddělení, a aplikačním softwarem, který skutečně běží v podnikových prostředích, není zanedbatelný. Ve velkých organizacích s desítkami let akumulace aplikací se rozdíl mezi zdokumentovaným a skutečným stavem může blížit třiceti procentům všech programů. Nezdokumentovaných třicet procent zahrnuje programy, které zpracovávají citlivá data, plní funkce dodržování předpisů, nacházejí se v kritické cestě obchodních procesů a obsahují bezpečnostní zranitelnosti, které nikdo nekontroloval, protože nikdo nevěděl, že by je měl zkontrolovat.
Nástroje pro vyhledávání stínových IT v SaaS dobře řeší cloudovou vrstvu tohoto problému. Problém stínových IT na úrovni kódu, vlastní programy, fiktivní utility, neformální datové kanály a nedokumentované dávkové úlohy, které zaplňují starší podniková prostředí, vyžaduje jiný přístup: strukturální analýzu skutečných softwarových artefaktů spíše než monitorování síťového provozu. Inventář, který z této analýzy vyplyne, je často překvapivě úplný. Organizace, které tuto práci provádějí, opakovaně zjišťují, že to, co si myslely, že běží v produkčním prostředí, a to, co skutečně běží, jsou dvě smysluplně odlišné věci. Překlenutí této mezery je základem každého programu správy, zabezpečení, BCP a modernizace, který závisí na znalosti toho, co organizace skutečně provozuje.
