Warum SBOM auf dem Mainframe viel mehr mit Anwendungsverständnis und Modernisierung zu tun hat als nur mit Security
Ein Beipackzettel für ein COBOL-Programm klingt zunächst etwas gewöhnungsbedürftig. Wenn man die Idee jedoch weiterdenkt, ist sie gar nicht so abwegig. Auf einem solchen Beipackzettel könnte beispielsweise stehen, dass eine Anwendung COBOL, einige Assembler-Routinen, gemeinsam verwendete Copybooks, CICS, JCL, Db2, VSAM und verschiedene Schnittstellen enthält. Hinzu käme vielleicht der Hinweis, dass einzelne Abhängigkeiten bereits seit mehr als 30 Jahren bestehen und deren ursprüngliche Entwickler längst nicht mehr im Unternehmen arbeiten.
Im Grunde beschreibt genau das die Idee hinter einer Software Bill of Materials, kurz SBOM. Sie soll nachvollziehbar machen, aus welchen Bestandteilen eine Software besteht, welche Abhängigkeiten zwischen diesen Bestandteilen vorhanden sind und welche Versionen tatsächlich verwendet werden. Die amerikanische NTIA beschreibt eine SBOM treffend als eine Art verschachteltes Inventar beziehungsweise als Zutatenliste für Software. Weitere Informationen zu diesem grundlegenden Verständnis finden sich unter https://www.ntia.gov/page/software-bill-materials.
Das Konzept selbst ist nicht neu. Interessant wird es jedoch dadurch, dass die Diskussion inzwischen auch dort angekommen ist, wo Software über Jahrzehnte hinweg nach ganz anderen Prinzipien entwickelt, gebaut und betrieben wurde als in modernen Cloud-, Java- oder Open-Source-Umgebungen: auf dem Mainframe.
Das Open Mainframe Project hat deshalb am 11. August 2026 eine eigene SBOM Working Group für z/OS-Anwendungen angekündigt. Im Mittelpunkt stehen zunächst COBOL, PL/I, HLASM sowie Anwendungen, die aus unterschiedlichen Sprachen und Technologien zusammengesetzt sind. Die Initiative ist unter https://openmainframeproject.org/announcements/17204/ beschrieben.
Auf den ersten Blick könnte man das als weiteres Security-Thema einordnen. Bei genauerer Betrachtung führt die Beschäftigung mit einer SBOM auf dem Mainframe jedoch sehr schnell zu einer wesentlich grundsätzlicheren Frage: Wissen Unternehmen heute wirklich noch vollständig, aus welchen Bestandteilen ihre produktiven Anwendungen bestehen und wie diese Bestandteile miteinander zusammenhängen?
Bei moderner Software ist die Zutatenliste häufig schon vorhanden
In vielen aktuellen Entwicklungsumgebungen hinterlassen Anwendungen vergleichsweise deutliche Spuren. Package Manager verwalten Abhängigkeiten, Build-Systeme kennen verwendete Komponenten, Sourcecode liegt versioniert in Repositories und CI/CD-Pipelines dokumentieren große Teile des Weges vom Quellcode bis zum produktiven Artefakt. Auch Versionsstände und verwendete Bibliotheken lassen sich deshalb häufig relativ zuverlässig nachvollziehen.
Standards wie SPDX oder CycloneDX wurden wesentlich durch solche Entwicklungsmodelle geprägt. SPDX ist inzwischen als ISO/IEC 5962 standardisiert und stellt Strukturen zur Verfügung, mit denen Informationen über Softwarekomponenten, Lizenzen, Beziehungen und weitere Metadaten ausgetauscht werden können. Die aktuelle Spezifikation und weitere Hintergrundinformationen sind unter https://spdx.dev/use/specifications/ zu finden.
CycloneDX verfolgt einen ähnlichen Ansatz und beschreibt die SBOM als maschinenlesbares Inventar von Softwarekomponenten, Diensten und deren Abhängigkeiten. Eine solche Beschreibung kann nicht nur für die Suche nach bekannten Sicherheitsproblemen verwendet werden, sondern beispielsweise auch bei der Bewertung veralteter Komponenten oder von Lizenzabhängigkeiten helfen. Eine Übersicht bietet https://cyclonedx.org/capabilities/sbom/.
Diese Verfahren funktionieren besonders gut, wenn eine Anwendung nach einem Entwicklungsmodell entstanden ist, bei dem ein großer Teil ihrer Bestandteile und Abhängigkeiten automatisch aus Build- und Repository-Informationen rekonstruiert werden kann. Genau an diesem Punkt unterscheidet sich die Realität vieler Mainframe-Anwendungen deutlich.
Eine Mainframe-Anwendung besteht selten nur aus ihrem Sourcecode
Eine über Jahrzehnte gewachsene Mainframe-Anwendung lässt sich häufig nicht einfach durch das Öffnen eines Sourcecode-Repositories verstehen. Vielleicht besteht sie aus mehreren hundert COBOL-Programmen, verwendet gemeinsam genutzte Copybooks und greift an bestimmten Stellen auf PL/I- oder Assembler-Routinen zurück. Die Batch-Verarbeitung wird über JCL und einen Scheduler gesteuert, während Online-Transaktionen in CICS laufen. Daten liegen gleichzeitig in Db2 und VSAM, Nachrichten werden möglicherweise über MQ ausgetauscht und einige Prozesse verwenden Dateien oder Schnittstellen, deren Ursprung weit in die Geschichte des Systems zurückreicht.
Damit entsteht eine Anwendungslandschaft, deren tatsächliches Verhalten sich nicht allein aus einzelnen Programmen ableiten lässt. Der Sourcecode ist ohne Zweifel eine wichtige Informationsquelle, aber er beschreibt eben nur einen Teil des Gesamtsystems.
Hinzu kommt, dass der vorhandene Sourcecode nicht zwangsläufig vollständig beschreibt, was in Produktion tatsächlich ausgeführt wird. Programme wurden im Laufe der Jahre geändert, kompiliert, gelinkt und in unterschiedliche Load Libraries übertragen. Copybooks haben sich weiterentwickelt, einzelne Komponenten wurden möglicherweise seit Jahren nicht mehr verändert und andere werden gleichzeitig von mehreren Anwendungen verwendet. Batch-Jobs starten Programme, die ihrerseits weitere Module nachladen, während CICS-Anwendungen auf Datenbestände oder Programme zugreifen, deren Zusammenhang sich aus dem Programmnamen allein kaum erkennen lässt.
Wer sich länger mit gewachsenen Anwendungen beschäftigt, kennt deshalb Aussagen wie: „Das müsste eigentlich noch irgendwo verwendet werden.“ Solche Aussagen wirken manchmal fast beiläufig, sind in einer produktiven Umgebung aber ein deutlicher Hinweis darauf, dass technisches Wissen nicht vollständig dokumentiert ist, sondern sich über Sourcecode, Betriebswissen, historische Dokumentationen und die Erfahrung einzelner Mitarbeiter verteilt.
Auf dem Mainframe muss eine SBOM deshalb weiter gedacht werden
Gerade deshalb ist die Initiative des Open Mainframe Project interessant. Es geht dort nicht einfach darum, COBOL-Programme in einen bereits vorhandenen SBOM-Standard einzutragen. Die Working Group untersucht vielmehr, wie gut etablierte Ansätze wie SPDX und CycloneDX überhaupt auf typische Mainframe-Umgebungen übertragbar sind und welche zusätzlichen Attribute und Metadaten für z/OS-Anwendungen benötigt werden.
Besonders bemerkenswert ist, dass dabei nicht nur der Sourcecode betrachtet werden soll. Die Initiative bezieht ausdrücklich Source, Build, Deployment und Runtime ein und berücksichtigt auch inkrementelle Build- und Deployment-Verfahren, wie sie in größeren Mainframe-Umgebungen über viele Jahre entstanden sind. Genau dieser Ansatz wird in der Beschreibung der Working Group unter https://openmainframeproject.org/announcements/17204/ erläutert.
Damit verändert sich die Perspektive erheblich. Die entscheidende Frage lautet nicht mehr nur, welche Softwarekomponenten grundsätzlich vorhanden sind, sondern welche dieser Komponenten gemeinsam die Anwendung bilden, die im produktiven Betrieb tatsächlich Geschäftsprozesse verarbeitet.
Genau diese Unterscheidung ist für Legacy-Systeme von erheblicher Bedeutung.
Security ist ein wichtiger Treiber, aber Transparenz ist mindestens genauso wertvoll
Der ursprüngliche Nutzen einer SBOM liegt natürlich stark im Bereich der Software Supply Chain und der Security. Wenn eine Schwachstelle in einer bestimmten Bibliothek oder Komponente bekannt wird, möchte ein Unternehmen möglichst schnell feststellen können, ob und wo diese Komponente eingesetzt wird. Ohne ein strukturiertes Inventar kann daraus eine aufwendige Suche über viele Anwendungen und Systeme hinweg werden.
Die amerikanische Cybersecurity and Infrastructure Security Agency CISA hat ihre Empfehlungen zu den Mindestelementen einer SBOM 2025 aktualisiert und hebt dabei insbesondere die Bedeutung einer verbesserten Transparenz innerhalb der Software Supply Chain hervor. Das entsprechende Dokument ist unter https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf verfügbar.
Auf einem Mainframe entsteht durch eine systematische Erfassung der Anwendungskomponenten allerdings ein zusätzlicher Nutzen, der weit über das ursprüngliche Security-Szenario hinausgeht. Sobald man versucht, belastbar zu dokumentieren, welche Bestandteile zu einer Anwendung gehören, beginnt zwangsläufig eine umfassendere Analyse der Anwendungslandschaft.
Dann muss beispielsweise geklärt werden, welche Programme tatsächlich aufgerufen werden, welche Copybooks welche Programme beeinflussen, welche Load Modules produktiv verwendet werden oder welche Batch-Jobs gemeinsam einen fachlichen Ablauf bilden. Ebenso interessant ist die Frage, welche Dateien, Datenbanken und Queues ein Programm verwendet und welche Komponenten von mehreren Anwendungen gemeinsam genutzt werden.
Gerade bei langjährig gewachsenen Systemen kann dabei auch sichtbar werden, dass bestimmte Programme oder Routinen zwar seit vielen Jahren nicht mehr verändert wurden, aber weiterhin eine wichtige Funktion erfüllen. Umgekehrt können Bestandteile identifiziert werden, die zwar noch im Repository oder in einer Library vorhanden sind, im tatsächlichen Betrieb aber keine Rolle mehr spielen.
Diese Erkenntnisse sind nicht nur für Security interessant. Sie beeinflussen unmittelbar die Wartbarkeit einer Anwendung und die Risiken jeder geplanten Veränderung.
Sourcecode besitzen bedeutet noch nicht, eine Anwendung zu verstehen
In Modernisierungsprojekten entsteht schnell der Eindruck, dass eine Anwendung im Wesentlichen verstanden werden könne, sobald der vollständige Sourcecode zur Verfügung steht. Technisch ist das nicht völlig falsch, für eine belastbare Bewertung reicht es allerdings häufig nicht aus.
Ein einzelnes COBOL-Programm kann durchaus gut lesbar und nachvollziehbar sein. Die eigentliche Komplexität vieler Legacy-Systeme entsteht jedoch durch die Beziehungen zwischen den Programmen, Datenstrukturen, Batch-Abläufen, Transaktionen und Subsystemen.
Ob ein Programm beispielsweise 8.000 oder 15.000 Zeilen COBOL enthält, ist für eine Modernisierungsentscheidung deshalb nur begrenzt aussagekräftig. Wesentlich interessanter wäre zu wissen, ob dieses Programm von zwölf Batch-Jobs und drei CICS-Transaktionen verwendet wird, auf mehrere VSAM-Dateien und Db2-Tabellen zugreift, vier gemeinsam genutzte Copybooks verwendet und zusätzlich eine Assembler-Routine aufruft, die gleichzeitig von mehreren anderen Anwendungen benötigt wird.
Erst diese Zusammenhänge zeigen, welche Auswirkungen eine Veränderung tatsächlich haben könnte. Aus einer reinen Sourcecodeanalyse wird damit eine Anwendungsanalyse, und genau diese Unterscheidung entscheidet häufig darüber, ob ein Modernisierungsvorhaben realistisch geplant werden kann.
Eine SBOM kann deshalb auch bei Modernisierung helfen
Eine SBOM wird selbstverständlich keine vollständige Anwendungsdokumentation ersetzen. Sie kann jedoch einen strukturierten Teil des Wissens bereitstellen, das für Wartung und Modernisierung benötigt wird.
Soll beispielsweise eine Anwendung aufgeteilt, ein bestimmter Geschäftsprozess aus CICS herausgelöst oder ein bestehender Batch-Prozess durch einen neuen Service ergänzt werden, hilft eine belastbare Übersicht über die beteiligten Komponenten dabei, den tatsächlichen Umfang der Veränderung frühzeitig zu erkennen. Ebenso lässt sich besser beurteilen, welche abhängigen Komponenten berücksichtigt und welche Bereiche anschließend getestet werden müssen.
Auch bei der Stilllegung alter Anwendungen kann eine solche Transparenz ausgesprochen wertvoll sein. Ein Programm oder eine Datei lässt sich nicht allein deshalb gefahrlos entfernen, weil seit Jahren keine Änderung mehr dokumentiert wurde. Entscheidend ist vielmehr, ob andere Programme, Jobs oder Anwendungen weiterhin darauf zugreifen.
Damit verändert sich die Bedeutung einer SBOM. Sie beantwortet dann nicht nur die Frage, welche Komponenten vorhanden sind, sondern liefert gleichzeitig Hinweise darauf, welche Konsequenzen Änderungen an diesen Komponenten haben könnten.
Wo künstliche Intelligenz helfen kann
An diesem Punkt kommt zwangsläufig auch die aktuelle Diskussion über künstliche Intelligenz ins Spiel. Generative KI wird im Mainframe-Umfeld häufig mit Code-Erklärung oder Code-Konvertierung verbunden. Für das tatsächliche Anwendungsverständnis könnte ihr Nutzen allerdings bereits wesentlich früher beginnen.
Werkzeuge können heute Sourcecode untersuchen, Programmlogik zusammenfassen, Beziehungen zwischen Komponenten identifizieren und vorhandene technische Informationen miteinander in Verbindung bringen. IBM beschreibt beispielsweise für watsonx Code Assistant for Z Funktionen zum Verständnis von Anwendungen und zur Analyse von Zusammenhängen innerhalb einer Anwendungslandschaft. Die Plattform unterstützt dabei inzwischen unterschiedliche Mainframe-Sprachen und Artefakte. Einen Überblick stellt IBM unter https://www.ibm.com/docs/en/watsonx/watsonx-code-assistant-4z/2.x?topic=welcome-overview-watsonx-code-assistant-z bereit.
Daneben existieren seit vielen Jahren klassische Werkzeuge für die statische Anwendungsanalyse. IBM Application Discovery and Delivery Intelligence verfolgt beispielsweise den Ansatz, Quellcode und Anwendungsstrukturen zu analysieren und Beziehungen zwischen Programmen sichtbar zu machen. IBM ordnet solche Analyseverfahren inzwischen auch in weitergehende KI-gestützte Modernisierungsansätze ein, wie unter https://www.ibm.com/think/architectures/patterns/genai-code-generation-z beschrieben wird.
Gerade die Kombination dieser Verfahren erscheint interessant. Eine klassische Analyse kann sehr präzise feststellen, welches Programm welches Copybook verwendet oder welche Datei angesprochen wird. Generative KI kann anschließend dabei helfen, die große Menge technischer Informationen zu strukturieren, Zusammenhänge verständlich zu erklären oder Hypothesen darüber zu entwickeln, welche Bestandteile fachlich zusammengehören könnten.
Dabei sollte allerdings eine wichtige Grenze nicht übersehen werden. Ein Sprachmodell kann beispielsweise erkennen, dass in einem COBOL-Programm ein bestimmtes Unterprogramm aufgerufen wird. Ob in der produktiven Umgebung tatsächlich das erwartete Load Module aus einer bestimmten Library geladen wird, ist jedoch eine andere Frage. Ebenso lässt sich aus einem Programm erkennen, dass auf eine VSAM-Datei zugegriffen wird. Wie häufig dieser Zugriff tatsächlich erfolgt und welche Bedeutung er für das Laufzeitverhalten hat, lässt sich allein aus dem Sourcecode jedoch nicht zuverlässig bestimmen.
Genau deshalb bleiben technische Fakten aus Sourcecode, Build-Prozessen, CICS-Definitionen, JCL, Scheduler-Informationen, Datenbank-Metadaten, SMF-Daten und anderen Betriebsinformationen unverzichtbar. KI kann solche Informationen zusammenführen, erklären und bei ihrer Interpretation helfen, sollte fehlende Fakten aber nicht durch plausibel klingende Annahmen ersetzen.
Vielleicht ist die SBOM nur ein Baustein eines größeren Anwendungsmodells
Besonders spannend wird das Thema, wenn man die SBOM nicht als statisches Dokument betrachtet, das einmal erzeugt und anschließend irgendwo für eine Prüfung abgelegt wird. Denkbar wäre vielmehr, dass solche Informationen künftig Bestandteil eines kontinuierlich gepflegten Anwendungsmodells werden.
Ein solches Modell könnte Sourcecode, Builds, Deployments und Runtime-Informationen miteinander verbinden und damit erheblich mehr leisten als eine reine Komponentenliste. Es könnte beispielsweise nicht nur dokumentieren, dass ein bestimmtes COBOL-Programm existiert, sondern gleichzeitig zeigen, von welchen Jobs und Transaktionen es verwendet wird, auf welche Datenbestände es zugreift und welche weiteren Programme davon abhängig sind.
Wenn solche Informationen zusätzlich mit Betriebsdaten, Security-Informationen und Analysewerkzeugen verbunden werden, entsteht eine Wissensbasis, die sowohl für Betrieb und Wartung als auch für zukünftige Modernisierungsvorhaben wertvoll sein kann.
Dass das Open Mainframe Project seine aktuelle Initiative ausdrücklich über den Sourcecode hinaus auf Build, Deployment und Runtime ausrichtet, passt genau zu diesem Gedanken. Nach Angaben des Projektes sollen die entwickelten Ansätze zudem anhand praktischer Erfahrungen aus mehreren Mainframe-Unternehmen überprüft werden. Die entsprechenden Ziele sind ebenfalls unter https://openmainframeproject.org/announcements/17204/ beschrieben.
Damit geht es offensichtlich nicht einfach darum, ein Konzept aus modernen Entwicklungsumgebungen auf COBOL zu übertragen. Es geht vielmehr darum, ein Modell zu entwickeln, das berücksichtigt, wie Mainframe-Anwendungen tatsächlich entstehen, über Jahrzehnte verändert werden und im täglichen Betrieb zusammenspielen.
Vor einer Modernisierung sollte deshalb zuerst das Verständnis stehen
Modernisierungsdiskussionen beginnen häufig mit der Zieltechnologie. Dann wird darüber gesprochen, ob Anwendungen zukünftig in Java umgesetzt, in die Cloud verlagert, auf Linux betrieben, in Services aufgeteilt oder vielleicht mithilfe generativer KI automatisch transformiert werden sollen.
Diese Fragen sind wichtig, setzen aber bereits voraus, dass ausreichend verstanden wurde, was eigentlich modernisiert werden soll.
Bei einer über Jahrzehnte gewachsenen Anwendung muss zunächst geklärt werden, welche Komponenten dazugehören, welche Abhängigkeiten bestehen und welche Geschäftsprozesse tatsächlich abgebildet werden. Ebenso wichtig ist die Frage, welche Bestandteile technisch kritisch sind, welche Komponenten gemeinsam verwendet werden und welche Teile der Anwendung möglicherweise nur aufgrund historischer Entscheidungen so aufgebaut sind, wie sie heute vorgefunden werden.
Genau hier liegt aus meiner Sicht eine der wichtigsten Schlussfolgerungen aus der aktuellen SBOM-Diskussion: Analyse ist kein vorbereitender Nebenschritt einer Modernisierung, sondern einer ihrer zentralen Bausteine.
Dabei ist zunächst zweitrangig, ob diese Analyse vollständig mit klassischen Werkzeugen erfolgt oder durch künstliche Intelligenz unterstützt wird. In vielen Fällen dürfte eine Kombination sinnvoll sein. Statische Analyse liefert überprüfbare technische Beziehungen, Betriebsdaten zeigen das tatsächliche Laufzeitverhalten und generative KI kann dabei helfen, große Informationsmengen schneller zu strukturieren, Code und Zusammenhänge verständlicher zu machen oder bislang übersehene Fragen sichtbar zu machen.
Entscheidend ist deshalb weniger die Frage, ob KI eingesetzt wird, sondern vielmehr, ob eine belastbare Analyse stattfindet und ob ihre Ergebnisse anschließend fachlich und technisch überprüft werden.
Gerade bei Legacy-Systemen liegt darin ein erheblicher Wert. Wer eine Anwendung nur anhand ihres Alters, der verwendeten Programmiersprache oder einer groben Anzahl von Codezeilen bewertet, weiß noch erstaunlich wenig über ihren tatsächlichen Modernisierungsaufwand. Erst wenn Programme, Daten, Schnittstellen, Jobs, Transaktionen und Laufzeitverhalten gemeinsam betrachtet werden, entsteht ein Bild, auf dessen Grundlage vernünftige Entscheidungen getroffen werden können.
Vielleicht braucht COBOL also tatsächlich einen Beipackzettel
Der Vergleich mit dem Beipackzettel ist deshalb vielleicht weniger scherzhaft, als er am Anfang erscheint. Nicht weil COBOL gefährlich wäre und auch nicht, weil jahrzehntealte Mainframe-Anwendungen automatisch ersetzt werden müssten. Der eigentliche Nutzen liegt in der Transparenz.
Eine SBOM kann einen Teil dieser Transparenz liefern, klassische Analysewerkzeuge können sie vertiefen und KI kann dabei helfen, große und komplexe Informationsbestände schneller zu erschließen. Keines dieser Werkzeuge ersetzt jedoch die fachliche und technische Bewertung durch Menschen, die verstehen, welche Bedeutung die gefundenen Zusammenhänge für den tatsächlichen Betrieb und für das Unternehmen besitzen.
Gerade deshalb sollte die Diskussion über SBOM auf dem Mainframe nicht auf die Frage reduziert werden, wie man eine Zutatenliste für COBOL erzeugt. Dahinter steckt eine wesentlich größere Chance: gewachsene Anwendungen wieder nachvollziehbarer zu machen und damit eine belastbare Grundlage für Wartung, Security und Modernisierung zu schaffen.
Am Ende bleibt damit eine Erkenntnis, die ausgesprochen unspektakulär klingt und trotzdem bei vielen Modernisierungsvorhaben entscheidend sein dürfte: Bevor ein System verändert wird, sollte möglichst genau verstanden werden, wie es heute funktioniert und wovon es abhängt. Ob dieses Verständnis mit klassischen Analysewerkzeugen, mit KI-Unterstützung oder mit einer Kombination aus beidem entsteht, ist dabei weniger wichtig als die Qualität der Analyse selbst.
Denn eine Anwendung ist nicht deshalb schwierig zu modernisieren, weil sie alt ist. Schwierig wird es vor allem dann, wenn niemand mehr genau weiß, wie sie wirklich funktioniert.
Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet
