Software bildet heute das Fundament zahlreicher Geschäftsmodelle, industrieller Prozesse und öffentlicher Verwaltungsstrukturen. Sie entsteht in komplexen Ökosystemen aus Quellcode, Daten, Schnittstellen und Architekturen – und gewinnt dadurch rechtliche Relevanz weit über klassische Urheberrechtsfragen hinaus. Manipulationsvorwürfe, Haftungsfragen bei Sicherheitslücken, Streitigkeiten um Nutzungsrechte oder auch die genaue Rekonstruktion technischer Abläufe führen zunehmend dazu, dass Quellcode und Softwareartefakte vor Gericht als Beweismittel dienen. In diesem Artikel wird mit speziellem Fokus auf die Programmiersprache Java die Identifizierbarkeit und Integrität von Softwareständen, dokumentationsrelevante Artefakte vorgestellt und Werkzeuge zur forensischen Untersuchung beschrieben. Der Einsatz von KI in der Software-Entwicklung führt darüber hinaus zu neuen Verantwortlichkeiten, wachsenden Gefahren und belegt die Notwendigkeit von qualitativ zuverlässiger und überprüfbarer Software.
Die Algorithmisierung des Rechts
Software ist längst nicht mehr nur ein Werkzeug zum Entwickeln von Anwendungen. In unserer modernen Industriegesellschaft stellt sie vielmehr das Rückgrat von Geschäftsmodellen, Produktionsprozessen, der öffentlichen Verwaltung, nahezu allen digitalen Prozessen dar [1]. Ihre Bedeutung geht weit über die reine, fast schon historische, Prozessoptimierung hinaus. Software wird zum Handelsprodukt, zum Geschäftsgeheimnis, zum Unterscheidungsmerkmal, sie weckt Begehrlichkeiten, schafft Möglichkeiten unterliegt rechtlichen sowie organisatorischen Rahmenbedingungen und schafft somit Werte jeglicher Art[2]. Dabei ist Software längst nicht mehr rein auf den Quellcode beschränkt – sie manifestiert sich vielmehr als komplexes Zusammenspiel aus Algorithmen, Datenbanken, Benutzeroberflächen, Schnittstellen oder Hardware[3]. Während früher häufig der Quellcode als „Maß der Dinge“ betrachtet wurde, ändert sich seine Rolle, wenn mehr und mehr Code-Generatoren eingesetzt werden. Beispielsweise ist das Schreiben von Datenzugriffsklassen, Unit-Tests oder auch die Entwicklung von Nutzeroberflächen mittlerweile immer weniger Tipparbeit von Entwicklern, so dass auch der juristische Begriff der „Schöpfungshöhe“ immer weniger am reinen Quellcode verankert werden kann[4].
Konkrete Anwendungsfälle zeigen die Vielschichtigkeit und Relevanz von Software gerade in juristischen Kontexten auf: beispielsweise kann in der Automobilbranche die Steuerungssoftware eines Fahrzeugs nicht nur Motorfunktionen beeinflussen, sondern auch gezielt Abgaswerte manipulieren – wie zahlreiche Gerichtsverfahren der letzten Jahre verdeutlich haben[5][6]. In der Finanzwelt regeln komplexe Algorithmen die Abwicklung von Börsengeschäften – Fehler oder Manipulationen dieser Systeme können weitreichende rechtliche und wirtschaftliche Folgen haben[7]. In der öffentlichen Verwaltung steuern Softwarelösungen die Vergabe von Leistungen, die Durchführung von Wahlen und werden regelmäßig Ziel verschiedenster Cyber-Attacken[8]. Fehlfunktionen oder die Manipulation digitaler Systeme werden mittlerweile als eines der größten Risiken für Privatpersonen, Unternehmen, die öffentliche Verwaltung, ja sogar für die Gesellschaft an sich angesehen.
Mit dieser fortschreitenden Digitalisierung dringt Software zwangsläufig auch in die Gerichtssäle vor. Der Quellcode ist hierbei häufig nur eine von vielen technischen Grundlagen, denn im Zentrum stehen meist Fragen nach der Funktionsweise, der Interaktion zwischen Systemen, der Nachvollziehbarkeit von Entscheidungen, der Sicherheit oder auch Fragen nach den Rechten an den eingesetzten Lösungen[9]. Dies können Urheberrechtsstreitigkeiten, Nutzungsrechte, Haftungsfragen nach einem Cyberangriff, Manipulationsvorwürfe – wie etwa die Umgehung von Emissionsvorschriften – oder auch Datenschutzverletzungen durch fehlerhafte Programme sein. In allen Fällen gilt: Software ist längst ein zentrales und oftmals entscheidendes Beweismittel im juristischen Diskurs. In zahlreichen Verfahren werden IT-Sachverständige aufgefordert, nicht nur den reinen Quellcode zu analysieren, sondern das gesamte Ökosystem einer Softwarelösung einzuordnen. Dies umfasst dann die Architektur, die eingesetzten Bibliotheken, die Lieferkette und Dokumentation, Konfigurationsdateien, Daten und Datenbanken, sowie das Zusammenspiel mit externen Systemen. Denn nur so lassen sich die tatsächlichen Sachverhalte rechtssicher rekonstruieren und bewerten[10].
Die Programmiersprache Java nimmt hierbei eine Sonderrolle ein, die nachfolgend auch in das Zentrum einer detaillierten Betrachtung gestellt wird. Durch ihre weite Verbreitung in Unternehmensanwendungen, Finanzsystemen, der Kritischen Infrastruktur und auch in Form von Android-Anwendungen auf zahllosen Smartphones, steht sie überproportional oft im Fokus forensischer Untersuchungen. Doch wie lässt sich Code „verhören“? Wie können abstrakte Klassen und Lambda-Ausdrücke in eine Sprache übersetzt werden, auf deren Basis ein Richter ein Urteil fällen kann? Was, wenn auch noch KI in all ihren Ausprägungen mit ins Spiel kommt?
Um diese Fragestellungen zu beantworten, wird in diesem Artikel neben den allgemeinen rechtlichen Rahmenbedingungen vor allem die Methodik im Kontext von Java-Anwendungen und aus Sicht von Java-Entwicklern beleuchtet, um sichere, nachvollziehbare und unangreifbare Quellcodes zu erzeugen.
Rechtliche Rahmenbedingungen
Quelltext ist nach deutschem und europäischem Recht grundsätzlich als Werk im Sinne des Urheberrechts geschützt, sofern er eine gewisse Schöpfungshöhe erreicht[11]. Das bedeutet, dass die Urheberrechte am Quelltext zunächst beim Entwickler liegen, aber aufgrund von Verträgen oder Anstellungsverhältnissen auch auf Unternehmen übergehen können. Daraus ergeben sich dann wiederum ausschließliche Rechte, wie bspw. das Vervielfältigungs-, Verbreitungs- und Bearbeitungsrecht, die es dem Rechteinhaber ermöglichen, die Nutzung und Weitergabe des Quellcodes zu kontrollieren und ggf. juristisch durchzusetzen[12]. Erschreckend oft kommt es zu Klagen, in denen eine Partei der anderen vorwirft, Quellcodes entweder gestohlen oder nachgebaut zu haben oder unrechtmäßig genutzte Komponenten zu verwenden. Die Einräumung von Nutzungsrechten wiederum zieht Garantien, Gewährleistung, die Pflicht zur Fehlerbehebung u.v.m. nach sich, die Hersteller regelmäßig in Bedrängnis bringen können.
Während Entwickler früher einen Großteil der Quellcode-Produktion selbst vorgenommen haben – und auch die Rechtsprechung teilweise noch aus dieser Zeit kommt – nehmen heutzutage moderne Werkzeuge, wie Code-Generatoren einen gewissen Teil der Tipp-Arbeit ab. Spätestens seit dem Aufkommen von KI und KI-generierten Quelltexten nimmt jedoch ein zusätzlicher Aspekt immer mehr Raum ein: KI-generierte Werke sind zunächst rechtefrei, d.h. der Entwickler besitzt im ersten Schritt nicht einmal das Urheberrecht, da das KI-System selbst keine natürliche Person ist und von ihm erzeugter Code somit auch nicht geschützt werden kann[13]. Allerdings muss man an dieser Stelle berücksichtigen, dass der Quellcode typischerweise in komplexe Systemarchitekturen eingebettet ist und dessen Erstellung auch maßgeblich von Entwicklern gesteuert wird. Dieser kreative Prozess wiederum stellt eine gewisse Schöpfungshöhe dar. Viele Juristen argumentieren, dass eben diese Einbettung oder auch das Prompting durchaus Schutz erzeugen können. Aber genau daran arbeiten sich derzeit zahlreiche Verfahren ab, um die entstehende Unsicherheit bei der Durchsetzbarkeit von Ansprüchen oder der Verwertbarkeit solcher Quelltexte zu regeln.
Identifizierbarkeit, Sicherung und Integrität
Bevor eine Analyse beginnen kann, muss die prozessuale Integrität des Beweismittels sichergestellt werden. Im Gegensatz zu physischen Beweisstücken ist die digitale Information jedoch flüchtig und leicht manipulierbar. Für einen Sachverständigen beginnt die Arbeit daher nicht beim Lesen des Codes, sondern deutlich vorher – nämlich bei der Akquise des Quellcodes zum streitgegenständlichen Zeitraum.
Berücksichtigt man nunmehr, dass teilweise mehrere Jahre zwischen dem Streitauslöser und einer gerichtlichen Verhandlung vergehen, stellt dies in der Praxis ein durchaus schwieriges Unterfangen dar. In Zivil- oder Strafprozessen muss bspw. zweifelsfrei nachgewiesen werden, dass der untersuchte Quellcode exakt dem Stand zum Zeitpunkt des schädigenden Ereignisses entspricht. Ist dies nicht möglich, entfällt häufig ein zentraler Grundpfeiler der Argumentation.
Dank moderner Werkzeuge, wie bspw. Git[14], lassen sich heutzutage Quelltexte zu beliebigen historischen Ständen rekonstruieren. Im Fall des Falles ein erheblicher Vorteil. Verwendet man zusätzlich noch kryptografische Hash-Funktionen (wie bspw. SHA-256), so lässt sich der Stand im Repository mit einem „digitalen Fingerabdruck“ versehen und somit auch belegen, dass nachträgliche Änderungen oder Manipulationen sofort auffallen würden.
Software ist jedoch nicht nur der reine Quellcode – aus dem hier genannten Aspekt empfiehlt es sich bspw. auch, Dokumentation, Datenbank-Dumps, Architekturdokumente, Testfälle und Testergebnisse regelmäßig im Repository abzulegen, damit diese zusammen mit den Quellcodes einen konsistenten und vollständigen Stand ergeben.
Auf diesem Weg kann eine vollständige, eindeutig identifizierbare Software jederzeit nachträglich bereitgestellt werden. Entwickler sollten daher jede Auslieferung einer Version via Tag und Hash-Wert dokumentieren und den dazu passenden Daten- und Dokumentationsstand mit einchecken.
Quellcode-Änderungen
Das Thema Git spielt noch aus einem anderen Aspekt eine wichtige Rolle: immer häufiger wird Unternehmen oder einzelnen Entwicklern unterstellt, Quelltexte z.B. vom vorherigen Arbeitgeber unrechtmäßig mitgenommen und in die Produkte eines neuen Arbeitgebers integriert zu haben. Hierbei handelt es sich in den seltensten Fällen um 1:1 Kopien. Sind jedoch große Teile von Quelltexten ähnlich – das gilt sogar unabhängig von der eingesetzten Programmiersprache – so kann der Verdacht entstehen, ein Entwickler hätte bspw. C#-Quellcode kopiert und dann mal eben in Java nachgebaut und in die Software des neuen Arbeitgebers integriert.
In solchen Fällen ist es extrem hilfreich, wenn die Git-Historie zu Rate gezogen werden kann. Dadurch kann die Entstehung und Genese von Quellcodes häufig sehr gut dokumentiert und nachvollzogen werden. Würden bspw. in einem Commit unübliche 10.000 Zeilen eingecheckt, könnte dies ein Indikator für gestohlene Quellcodes sein. Wird jedoch über die Git-Historie belegt und dokumentiert, dass sich der Quellcode in „handelsüblichen“ Mengen weiterentwickelt hat, sind Umbau- und Rückbaumaßnahmen im Git erkennbar, so lässt sich daraus eine gute Argumentation für die eigenständige und originäre Erstellung von Quelltexten entwickeln. Hierbei müssen natürlich keine Bedenken bei automatisch generierten Quellcodes, wie bspw. Testfällen oder auch Datenzugriffsklassen entstehen, da Sachverständige hier sehr wohl unterscheiden und derartige Strukturen auch nur eine sehr geringe Schöpfungshöhe aufweisen. Das Projekt „Gource“ (https://gource.io)[15] hat die Visualisierung von Quellcode-Veränderungen zu einer regelrechten Kunstform erweitert, indem die Git-Historie als Film visualisiert wird.
Dies bedeutet aber auch, dass Entwickler regelmäßig ihre Ergebnisse einchecken sollten. Kommentare, Erläuterungen im Quellcode sind ebenfalls hilfreich.
Analyse-Methodik – vom Bytecode zur Business-Logik
Die Analyse von Java-Anwendungen unterscheidet sich grundlegend von der Untersuchung nativer Sprachen wie C++ oder C. Das Konzept der Java Virtual Machine (JVM) bietet hierbei sowohl Vorteile als auch Hürden.
Häufig steht Gerichten nämlich kein sauber dokumentierter Quellcode zur Verfügung, sondern lediglich ein vorkompiliertes jar, war, oder ear-Archiv. Diese können mit Hilfe von Decompilern mit hoher Präzision zurück in den Quellcode übersetzt werden. Werkzeuge, wie der CFR-Decompiler oder Fernflower[16] ermöglichen es, aus Binärdateien wieder lesbare Quellcodes zu rekonstruieren[17]. Allerdings hat dieses Vorgehen auch seine Grenzen[18]. Kommen beispielsweise Obfuscatoren zum Einsatz, so werden alle Methoden, Variablen, Klassennamen durch unverständliche und kryptische Bezeichner ersetzt, was die Lesbarkeit erheblich einschränkt. Diese haben jedoch in modernen Software-Architekturen das große Problem, dass die Entwicklung von Services, APIs oder wiederverwendbaren Komponenten deutlich erschwert wird, denn gerade hierfür müssen ja Methoden und Strukturen erhalten bleiben. Für besondere, kritische Bereiche bieten Obfuscatoren jedoch zusätzliche Sicherheit und einen Schutz vor dem Decompilieren in lesbare (!) Quelltexte[19].
Sofern ein Quelltext entweder im Original oder durch Decompilieren vorliegt, prüft der Sachverständige dann die Logische Konsistenz, die Software-Qualität, versteckte Funktionen oder vergleicht den Quellcode im Rahmen der Beweisfrage.
In diesem Kontext ist auch auf den Aspekt der Sicherheitsüberprüfung hinzuweisen. Häufig gibt es Streitigkeiten, ob ein vorliegender Quellcode den (hoffentlich gemeinsam) festgelegten Qualitätskriterien genügt. CVE-Datenbanken (Common Vulnerabilities & Exposures) mit zugehörigen Schwachstellen-Scannern[20], wie bspw. Grype, Trivy, aber auch SonarQube, bieten komfortable Werkzeuge, um solche Schwachstellen automatisch zu erkennen. Allerdings stellt sich hier die Problematik, dass es nahezu nie um die Bewertung aktueller Schwachstellen, sondern um die Bewertung einer Software zum Zeitpunkt X geht. D.h. dass auch die CVE-Datenbank vom Zeitpunkt X stammen muss, um nachvollziehbar, nachprüfbar und fair zu bewerten. Durch die Verbindung von Snapshot-Repositories (z.B. NVD) oder archivierte Scans kann dieser Forderung Rechnung getragen werden[21].
Entwickler sollten daher den Einsatz von Obfuscatoren prüfen und in regelmäßigen Abständen auch das Decompilieren ihrer eigenen Anwendung ausprobieren, um ein Verständnis davon zu erlangen, an welche Informationen Dritte ggfs. kommen könnten, wenn sie in Besitz von jar-, war- oder ear-Dateien gelangt sind.
Deutlich komplizierter als die reine, statische Quellcode-Analyse ist es, ein Verständnis der dynamischen Aspekte einer Software zu entwickeln und zu dokumentieren. Damit Fehlerzustände nachgestellt werden können, reicht es meist nicht, den algorithmischen Ansatz zu verfolgen. Vielmehr spielen Rahmenbedingungen, wie Konfiguration, Datenbeschaffenheit, Infrastruktur, selbst Hardware-Gegebenheiten eine Rolle. In diesem Kontext sind Werkzeuge wie AspectJ[22], Eclipse Memory Analyzer[23] oder – falls möglich – auch Remote-Debugger wichtig, um ein Verständnis über das Laufzeitverhalten von Anwendungen zu entwickeln. Diese können nicht nur zur Überprüfung der Beschaffenheit von Anwendungen sondern auch während der Entwicklung oder beim Testen sehr hilfreich sein.
Letztlich gilt zu berücksichtigen, dass moderne Anwendungen so gut wie nie „from scratch“ entwickelt werden. Sie bestehen zu einem großen Teil aus Bibliotheken, im Java Kontext meist sogar aus Open Source Bibliotheken. Allerdings bedeutet dies nicht, dass die Verantwortung eines Entwicklers beim eigenen Quellcode endet. Vielmehr muss der komplette Abhängigkeitsbaum einer Software, die Software Bill of Materials (SBOM) in die Prüfung mit einbezogen werden. Das beste Beispiel, warum das wichtig sein kann, sind veraltete Bibliotheken mit Sicherheitslücken. Die regelmäßige Prüfung der SBOM und auch die regelmäßige Aktualisierung der Komponenten ist Bestandteil professioneller Software-Entwicklung und kann dem Hersteller von Anwendungen bei unsachgemäßer Umsetzung ggfs. zur Last gelegt werden. Die Sicherheitslücke in dem beliebten Logging-Framework Log4j war ein prominentes Beispiel und hat weltweit für Schwierigkeiten gesorgt.
Es ist dringend zu empfehlen, kontinuierliche Überprüfungen der SBOM von Anwendungen durchzuführen und deren Ergebnisse in die Software einfließen zu lassen. Gerade bei Open Source Projekten sind nutzende Entwickler umso mehr für die Funktionsweise ihrer eigenen Komponenten verantwortlich, da es keinen Hersteller mit entsprechenden Verträgen gibt, der im Zweifel belangt werden könnte.
Künstliche Intelligenz
Bei offen liegenden Quelltexten, Daten, Dokumentationen können Qualitäts- oder Problembewertungen meist mit genügend Sachverstand durchgeführt werden. Schwieriger wird all das jedoch, wenn künstliche Intelligenz ins Spiel kommt. KI-generierte Quelltexte werfen völlig neue Fragen auf: wer trägt bspw. die Verantwortung, wenn eine KI eine unsichere Java-Methode vorschlägt?[24] In puncto Verantwortung spielt auch das Urheberrecht keine große Rolle, denn ähnlich wie bei der Überprüfung der SBOM hat auch bei der Nutzung von KI der Entwickler die klare Verantwortung, KI-generierte Ergebnisse zu überprüfen[25]. An dieser Stelle muss allerdings auch entsprechende Fachkenntnis beim Entwickler vorliegen und dies wird zunehmend problematischer: Vibe Coding bspw. adressiert gezielt Nicht-Entwickler, indem durch funktionale Beschreibungen eine KI soweit gepromptet wird, dass diese selbständig und für den nicht ausgebildeten „Entwickler“ nicht überprüfbare Quelltexte erstellt, aus denen dann Anwendungen entstehen können. Auch hierbei ist der Entwickler für die Lösung verantwortlich, obwohl das ganze Konzept des „Vibe Codings“ ja eben exakt vorsieht, dass er diese Verantwortung nicht wahrnehmen muss[26]. Leider führt der Einsatz von KI in der Software-Entwicklung auch immer mehr dazu, dass Junior Entwickler sich zu sehr auf KI verlassen und die Ergebnisse nicht mehr beurteilen können. Solche Fälle können für Entwickler schnell problematisch werden.
Beim Einsatz von KI sollten Entwickler daher unbedingt in der Lage sein, die Ergebnisse zu überprüfen und zu bewerten. Ansonsten sind Probleme und ggfs. auch Haftungsrisiken vorprogrammiert. Darüber hinaus sollte unbedingt dokumentiert werden, welche Teile des Codes KI-generiert oder menschengemacht sind. Dies kann auch für spätere Trainings- oder Optimierungsprozesse auf der eigenen Codebase wichtig sein, da KI möglichst nicht mit KI-generierten Daten trainiert werden sollte.
Fazit und Ausblick
„Code vor Gericht“ wird in den kommenden Jahren immer mehr zu einem Standard-Szenario werden. Für Software-Unternehmen bedeutet dies, dass die Qualitätssicherung und Dokumentation von Quellcode und den dazu gehörigen Artefakten nicht nur technische Notwendigkeit, sondern essenzielle Risikovorsorge sind. Java bietet durch seine Struktur und die exzellenten Analyse-Werkzeuge eine gute Basis, auf der objektive Untersuchungen und Qualitätsmaßstäbe möglich sind. Vor Gericht lässt sich hier ein nachvollziehbares und nachprüfbares Gutachten erstellen.
Die menschliche Komponente wird in diesem Zusammenhang immer entscheidender. Unternehmen und Entwickler müssen heute wissen, welche Bestandteile zum Risiko werden können und welche Maßnahmen ergriffen werden können, um dieses in den Griff zu bekommen. In diesem Artikel wurden eine Reihe von konkreten Empfehlungen aufgelistet, die auf verschiedenen Ebenen und zu verschiedenen Phasen des Entwicklungsprozesses relevant sind. Werden diese berücksichtigt, dann kann man auf diesem Weg eine solide Basis nicht nur für qualitativ hochwertige Software, sondern auch für gute Argumentation im Streitfall liefern. Denn am Ende des Tages hoffen wir alle, dass Ihr Code nicht vor Gericht diskutiert werden muss.
Prof. Dr.-Ing Stefan Wagenpfeil
SLW – IT-Sachverständige, Brühl
PFH Private University of Applied Sciences, Göttingen
[1] Bundesministerium für Wirtschaft und Energie (BMWi), Digitale Transformation erfolgreich umsetzen – Herausforderungen und Erfolgsfaktoren für Industrieunternehmen, 2020.
[2] Fraunhofer ISI, Metzger, F.M. (2023): Digitale Geschäftsmodelle: Zugrundeliegende Trends und kennzeichnende Charakteristika.
[3] Buxmann, Diefenbach & Hess (2015): Geschäftsmodelle in der Softwareindustrie. Springer.
[4] Wagenpfeil (2026): Nachhaltiges Software-Engineering, Springer.
[5] EuGH (2020): Abgasmanipulationssoftware ist illegal
[6] BGH (2024): Deliktische Haftung wegen unzulässiger Abschalteinrichtungen
[7] FINRA (2024): Algorithmic Trading – Risiken & Regulierung
[8] FES / USAID (2023): Elections and Cybersecurity Reference Document
[9] UpCounsel. (2025, August 26). Forensics software in legal and cyber investigations. https://www.upcounsel.com/software-forensics
[10] Ferner, J. (2022). Quelltext als digitales Beweismittel. Ferner Alsdorf. https://www.ferner-alsdorf.de/bgh-einsichtsrecht-in-software-quelltext-bei-vermuteter-urheberrechtsverletzung-softwarerecht-rechtsanwalt/
[11] Weiß, F. (2025, 30. Juni). Schöpfungshöhe im Urheberrecht: Wann ist ein Werk wirklich geschützt? Ratgeberrecht.eu. https://www.ratgeberrecht.eu/aktuell/schoepfungshoehe-im-urheberrecht/
[12] HK Region Stuttgart. (2024). Rechtlicher Schutz an Software – Das sind die Regeln. https://www.ihk.de/stuttgart/fuer-unternehmen/recht-und-steuern/it-recht/ueberlassung-von-standardsoftware-das-sind-die-regeln-4368114
[13] Braguinski, L. (2025). Urheberrecht vor Gericht: Wie soll ich beweisen, dass mein Code nicht KI‑generiert ist? RSW/Beck. https://rsw.beck.de/aktuell/daily/meldung/detail/urheberrecht-gericht-code-ki-generiert-beweislast
[14] Chacon, S., & Straub, B. (n.d.). Pro Git (2nd Edition). Git‑Projektseite. https://git-scm.com/book/en/v2
[15] Caudwell, A. (n.d.). Gource – a software version control visualization tool. https://gource.io/
[16] JetBrains. (n.d.). Fernflower: Decompiler from Java bytecode to Java. GitHub. https://github.com/JetBrains/fernflower
[17] Benfield, L. (n.d.). CFR – another Java decompiler. https://www.benf.org/other/cfr/
[18] Javathinking. (2025, December 8). How to decompile Java code with correct line numbers using Fernflower in IntelliJ IDEA. https://www.javathinking.com/blog/how-to-decompile-with-correct-line-numbers-using-fernflower/
[19] CodingTechRoom. (n.d.). How can I decompile obfuscated Java bytecode? https://codingtechroom.com/question/decompile-obfuscated-java-bytecode
[20] CVE Program. (n.d.). Common Vulnerabilities and Exposures (CVE): Global reference standard for publicly disclosed cybersecurity vulnerabilities. https://www.cve.org/
[21] National Vulnerability Database (NVD). (n.d.). NVD Data Feeds: Annual CVE feeds and modified feed update guidance for local mirroring. https://nvd.nist.gov/vuln/data-feeds
[22] Eclipse Foundation. (n.d.). AspectJ documentation: Programming Guide, Problem Diagnosis Guide, Runtime API, and Weaver API. https://eclipse.dev/aspectj/doc/latest/index.html
[23] Eclipse Foundation. (n.d.). Eclipse Memory Analyzer (MAT): Fast and feature‑rich Java heap analyzer. https://eclipse.dev/mat/
[24] Saify, A. (2025, October 6). AI‑code‑responsibility: Who’s responsible for the bugs in AI‑generated code? Techfrolic. https://techfrolic.com/ai-code-responsibility-whos-responsible-for-the-bugs-in-ai-generated-code/
[25] Mark. (2025, March 22). AI‑generated code liability: Who’s responsible when Copilot X fails? Markaicode. https://markaicode.com/ai-code-liability-copilot-x-failures/
[26] Taylor Wessing. (2025, March 25). Open Source‑Risiken bei KI‑generiertem Code vermeiden. https://www.taylorwessing.com/de/insights-and-events/insights/2025/03/open-source-fallen-bei-ki-generiertem-code
