Aufdeckung von Schatten-IT: Anwendungen finden, die niemand dokumentiert hat

Jedes Unternehmen weiß, dass es Schatten-IT gibt. Die Zahl, die das Problem verdeutlicht: Die meisten Unternehmen betreiben mehr als 1,000 Cloud-Anwendungen, und die IT hat in der Regel nur bei weniger als 10 Prozent davon Einblick. Große Unternehmen nutzen durchschnittlich 473 SaaS-Anwendungen; die IT verwaltet direkt nur einen Bruchteil davon. 80 Prozent der Mitarbeitenden verwenden nicht genehmigte Anwendungen für ihre Arbeit. Die Zahlen sind in allen Studien konsistent, da die dahinterstehende Dynamik dieselbe ist: Mitarbeitende und Geschäftsbereiche setzen Tools ein, die akute Probleme schneller lösen, als die IT-Governance-Prozesse sie bewerten und genehmigen können.

Die Diskussion um Schatten-IT im Jahr 2026 wird von SaaS-Erkennungstools dominiert, die DNS-Logs scannen, SSO-OAuth-Token analysieren, Spesenabrechnungen prüfen und Netzwerkverkehr charakterisieren, um Cloud-Anwendungen aufzuspüren, die Mitarbeiter ohne Autorisierung nutzen. Diese Tools lösen die SaaS-Ebene des Problems – und zwar recht gut. Was sie jedoch nicht lösen und was kein SaaS-Erkennungstool adressiert, ist das andere Problem der Schatten-IT: die individuell entwickelten Anwendungen, undokumentierten Batch-Programme, informellen Datenpipelines und unsichtbaren Hilfsprogramme, die in Unternehmensanwendungsportfolios existieren und nie in einem Asset-Management-System, einem Änderungsprotokoll oder einem IT-Inventar aufgetaucht sind. Es handelt sich dabei nicht um von Mitarbeitern bereitgestellte Cloud-Anwendungen. Es sind Produktionsprogramme, die auf Mainframes und Midrange-Systemen laufen und geschäftskritische Funktionen ausführen, deren Nutzung die Unternehmen, denen sie gehören, nicht vollständig nachvollziehen können.

Die beiden Probleme erfordern unterschiedliche Vorgehensweisen zur Problemanalyse. Das SaaS-Schatten-IT-Problem erfordert Netzwerktransparenz und Identitätsintegration. Das Schatten-IT-Problem auf Codeebene erfordert die Analyse der eigentlichen Softwareartefakte – Quellcode, geladene Bibliotheken, JCL-Jobstreams –, um die vorhandenen Programme und ihre Funktionen zu ermitteln. Dieser Leitfaden behandelt beide Problemstellungen, wobei der Schwerpunkt auf der zweiten Kategorie liegt, die bisher von anderen Publikationen vernachlässigt wurde.

Die zwei Schatten-IT-Probleme

Schatten-IT wird typischerweise als Technologie definiert, die innerhalb einer Organisation ohne explizite Genehmigung oder Kenntnis der IT-Abteilung eingesetzt wird. Diese Definition umfasst zwei grundlegend verschiedene Phänomene, die unterschiedliche Ermittlungsansätze und unterschiedliche Governance-Maßnahmen erfordern.

Schatten-SaaS und Cloud-Tools sind Anwendungen und Dienste, die von Mitarbeitern oder Geschäftsbereichen ohne formale IT-Beschaffung genutzt werden. Beispiele hierfür sind ein Marketingteam, das ein nicht genehmigtes KI-Tool zum Texten verwendet, ein Finanzteam, das Tabellenkalkulationen über ein privates Dropbox-Konto teilt, oder ein Entwickler, der einen nicht autorisierten KI-Programmierassistenten einsetzt, der proprietären Quellcode an eine externe API sendet. Diese Anwendungen existieren außerhalb der Unternehmensinfrastruktur und sind über externe Signale auffindbar: DNS-Abfragen, OAuth-Autorisierungen, Spesenabrechnungen und Netzwerkverkehrsmuster.

Schattensoftware , die Kategorie, auf die sich dieser Artikel speziell konzentriert, umfasst individuell entwickelte Programme und Batch-Prozesse, die innerhalb der eigenen Infrastruktur des Unternehmens erstellt und nie ordnungsgemäß dokumentiert, inventarisiert oder verwaltet wurden. Ein Beispiel: Ein COBOL-Programm, das 1994 von einem Entwickler der Finanzabteilung geschrieben wurde, um einen speziellen Sonderfall bei der Steuerberechnung zu behandeln. Ein RPG-Programm, das von einem Business-Analysten erstellt wurde, um EDI-Dateien für einen bestimmten Handelspartner zu generieren. Ein JCL-Job, der jeden Monatsende ausgeführt wird und einen für das Compliance-Team wichtigen Bericht erstellt – entwickelt von einem externen Dienstleister, der das Unternehmen 2009 verließ. Ein Java-Dienstprogramm, das 2018 im Rahmen eines Systemintegrationsprojekts „temporär“ geschrieben wurde und sich ohne entsprechende Entscheidung zu einer permanenten Abhängigkeit entwickelte.

Diese Programme sind in den DNS-Protokollen nicht sichtbar, da sie auf der internen Infrastruktur laufen. Sie erscheinen auch nicht in den OAuth-Autorisierungsdatensätzen, da sie vor der Einführung von OAuth entwickelt wurden. Sie sind nicht im offiziellen Anwendungsinventar enthalten, da sie nie formell zur Überprüfung durch die IT-Governance eingereicht wurden. Sie lassen sich nur durch die Untersuchung der Infrastruktur selbst, der Ladebibliotheken, der Quellcode-Repositories, der Job-Scheduler und der Ausführungsprotokolle aufspüren, die Aufschluss darüber geben, welche Software tatsächlich in der Umgebung ausgeführt wird.

Warum dies über die Vollständigkeit des Inventars hinaus von Bedeutung ist: 74 Prozent der Unternehmen haben Sicherheitsvorfälle aufgrund unbekannter oder nicht verwalteter Assets erlebt. Schattenanwendungen stellen eine Kategorie unbekannter Assets dar, die weder netzwerkbasierte Erkennungstools noch SaaS-Visualisierungsplattformen aufspüren können.

Warum sich Schatten-Anwendungssoftware ansammelt

Das Verständnis dafür, warum undokumentierte kundenspezifische Anwendungen in Unternehmensumgebungen so weit verbreitet sind, erklärt, warum Standard-Governance-Prozesse dies nicht verhindern können und warum eine nachträgliche Ermittlung notwendig ist.

Die sofortige Lösung ist unerlässlich. Geschäftsbereiche stehen vor spezifischen operativen Problemen, die spezifische Lösungen erfordern. Die genehmigte Anwendung deckt den Sonderfall nicht ab. Die IT-Anfragewarteschlange ist überlastet. Ein Entwickler, teils in der IT, teils in einem Fachteam integriert, entwickelt eine funktionierende Lösung. Diese Lösung läuft, behebt das Problem und wird in den operativen Workflow integriert. Der formale Governance-Prozess entfällt, da das Problem bereits gelöst ist.

Das Muster „Provisorisch wird permanent“. Die heimtückischste Form von Schattensoftware beginnt als explizit temporäre Lösung. „Nur bis das eigentliche System fertig ist.“ „Ein schneller Workaround für das Datenformatproblem.“ „Vorübergehend, während wir darauf warten, dass der Anbieter seine API repariert.“ Temporäre Lösungen werden permanent, wenn die sich anhäufenden Abhängigkeiten nicht aufgelöst werden. Die COBOL-Datumsberechnungskorrektur, die zur Behebung des Jahr-2000-Problems geschrieben wurde, wird auch 25 Jahre später noch verwendet, weil kein nachfolgender Entwickler wusste, warum sie existierte oder ob sie gefahrlos entfernt werden konnte. Das „temporäre“ Datenbanknormalisierungsskript, das Teil des nächtlichen Batch-Builds wurde, weil die Zielanwendung nie tatsächlich erstellt wurde.

Das Scheitern des Wissenstransfers. Schattenanwendungen, die von einzelnen Mitarbeitern entwickelt wurden, verschwinden aus der dokumentierten Wissensbasis des Unternehmens, sobald diese Mitarbeiter ausscheiden. Das Programm läuft zwar weiter und ist in Produktionsprozesse eingebettet, die von ihm abhängen, doch es existiert keine Dokumentation, keine Zuständigkeit ist festgelegt und niemand kennt seine Funktionsweise detailliert genug, um es sicher zu ändern. Es wird zu einem Gespenst in der Produktionsumgebung: sichtbar in seinen Auswirkungen, unsichtbar in seiner Steuerung.

Die Schatten-Datenpipeline. Datenintegration bietet besonders viel Raum für undokumentierte, kundenspezifische Software. Wenn die offizielle ETL-Schicht eine benötigte Transformation nicht unterstützt oder ein Geschäftsprozess einen schnelleren Datentransfer zwischen Systemen erfordert, als der offizielle Integrationsprozess zulässt, erstellen Entwickler inoffizielle Datentransferprogramme. Ein Python-Skript fragt die Produktionsdatenbank ab und schreibt die Ergebnisse auf ein gemeinsames Laufwerk, von dem ein nachgelagerter Prozess sie abruft. Ein COBOL-Programm liest Daten aus der Mainframe-DB2-Datenbank und schreibt sie in eine Textdatei, die von einer Cloud-Anwendung verarbeitet wird. Diese inoffiziellen Datenpipelines überschreiten Systemgrenzen, verarbeiten potenziell sensible Daten und operieren vollständig außerhalb des Integrations-Governance-Frameworks.

Die vier Kategorien von Schatten-Anwendungssoftware

Kategorie 1: Kundenspezifische Anwendungen für Geschäftsbereiche

Programme, die von Entwicklern in Geschäftsbereichen wie Finanzen, Beschaffung, Betrieb und Compliance erstellt werden und spezifische Probleme in diesem Bereich lösen. Diese Programme sind typischerweise:

• Sie werden informell benannt (TAXCALC, VENDREPT, ADJBATCH) und folgen nicht den Namenskonventionen des Unternehmens.
• Die Daten werden in Verzeichnissen oder Bibliotheken gespeichert, die von der Geschäftseinheit und nicht von der IT verwaltet werden.
• Kein Eintrag in der Konfigurationsverwaltungsdatenbank (CMDB) vorhanden.
• Im IT-Servicemanagementsystem ist kein technischer Verantwortlicher zugewiesen.
• Fehlende formale Dokumentation, Testabdeckung und Änderungskontrollhistorie

Ihre Bedeutung wird häufig unterschätzt, da die Fachabteilung die Funktion des Programms kennt und es als ihr eigenes betrachtet. Die IT-Abteilung, der das Programm nicht bekannt ist, kann dessen Bedeutung nicht einschätzen. Da das Programm nicht im Anwendungsinventar der IT enthalten ist, wird es weder in der Geschäftskontinuitätsplanung noch in der Notfallwiederherstellungsplanung, den Sicherheitsbewertungen oder im Umfang von Modernisierungsprogrammen berücksichtigt.

Kategorie 2: Geisterprogramme

Programme, die im Produktivbetrieb eingesetzt werden, deren Ursprung, Zweck und Verantwortlichkeit der aktuellen Organisation jedoch unbekannt sind. Sie existieren in Ladebibliotheken und Quellcode-Repositories, werden von anderen Programmen aufgerufen oder durch JCL-Jobs gestartet und erzeugen Ausgaben, von denen nachgelagerte Prozesse abhängen. Das organisatorische Wissen darüber, warum sie existieren und wer dafür verantwortlich ist, ist jedoch verloren gegangen.

Ghost-Programme sind aus Sicherheits- und Compliance-Sicht besonders gefährlich, da sie nicht anhand aktueller Standards überprüft werden können, nicht in Schwachstellenscan-Programme einbezogen werden können, die die Zuweisung der Anwendungsverantwortung erfordern, und nicht auf die Einhaltung gesetzlicher Vorschriften geprüft werden können, da niemand weiß, auf welche Daten sie zugreifen oder welche Geschäftsfunktion sie erfüllen.

Kategorie 3: Schatten-Datenpipelines

Inoffizielle Programme, die Daten zwischen Systemen außerhalb der genehmigten Integrationsarchitektur übertragen. Diese reichen von ausgefeilten ETL-Alternativen bis hin zu einfachen Dateiübertragungsskripten:

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")

Dieses Programm, das typisch für ein in Unternehmensumgebungen häufig anzutreffendes Muster ist, verwendet fest codierte Zugangsdaten für die Produktionsdatenbank, speichert sensible Abrechnungsdaten unverschlüsselt in einem gemeinsam genutzten Netzwerkverzeichnis und lief jahrelang unüberwacht, nachdem der Autor das Unternehmen verlassen hatte. Es würde von keinem SaaS-Erkennungstool erfasst, da es auf der internen Infrastruktur läuft. Auch bei der Netzwerkverkehrsanalyse würde es nicht auffallen, da es Standard-Datenbankprotokolle verwendet, die keine eindeutige Signatur erzeugen. Es ist ausschließlich im Quellcode selbst sichtbar.

Kategorie 4: Nicht dokumentierte Stapelverarbeitungsaufträge

JCL-Jobstreams und geplante Programme, die auf der Produktionsinfrastruktur ausgeführt werden, aber nicht in der offiziellen Jobplanungsdokumentation aufgeführt sind. Diese sammeln sich an durch:

• Aufträge, die außerhalb des Standard-Auftragsplaners per Direkteinreichung eingereicht wurden
• Programme, die dynamisch aus anderen Programmen aufgerufen werden (und daher nicht unabhängig in den Scheduler-Inventaren sichtbar sind)
• Aufträge, die nur selten, zum Monatsende, zum Jahresende oder nur unter bestimmten Geschäftsbedingungen ausgeführt werden und noch nie bei routinemäßigen Inventurprüfungen erfasst wurden.
• Jobs, die von Vorgängersystemen übernommen wurden, welche zwar „migriert“, aber nie formell außer Betrieb genommen wurden

Nicht dokumentierte Batch-Jobs werden zu kritischen Fehlerquellen, wenn:

• Ein Wartungsfenster beeinträchtigt das System, auf dem sie laufen, und niemand weiß, wie er die Geschäftseinheit benachrichtigen soll, die von ihren Ergebnissen abhängig ist.
• Es wird eine Sicherheitsbewertung durchgeführt und diese Prozesse werden als unüberwachte Dienstkonten mit erhöhten Berechtigungen ausgeführt.
• Ein Modernisierungsprogramm plant die Migration anhand des dokumentierten Arbeitsablaufs und führt in der Zielumgebung zu einem Mangel an kritischer Stapelverarbeitung.

Ermittlungsmethoden nach Schattensoftware-Kategorie

Die für SaaS-Schatten-IT geeigneten Erkennungsmethoden sind für Schatten-Anwendungssoftware weitgehend ungeeignet. Folgende Methoden sind erforderlich:

Analyse der Ladebibliothek. Jedes Programm, das jemals kompiliert und auf einem Mainframe- oder Midrange-System bereitgestellt wurde, existiert in einer Ladebibliothek, dem Repository für ausführbare Dateien. Der Vergleich der Programme in der Ladebibliothek mit den Programmen im offiziellen Anwendungsinventar deckt die Diskrepanz auf: Jedes Lademodul, das in der Bibliothek, aber nicht im Inventar vorhanden ist, ist ein Schattenprogramm. Diese Analyse benötigt keinen Quellcode; sie arbeitet mit den kompilierten ausführbaren Dateien und deren Metadaten.

Durchlaufen von Quellcode-Repositories. Quellcode-Repositories (COBOL-Quellcode-PDSs, Git-Repositories, RPG-Quellcode-Bibliotheken) enthalten jedes jemals geschriebene Programm, einschließlich informell erstellter und bereitgestellter Programme, die nie in IT-Governance-Systemen registriert wurden. Durch das Durchlaufen des gesamten Quellcode-Repositorys anhand der CMDB werden Programme sichtbar, die zwar im Quellcode vorhanden sind, aber keinen Governance-Eintrag haben.

JCL- und Scheduler-Abgleich. Jeder JCL-Jobstream, der in der Produktionsumgebung ausgeführt wird – unabhängig davon, ob er über den offiziellen Scheduler, manuell oder durch einen anderen Job gestartet wurde –, hinterlässt eine Spur im Jobausführungsprotokoll (JESLOG, SYSLOG). Durch den Vergleich der in den Produktionsausführungsprotokollen aufgeführten Programme mit den Programmen im offiziellen Inventar lassen sich Programme identifizieren, die in der Produktionsumgebung ohne Governance-Abdeckung ausgeführt werden.

Dynamische CALL-Analyse. Programme, die andere Programme dynamisch aufrufen, wobei der Name des aufgerufenen Programms zur Laufzeit und nicht zur Kompilierzeit bestimmt wird, erzeugen Abhängigkeiten, die für die statische Scheduler-Analyse unsichtbar sind. Die dynamische CALL-Analyse verfolgt, welche Programme CALL-Anweisungen mit variablen Programmnamen ausgeben, identifiziert den Bereich der potenziell aufrufbaren Programme und kennzeichnet Programme, die über dynamische Dispatch erreichbar sind, aber möglicherweise in keiner statischen Abhängigkeitsübersicht erscheinen.

Datenflussverfolgung. Schatten-Datenpipelines lassen sich durch die Analyse von Dateisystem- und Datenbankzugriffsmustern aufspüren: Welche Programme lesen oder schreiben auf welche Datensätze, Dateien oder Datenbanktabellen? Ein Programm, das Daten aus einer Produktionsdatenbank liest und in einen Dateipfad außerhalb der Standard-Datenverwaltungshierarchie schreibt, ist ein potenzieller Schatten-Pipeline-Kandidat.

Die Schatten-KI-Dimension

Die Ausweitung des Schatten-IT-Problems bis 2026 betrifft Schatten-KI: Mitarbeiter und Geschäftsbereiche nutzen KI-Tools und -Agenten ohne IT-Autorisierung. Laut dem IBM-Bericht „Cost of a Data Breach 2026“ sind 43 Prozent der Sicherheitsvorfälle auf Mitarbeiter zurückzuführen, die Schatten-KI einsetzen. Gartner prognostiziert, dass bis 2030 mehr als 40 Prozent der Unternehmen einen Sicherheits- oder Compliance-Vorfall im Zusammenhang mit unautorisierter Schatten-KI erleben werden.

Das spezifische Risiko, das Schatten-KI mit sich bringt und das direkt mit Schatten-IT auf Codeebene zusammenhängt, ist die Weitergabe von proprietärem Quellcode an KI-Programmierassistenten. Ein Mitarbeiter, der einen nicht autorisierten KI-Programmierassistenten zur Unterstützung eines älteren COBOL-Programms verwendet, hat den Quellcode dieses Programms an einen externen KI-Anbieter übermittelt. Der Quellcode kann fest codierte Zugangsdaten, Geschäftslogik, die Geschäftsgeheimnisse darstellt, oder Datenstrukturen enthalten, deren Offenlegung gegen die Anforderungen an den Datenspeicherort verstößt. Die Erkennungsmethode für dieses spezifische Risiko ist nicht die Analyse des Netzwerkverkehrs, sondern die Ermittlung, auf welche Programme von Tools zugegriffen wurde, die mit externen KI-APIs kommunizieren. Dies erfordert eine Überwachung auf Anwendungsebene anstelle einer Überwachung auf Netzwerkebene.

Das Problem der Schatten-KI und das Problem der Schatten-Anwendungssoftware weisen eine wichtige Gemeinsamkeit auf: Beide bleiben für die netzwerkbasierten Erkennungstools, die den Markt für Schatten-IT im SaaS-Bereich dominieren, unsichtbar. Um beide Probleme aufzudecken, ist entweder eine Überwachung auf Anwendungsebene oder eine strukturelle Codeanalyse erforderlich.

Erstellung des vollständigen Anwendungsinventars

Das Ergebnis eines Programms zur Aufdeckung von Schatten-IT für Unternehmenssoftware ist ein abgeglichenes Inventar, das vier Bevölkerungsgruppen umfasst:

Bekannt und dokumentiert: Programme, die sowohl im offiziellen Inventar als auch in der tatsächlichen Produktionsumgebung aufgeführt sind. Diese Programme verfügen über Governance-Strukturen, zugewiesene Verantwortliche, eine Änderungshistorie und Notfallwiederherstellungspläne.

Bekannt, aber nicht im Einsatz: Programme, die im offiziellen Inventar aufgeführt sind, aber weder in den Ladebibliotheken noch in den Produktionsprotokollen gefunden werden können. Diese Programme sind Kandidaten für die Außerbetriebnahme, wurden möglicherweise ohne ordnungsgemäße formelle Außerbetriebnahme abgeschaltet oder sind fehlerhaft gelistet.

Unbekannt, aber im Einsatz (Schattenprogramme): Programme, die in Produktionsprotokollen oder Ladebibliotheken erscheinen, aber keinen Eintrag im offiziellen Inventar haben. Dies sind die Kernbefunde von Schatten-IT; Programme, die eine sofortige Zuweisung der Verantwortlichen, eine Sicherheitsbewertung und eine Registrierung in den Governance-Strukturen erfordern.

Nicht dokumentierte Abhängigkeiten: Programme, die weder im offiziellen Inventar noch in den primären Produktionsprotokollen erscheinen, sondern durch dynamische Aufrufanalyse oder Datenflussverfolgung als von Produktionsprozessen erreichbar identifiziert werden. Diese sogenannten Geisterprogramme sind am schwersten zu finden und stellen das größte Risiko dar, wenn sie unentdeckt bleiben.

Die Abstimmung zwischen diesen vier Gruppen führt zum Aktionsplan: Registrierung der Schattenprogramme, Bewertung ihrer Sicherheitslage, Zuweisung der Zuständigkeit und Festlegung ihrer weiteren Verwendung, Steuerung und Instandhaltung, Modernisierung oder Stilllegung.

Wie SMART TS XL Führt die Erkennung von Schatten-IT auf Codeebene durch.

SMART TS XLDer Ansatz von [Name des Unternehmens] zur Erkennung von Schatten-IT befasst sich mit den Codeebenenkategorien, die netzwerkbasierte Tools nicht erreichen können.

Die statische Codeanalyse beginnt mit der vollständigen Durchsuchung des Quellcode-Repositorys: Jedes COBOL-Programm, RPG-Modul, jede PL/I-Anwendung, jeder Java-Dienst, jedes Python-Skript und jeder JCL-Jobstream in der Umgebung wird mit Quellcode-Speicherort, Sprache, Größe und vorläufigem Komplexitätsprofil katalogisiert. Dieses Inventar dient als Grundlage für den Abgleich der CMDB und des offiziellen Anwendungsregisters. Programme, die im Quellcode-Repository, aber nicht im offiziellen Inventar vorhanden sind, stellen die primären Schattenanwendungen dar.

Die Abhängigkeitsabbildung für Anwendungen löst das Problem dynamischer Aufrufe: Durch die Verfolgung jeder CALL-Anweisung in jedem Programm, einschließlich dynamischer Aufrufe, bei denen der Programmname eine Variable ist, identifiziert die Abhängigkeitsabbildung Programme, die von Produktionsprozessen aus erreichbar sind, selbst wenn sie nie in statischen Scheduler-Inventaren erscheinen. Ein sogenanntes „Geisterprogramm“, das von zehn Produktionsprogrammen dynamisch aufgerufen wird, erscheint in der Abhängigkeitsabbildung, selbst wenn es keine unabhängige JCL-Jobdefinition besitzt.

Die JCL-Erweiterungsfunktion verfolgt die vollständige Ausführungskette jedes JCL-Jobstreams: Auflösung von PROC-Referenzen, Erweiterung symbolischer Parameter und Erstellung der vollständigen Liste der von jedem Job aufgerufenen Programme. Beim Vergleich dieser Liste mit der offiziellen Jobablaufdokumentation werden automatisch die Jobs und Programme identifiziert, die in der Produktion ohne Dokumentationsabdeckung ausgeführt werden.

Die Auswirkungsanalyse ermöglicht es, die Ergebnisse der Analyse in konkrete Maßnahmen umzuwandeln: Für jedes entdeckte Schattenprogramm werden alle davon abhängigen Produktionsprozesses aufgelistet. Ein Schattenprogramm ohne Abhängigkeiten ist potenziell toter Code und kann bedenkenlos stillgelegt werden. Ein Schattenprogramm mit zwanzig Produktionsabhängigkeiten stellt hingegen ein kritisches, nicht dokumentiertes Asset dar, das sofortige Aufmerksamkeit der Governance erfordert. Der Umfang der Auswirkungen bestimmt die Priorität der Behebungsmaßnahmen.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage des gesamten Inventars: Sie findet jedes Programm, das auf einen bestimmten Datensatz zugreift (potenzielle Kandidaten für Schatten-Datenpipelines), jedes Programm, das nach einem bestimmten Datum geschrieben wurde und keinen CMDB-Eintrag hat (neue Schattenanwendungen), sowie jedes Programm, das in externe Dateipfade außerhalb der Standard-Datenverwaltungshierarchie schreibt. Diese Suchfunktion unterstützt sowohl die anfängliche Ermittlung als auch die kontinuierliche Überwachung, die verhindert, dass sich nach der ersten Bereinigung erneut Schattenanwendungen ansammeln.

Für Organisationen, die Modernisierungsprogramme für Legacy- Systeme durchführen , ist die Ermittlung von Schattenanwendungen eine unerlässliche Voraussetzung. Ein Modernisierungsprogramm, das den Migrationsumfang auf Basis des offiziellen Anwendungsinventars festlegt und Schattenanwendungen erst während der Ausführung entdeckt, ist ein Programm, dessen Umfang, Zeitplan und Budget von Anfang an falsch waren. Die Ermittlung, die vor der Planung hätte erfolgen müssen, findet nun während der Ausführung statt – und verursacht damit die höchsten Kosten.

Die Antwort der Governance: Nicht Blockieren, sondern Sichtbarmachen

Unternehmen, die Schatten-IT im Jahr 2026 effektiv managen, haben erkannt, dass ein generelles Verbot nicht funktioniert und kontraproduktive Anreize schafft. Die Meldung von Schatten-IT scheitert in den meisten Organisationen aus einem Grund: Mitarbeiter erwarten Bestrafung. Wenn ein Mitarbeiter des Finanzteams ein nicht genehmigtes Spesenabrechnungstool verwendet und dies selbst meldet, hat das Sicherheitsteam, das lediglich eine Rüge ausspricht, diesen Mitarbeiter und alle, mit denen er spricht, dazu erzogen, beim nächsten Mal zu schweigen.

Dasselbe Prinzip gilt für Schattenanwendungen. Ein Entwickler, der ein geschäftskritisches COBOL-Tool erstellt hat, von dem das Unternehmen abhängig ist, sollte nicht dafür bestraft werden, dass er einen Governance-Prozess nicht durchlaufen hat, der möglicherweise zum damaligen Zeitpunkt nicht klar kommuniziert wurde. Die Reaktion der Governance auf die Entdeckung von Schattenanwendungen sollte wie folgt lauten:

Registrierung statt Entfernung. Schattenprogramme, die sich im kritischen Pfad von Geschäftsprozessen befinden, sind keine zu entfernenden Schattenprogramme, sondern undokumentierte Produktionsanwendungen, die einer Governance bedürfen. Registrieren Sie sie, weisen Sie ihnen Verantwortliche zu, bewerten Sie ihren Sicherheitsstatus und behandeln Sie sie mit denselben Governance-Regeln wie jede andere Produktionsanwendung.

Amnestie für Selbstoffenlegung. Ein Governance-Programm, das sichere Kanäle für Geschäftsbereiche schafft, um informell entwickelte Anwendungen offenzulegen, deckt Schattensoftware schneller auf als jede technische Ermittlungsmethode. Die Zusicherung, dass die Offenlegung zu Governance-Unterstützung, Hilfe bei der Dokumentation, Sicherheitsüberprüfung und formeller Registrierung führt, anstatt zu disziplinarischen Maßnahmen, beseitigt den Anreiz zur Verschleierung.

Prävention durch Prozesse. Die Hauptursache für die Anhäufung von Schattenanwendungen liegt in der mangelnden Governance: Der offizielle Prozess zur Anforderung neuer Anwendungsentwicklungen ist langsamer als es die Geschäftsanforderungen erfordern. Durch die Reduzierung dieser Reibungsverluste, eine schlanke und agile Entwicklungs-Governance, die Integration von IT-Governance-Unterstützung in die Geschäftsbereiche und eine optimierte Genehmigung für interne Tools mit geringem Risiko lässt sich die Entstehungsrate neuer Schattenanwendungen verringern, ohne dass eine kontinuierliche technische Überprüfung notwendig ist.

Der Lagerbestand, den Sie zu haben glauben, ist nicht der Lagerbestand, den Sie tatsächlich haben.

Die Diskrepanz zwischen dem von der IT verwalteten Anwendungsbestand und der tatsächlich in Unternehmensumgebungen eingesetzten Anwendungssoftware ist erheblich. In großen Organisationen mit jahrzehntelanger Anwendungsentwicklung kann die Lücke zwischen dokumentierter und tatsächlicher Software fast 30 Prozent aller Programme ausmachen. Zu diesen undokumentierten 30 Prozent gehören Programme, die sensible Daten verarbeiten, regulatorische Anforderungen erfüllen, geschäftskritische Prozesse steuern und Sicherheitslücken aufweisen, die bisher unbemerkt blieben.

Tools zur Erkennung von Schatten-IT im SaaS-Bereich adressieren die Cloud-Ebene dieses Problems gut. Das Problem der Schatten-IT auf Codeebene – also die benutzerdefinierten Programme, im Verborgenen laufenden Hilfsprogramme, informellen Datenpipelines und undokumentierten Batch-Jobs, die in veralteten Unternehmensumgebungen allgegenwärtig sind – erfordert einen anderen Ansatz: die strukturelle Analyse der tatsächlichen Softwareartefakte anstatt der Überwachung des Netzwerkverkehrs. Das Ergebnis dieser Analyse ist oft überraschend umfassend. Unternehmen, die diese Arbeit durchführen, stellen immer wieder fest, dass das, was sie für produktiv hielten, und das, was tatsächlich läuft, sich deutlich unterscheiden. Diese Diskrepanz zu schließen, ist die Grundlage jedes Governance-, Sicherheits-, BCP- und Modernisierungsprogramms, das darauf basiert, zu wissen, was das Unternehmen tatsächlich betreibt.