53. TAV

Programm

Donnerstag 10 - 18 Uhr

Keynote
KI schreibt Code - Wer testet die Sicherheit?
Clemens Hübner

Der Einsatz generativer KI verändert die Softwareentwicklung grundlegend. Coding Assistants beschleunigen die Implementierung und erleichtern den Zugang zu Entwicklungswissen, können jedoch zugleich neue Risiken für die Softwaresicherheit schaffen. Insbesondere besteht die Gefahr, dass unsichere oder ungeeignete Codevorschläge ohne ausreichende Prüfung übernommen werden und sich dadurch Sicherheitslücken in Anwendungen verbreiten. Gleichzeitig eröffnet KI neue Möglichkeiten, Sicherheitstests gezielter, skalierbarer und stärker kontextbezogen durchzuführen.

Dieser Beitrag untersucht die Frage: Wie verändert der Einsatz von KI die Praxis der Softwaresicherheitstests entlang des Secure Software Development Lifecycle (SSDLC) - sowohl als Risikofaktor bei KI-generiertem Code als auch als Werkzeug zur Verbesserung von Sicherheitstests? Dazu werden Herausforderungen bei der Nutzung von Coding Assistants und Ansätze für den KI-gestützten Einsatz in Code Reviews, bei der Generierung von Sicherheitstestfällen sowie im Umfeld statischer Anwendungssicherheitsanalyse vorgestellt. Der Beitrag ordnet diese Ansätze in einen SSDLC ein und zeigt die Bedeutung vorgelagerter Aktivitäten, insbesondere der Bedrohungsmodellierung, für wirksame und passgenaue Sicherheitstests.

KI-gestützte Absicherung kryptografischer Migrationen
Mario Friske

In diesem Beitrag wird die Absicherung kryptografischer Migrationen betrachtet und untersucht, wie KI-Systeme dabei unterstützen können. Im Mittelpunkt stehen die besonderen Herausforderungen kryptografischer Migrationen für den Test und die Frage, wie verschiedene Phasen des Testprozesses durch KI-Systeme unterstützt werden können. Darüber hinaus werden Möglichkeiten und Grenzen des KI-Einsatzes insbesondere im sicherheitskritischen Kontext diskutiert.

Zunächst wird auf die Notwendigkeit kryptografischer Migrationen und die aktuellen Herausforderungen beim Übergang zu quantensicheren Verfahren eingegangen. Dabei werden mit Crypto Assessment und Crypto Agility zentrale Konzepte kryptografischer Migrationen vorgestellt. Im zweiten Teil wird betrachtet, warum kryptografische Migrationen ein anspruchsvolles Testthema sind und welche besonderen Anforderungen sich daraus für die Qualitätssicherung ergeben. Der dritte Teil zeigt konkrete Einsatzmöglichkeiten von KI-Systemen bei der Absicherung kryptografischer Migrationen. Der vierte Teil diskutiert Möglichkeiten und Grenzen dieses Einsatzes. Dabei werden insbesondere die Sicherheitsanforderungen und Vorbehalte gegenüber dem Einsatz von KI im Security-Kontext berücksichtigt.

Als durchgängiges Fallbeispiel dient die Migration zu ML-KEM, anhand derer die Testherausforderungen und mögliche Einsatzfelder von KI konkretisiert werden.

KI? Aber sicher!
Dehla Sokenou, David Faragó

In den letzten Jahrzehnten haben wir gute Fortschritte gemacht, um Software sicherer zu machen. Inzwischen haben wir Regeln und Muster, um typische Securityprobleme schon von vornherein zu vermeiden. Doch inzwischen schreibt immer öfter KI Software, die von Menschen nur mangelhaft kontrolliert wird, wenn er sie überhaupt verstehen und bewerten kann. Und anstatt die Regeln und Muster anzuwenden, die wir entwickelt haben, lernt KI nicht nur von den guten Beispielen, sondern schreibt z.T. unsichere Software und wiederholt damit alte Fehler.

Schlimmer noch: es entsteht immer mehr Software, die potentiell unsichere KI-Komponenten enthält. Die Schlagzeilen sind voll davon. Wir hören von KI-Systemen, die nicht nur wie gewünscht die Testsysteme löschen, sondern auch gleich die gesamte Produktion inklusive aller Backups mit abräumen. Wir sehen KI-Systeme, die Festplatten nach Passwörtern scannen. KI wird genutzt, um Supply-Chain-Attacken durchzuführen, die schadhaften Code in bekannte Packages einschleusen.
Was können wir also tun? Der Vortrag soll eine Rückbesinnung auf die Grundsätze sicherer Software fördern, die natürlich auch für KI-Systeme und -komponenten gilt. Und zudem thematisiert er die besondere Probleme moderner Kis und zeigt Lösungen auf.

From TTCN-3 to C# – how AI turns a painful manual test migration into an overnight task
Victor-Iuliu Navratil

In the automotive industry, software suppliers must comply with strict code-quality requirements from
Original Equipment Manufacturers (OEMs), including adherence to the designed and implemented software architecture. Static architecture-conformance checking compares the code against the intended architecture and identifies the dependencies that violate architectural rules.

This typically reports only lists of violations without quantifying their overall impact on architectural quality.
This paper presents the Architecture Conformance Index (ACI), a five-step construction – model, classify,
aggregate, normalize, and compute a quality index – that turns conformance findings into a single bounded score in the range 0 to 100, where 100 means no violations and 0 means severe architectural erosion. The approach is evaluated on industrial automotive software systems. The evaluation shows that the proposed index can distinguish varying levels of architectural degradation and supports consistent comparison across projects of different size while preserving confidentiality of project-specific
results. By providing a quantitative measure of architectural conformance, ACI enables architecture
quality to be incorporated into composite software-quality assessment frameworks alongside other quality metrics.

Lesbare Tests – der Heilige Gral des Testens
Ronald Brill

Die Ritter der Tafelrunde zogen aus, um den Heiligen Gral zu finden – jeder mit einer anderen Vorstellung davon, was er eigentlich ist. Manche, wie Parzival, kamen ihm nahe. Andere scheiterten an ihren eigenen Fehlern. Und spätestens seit Umberto Ecos Baudolino wissen wir: Vielleicht existiert der Gral nur in den Geschichten, die wir über ihn erzählen.

Geht es uns mit lesbaren Tests nicht genauso? In Teststrategien, Guidelines und Konferenzvorträgen klingt Lesbarkeit wie eine Selbstverständlichkeit – ein Ziel, über das sich alle einig sind. Aber ist sie überhaupt ein absoluter Wert – oder liegt sie, wie Schönheit, im Auge des Betrachters? Und ist Lesbarkeit allein die Aufgabe des Autors?

Lesbarkeit entsteht nicht allein beim Schreiben – sie verlangt auch etwas vom Lesenden. Genau hier setzt dieser Vortrag an: Wie lesen wir Tests – und worauf kommt es dabei eigentlich an? Welche Rolle spielen unsere Erwartungen, die Perspektive, unter der wir lesen, sowie Erfahrung, Domänenwissen und Konventionen? Welche Annahmen über Lesbarkeit sollten wir hinterfragen?

Sind wir bei der Suche nach dem Heiligen Gral auf dem Holzweg? Vielleicht müssen wir gar nicht lernen, lesbarere Tests zu schreiben. Vielleicht müssen wir lernen, bessere Leser zu werden…

From Static Analysis Findings to a Quality Score: An Architecture Conformance Index for Automotive Software
Wadi Touil, Priteshkumar Gohil, Michael Schmidt and Joachim Wegener

In the automotive industry, software suppliers must comply with strict code-quality requirements from Original Equipment Manufacturers (OEMs), including adherence to the designed and implemented software architecture. Static architecture-conformance checking compares the code against the intended architecture and identifies the dependencies that violate architectural rules. This typically reports only lists of violations without quantifying their overall impact on architectural quality. This paper presents the Architecture Conformance Index (ACI), a five-step construction – model, classify, aggregate, normalize, and compute a quality index – that turns conformance findings into a single bounded score in the range 0 to 100, where 100 means no violations and 0 means severe architectural erosion. The approach is evaluated on industrial automotive software systems. The evaluation shows that the proposed index can distinguish varying levels of architectural degradation and supports consistent comparison across projects of different size while preserving confidentiality of project-specific results. By providing a quantitative measure of architectural conformance, ACI enables architecture quality to be incorporated into composite software-quality assessment frameworks alongside other quality metrics.

Update für den ISTQB Certified Automotive Software Tester
Ralf Reißing

Das Certified-Tester-Schema des International Software Testing Board (ISTQB) dient der Qualifizierung von Software-Testern. Es basiert auf einer allgemeinen Grundausbildung, dem Certified Tester Foundation Level (CTFL), und darauf aufbauenden Vertiefungen (Advanced Level, Expert Level) sowie Spezialisierungen (Specialist). Eine der Spezialisierungen ist der Certified Automotive Software Tester (CT-AuT). Seit der grundlegenden Überarbeitung des Lehrplans für die Version 2.0 im Jahr 2017 war sowohl wegen der Änderungen relevanter Normen im Automobilbereich als auch wegen der fundamentalen Überarbeitung des CTFL-Lehrplans eine Anpassung des CT-AuT-Lehrplans notwendig. Die Überarbeitung wurde 2025 sowohl für die englische als auch die deutsche Fassung abgeschlossen. Dieser Beitrag stellt die wesentlichen Änderungen am CT-AuT-Lehrplan und ihre Hintergründe vor.

Freitag 8:30 - 16 Uhr

Mythos und Wirklichkeit – Den eigenen Weg zur Qualität finden
Ralf Somplatzki

Qualität sichern bedeutet mehr als Software testen. Und in der jüngsten Zeit auch nicht mehr allein funktionales Testen. Die Anforderungen an Qualität werden immer breiter. Spitz gefragt: Können QA Verantwortliche heute eigentlich noch alles im Blick haben? Cyber-Angriffsflächen werden immer größer, Software wird nicht mehr von Menschen, sondern von Maschinen geschrieben. Es entstehen Komplexitäten, die mit menschlichem Vermögen kaum oder gar nicht mehr handle bar sind. Wo soll Qualitätssicherung (QA) angreifen? Was muss ein Unternehmen oder ein Projekt im Bereich QA
leisten?

Im Rahmen des Beitrages werden Metaphern und Bilder rund um Elefanten genutzt, um auf unterhaltsame Weise die Frage zu beantworten, wie wir Qualität effektiv in unseren Entwicklungsprojekten adressieren.

Dabei spielen psychologische, wirtschaftliche und strategische Effekte möglicher Weise eine größere Rolle als Technik und Fachlichkeit. Aus diesem Grund werden Bilder aus Soziologie, Psychologie und Wirtschaft herangezogen.

Am Ende steht die Erkenntnis, dass mehr Qualität nicht das Ergebnis von mehr Befähigung, Methoden oder Tools und Techniken ist. Reifende und zukunftsorientierte Qualitätssicherung hat ihren Ursprung in einer gemeinsamen Kultur. Und Kultur beginnt im Miteinander, bei aller Unterschiedlichkeit, im Austausch über Probleme, Herausforderungen und Ziele. Im gemeinsamen Suchen nach Synergien, Stärken und Lösungen, die dem Ganzen gerecht werden. Der Startpunkt dafür liegt beim Unternehmen selbst, bei seiner Identität.

Cyber Resilience Act und Cybersicherheit – Anforderungen, Normen und praktische Umsetzung
Michael Lang

Die zunehmende Vernetzung von Produkten und Systemen macht Cybersicherheit zu einer zentralen Voraussetzung für den sicheren Betrieb digitaler Technologien. Der Vortrag beleuchtet zunächst die praktischen Gründe für Cybersecurity, darunter konkrete Bedrohungsbeispiele sowie wirtschaftliche Risiken für Hersteller und Betreiber. Ergänzend werden die regulatorischen Rahmenbedingungen aufgezeigt, die durch die Radio Equipment Directive (RED) und insbesondere durch den neuen Cyber Resilience Act (CRA) maßgeblich geprägt werden.

Im zweiten Teil folgt ein umfassender Ausblick auf die kommenden Anforderungen des CRA. Hierzu zählt der aktuelle Stand der Normung rund um die prEN 40000 Reihe, die grundlegende Begriffe, Prinzipien der Cyberresilienz, den Umgang mit Schwachstellen sowie generische und bereichsspezifische Sicherheitsanforderungen definiert. Zudem werden die betroffenen Produktkategorien und die neuen Meldepflichten erläutert.

Der letzte Teil des Vortrags konzentriert sich auf die praktische Umsetzung: Welche Produkte fallen in den Anwendungsbereich? Welche grundlegenden Anforderungen müssen erfüllt werden? Welche Inhalte gehören in die technische Dokumentation? Wie sehen Konformitätsbewertungsverfahren aus? Durch Beispiele wie SBOMs, Richtlinien zur koordinierten Offenlegung von Schwachstellen sowie Prozesse zum Vulnerability Handling wird der Weg zur Compliance konkret aufgezeigt. Abschließend werden praxisnahe Empfehlungen gegeben, wie sich Unternehmen effizient auf die CRA-Anforderungen vorbereiten können.

Impulsvortrag: Cyber Resilience Act - was werden wir testen?
Georg Sehl

Wogegen werden wir testen? Was ist unser Testorakel? Was ist die Testbasis?

In den Anhängen I, III und IV des Cyber Resilience Acts werden grundlegende horizontale und vertikale Cybersecurity-Anforderungen aufgelistet. Werden diese Cybersecurity-Anforderungen mit neuen und bereits bestehenden Normen („standards“) „harmonisiert“ („harmonised standards“), dann besteht eine „Konformitätsvermutung“ („presumption of conformity“), dass durch die Erfüllung dieser Normen auch die grundlegenden Cybersecurity-Anforderungen des Cyber Security Acts abgedeckt werden.

Die Europäische Kommission hat am 3.2.2025 einen Normierungsauftrag M/606 verabschiedet, in dem ein Paket von 41 Normen beschrieben wird , welche mit den grundlegenden horizontalen und vertikalen Cybersecurity-Anforderungen harmonisiert werden sollen. Die aktuellen Deadlines für die 41 einzelnen Normierungsaufträge liegen zurzeit zwischen dem 31.10.2026 und der finalen Deadline des CRA am 30.10.2027 (die Deadlines in 2026 wurden Ende Juli um jeweils 2 Monate verschoben). Wir sind daher in einer Übergangsphase, in der wir sowohl gegen generische Cybersecurity-Anforderungen des CRA als auch gegen bereits harmonisierte Normen testen müssen.

Lassen sich aus den Cybersecurity-Anforderungen des CRA, deren Harmonisierung erst bis zum 30.10.2027 abgeschlossen sein soll, mit den vertrauten Test-Vorgehensweisen, -Methoden und -Werkzeugen Testideen, Testbedingungen oder gar logische Testfälle ableiten? Versuchen wir es ...

How CRA changed the way how we develop Software
Stephan Schulz

There are only a few disruptive changes in software development that one generally consciously remembers, e.g., the day your CEO came and put this book on the table on agile development and everything changed, or when the Software Bill of Materials (SBOM) became a mandatory requirement in software releases due to export regulations. The day I got back from my winter vacation this year was another such day: it was the day the Cyber Resilience Act (CRA) changed the way how we deliver software.