Die Konferenz war wirklich schön mit vielen interessanten Vorträgen und anregenden Gesprächen. Regensburg ist eine charmante Stadt mit viel Geschichte, auch wenn ich persönlich davon nicht allzu viel sehen konnte, da mein Zeitplan leider recht voll war. Immerhin konnte ich den Fußweg vom Hotel zur Marina Regensburg etwas genießen. Sowohl die Location als auch das Catering waren super – beides hat sicher dazu beigetragen, dass die Atmosphäre auf der Konferenz angenehm war und zum Networking bzw. Austausch eingeladen hat. Darüber war ich froh, da mir so als einziger Vertreter der CI auf der devSec auch beim Mittagessen nie langweilig wurde und ich einige gute Gespräche führen konnte.
Der Themenfokus lag sehr stark auf Threat Modeling, was wohl dem geschuldet ist, dass der Cyber Resiliency Act (CRA) eine Bedrohungsanalyse fordert. Entsprechend gab es viele Talks zu diesem Thema. Es war durchaus spannend zu sehen, wie Andere Threat Modeling angehen, auch wenn inhaltlich für mich nur wenig Neues dabei war. In einem Talk zum Thema CRA war das Fazit: “Wer heute Security ernst nimmt → wenig Zusatzaufwand”. Das mag zwar stimmen, aber viele Teams haben Threat Modeling noch nicht in ihre Prozesse integriert.
Die starke Präsenz des Themas zeigt für mich, dass es Bedarf gibt und Threat Modeling nicht so weit verbreitet ist, wie es sein sollte. Gerade kleineren Entwicklungs-/Produktteams fehlt oft die Expertise ein explizites Threat Modeling durchzuführen. Genau das wird aber jetzt mit dem CRA gefordert. Das birgt Chancen aber auch Risiken: Ich sehe hier etwas die Gefahr, dass Threat Modeling in Teams nur wegen der Compliance-Vorgaben eingeführt, aber nicht sauber in Prozesse integriert wird.
Bei CI helfen wir als Experten für Threat Modeling dabei, diese Methode erfolgreich in Ihren Entwicklungsprozess zu integrieren.
Das große Thema überhaupt war natürlich Künstliche Intelligenz (KI). Es gab kaum einen Vortrag in dem KI nicht angesprochen wurde. Ich denke, dass ist dem generellen Trend und der Unsicherheit im Bereich Softwareentwicklung geschuldet: Wo wird Softwareentwicklung in fünf Jahren stehen? Werden wir alle Vibe Coden? Was heißt das für den Betrieb von Software? Dementsprechend haben sich viele Vorträge mit den Chancen und Risiken von KI beschäftigt. Auch in der Keynote von Dr. Kind von Siemens wurde das Thema beleuchtet.
Die Präsentation beschäftigte sich mit dem zunehmenden Einsatz von KI in der industriellen Softwareentwicklung bei Siemens. Siemens arbeitet daran, eine zentrale DevSecOps-Plattform aufzubauen, die industrielle Foundation Models nutzt, also KI-Modelle, die auf Zeitreihen industrieller Prozesse trainiert sind. Insgesamt geht Siemens klar in Richtung einer KI-gestützten, sicheren und resilienten Softwareentwicklung für die Industriebereiche.
Dr. Kind hat den Nutzen von KI in drei Kategorien eingeteilt, die ich sehr treffend finde. Viele der restlichen Vorträge auf der devSec Konferenz können ebenfalls in diese Kategorien einsortiert werden.
Spannend fand ich den Ansatz von Siemens, KI zur Unterstützung bei Threat Modeling – bzw. hier “Threat and Risk Assessment” genannt – zu nutzen. Die Idee ist, die initiale Analyse zu automatisieren und anschließend mit manuellen Sessions zu validieren und zu erweitern.
Ich kann mir gut vorstellen, dass eine Organisation wie Siemens viel Potenzial hat, Prozesse zu optimieren und eine Security-Baseline durch KI-gestütztes Threat Modeling zu schaffen, bevor menschliche Security-Spezialist*innen involviert werden. Gerade in großen Organisationen, wie Siemens, sind Security Expert*innen oft das Bottleneck und können nicht in jedes Projekt von Anfang an involviert werden.
Auch andere spannende Projekte bei Siemens wurden vorgestellt: So entwickelt das Unternehmen maßgeschneiderte LLM-Tools als „Secure Coding Companion“, um Sicherheitslücken frühzeitig zu erkennen und zu beheben. Im DARPA-Projekt CASTLE wird agentenbasierte KI für Red/Blue Teaming eingesetzt, wobei Siemens mit dem ORLANDO-Agenten zur Netzwerkverteidigung beiträgt – ein spannendes Programm, auf dessen Resultate ich schon gespannt bin. KI bzw. Machine Learning wird schon lange im Computer Security Bereich eingesetzt, z. B. für Malware-Erkennung oder im Bereich Network Intrusion Detection. Jedoch wurde hier auch immer wieder demonstriert, dass die Machine Learning Modelle häufig durch einen aktiven menschlichen Angreifer ausgetrickst werden können. Insofern bin ich schon gespannt, ob die KI-Agenten in dem CASTLE-Programm lernen werden, sich gegenseitig mit Prompt Injection oder ähnlichen Angriffen auszuhebeln.
Im Bereich Kryptografie zeigt sich, dass Siemens sich mit Post-Quantum Cryptography (PQC) beschäftigt. Neu war für mich, dass es „CryptoBOM“ (Crypto Bill of Materials) gibt. Hier sieht man gut die Unterschiede zu einem Software Produkt in der Cloud und einem Cyber-Physical System, wie sie Siemens herstellt: Eine SaaS-Applikation wurde in zehn Jahren wahrscheinlich schon dreimal komplett neu geschrieben, während ein Zug auch in zehn Jahren noch sicher kommunizieren können muss, egal ob es bis dahin praktikable Quantencomputer gibt oder nicht.
Ein weiteres spannendes Thema aus der Diskussion war die Frage, wie KI „gepatcht“ werden kann. Dr. Kind verwies auf Guardrails, Richtlinien und Sandbox-Ansätze, räumte jedoch Forschungsbedarf ein. Ich denke, dass hier gerade das Sandboxing immer wichtiger wird. Je mehr Autonomie einem KI-Agenten gegeben wird, umso mehr wird man auch in Sandboxing, Monitoring und Logging rund um den KI-Agenten investieren müssen.
Ein Kommentar aus dem Publikum berichtete von schlechten Erfahrungen mit KI und Threat Modeling. Der Kritikpunkt: Die KI würde nur generische Threats finden, die interessanten Eigenschaften in der Architektur blieben jedoch unentdeckt. Dr. Kind entgegnete, dass die guten Erfahrungen von Siemens eventuell an der spezielleren Umgebung liegen könnten: 1. Siemens kann die Modelle mit Fine-Tuning auf historische Threat Modeling Sessions maßschneidern. 2. Durch die geringere Vielfalt im OT-Bereich gibt es auf der Architektur-Ebene weniger Varianz, was automatisierte Analysen durch KI begünstigt.
Meine persönliche Einschätzung ist, dass der Ansatz von Siemens vernünftig klingt. Viele Teams ohne gelebte Security brauchen zuerst eine Security-Baseline und KI kann dabei helfen, diese zu automatisieren. Ein Beispiel dazu: KI hat auf jeden Fall schon die Fähigkeit nachzufragen, ob alle Verbindungen durch TLS geschützt sind und ob Autorisierung und Authentifizierung implementiert sind. Für Sicherheitsexpert*innen klingt das offensichtlich, aber es ist leider nicht selbstverständlich, dass das auch überall umgesetzt ist. Gerade in abgeschotteten Netzen, wie sie im OT-Bereich üblich sind, wird gerne auf TLS verzichtet. Aber selbst, wenn Security im Entwicklungsprozess bereits etabliert ist, kann KI unterstützen, etwa um ein Threat Model aktuell zu halten oder einfach als automatisierter Reviewer. Werden KI-Modelle die Feinheiten komplexer Architekturen erkennen? Nein – zumindest nicht mit aktuellen Modellen. Es bedarf immer noch der Überprüfung und Bewertung durch menschliche Security-Expert*innen.
In seinem Vortrag hat Marcus Blankenburg gezeigt, wie sich Threat Modeling weiterentwickelt hat – weg vom statischen Diagramm hin zu einem lebendigen, iterativen Prozess, der moderne Risiken, wie Supply-Chain-Angriffe, API-Missbrauch, Cloud-Fehlkonfigurationen und KI-spezifische Bedrohungen integriert. Threat Modeling wird so zur Gewohnheit im agilen Prozess – mit Backlog-Items, Security-Kriterien in der Definition of Done und kontinuierlicher Modellpflege. Besonders spannend fand ich die Ansätze, Threat Modeling näher an das Entwicklungsteam zu bringen, z.B. indem Bedrohungen als Teil des agilen Sprints und wie ein normales Backlog-Item betrachtet werden.
Beim Thema KI hat der Vortragende das „KI-Bedrohungsmodell-Quadrat“ eingeführt, das KI aus vier Perspektiven betrachtet: als Bestandteil von Anwendungen, als Tool in der Entwicklung, als Hilfe für den Angreifer und als Verteidiger im Betrieb. In der Keynote von Dr. Kind waren es noch drei Kategorien – ich sehe hier allerdings keinen Widerspruch. Je nach Abstraktionsebene ließen sich „KI in Anwendung“ und „KI im Betrieb“ auch kombinieren.
Der Vortrag behandelte auch neue Threat Modeling Frameworks. Laut Blankenburg stoßen klassische Frameworks wie STRIDE an ihre Grenzen, wenn es um KI-Anwendungen geht, weshalb neue Ansätze wie MAESTRO nötig sind. Ich sehe das etwas anders: Meiner Ansicht nach ist MAESTRO in engeren Sinne keine Threat-Modeling-Methode, sondern eher vergleichbar mit z.B. Google’s Secure AI Framework (SAIF), dem OWASP SAIF Threat Model oder auch dem Databricks AI Security Framework (DASF). Das sind alles Referenzarchitekturen für typische KI-Anwendungen, die mit Katalogen für Bedrohungen und Gegenmaßnahmen ausgestattet wurden. Man könnte sie als generische Threat Models für KI-Anwendungen bezeichnen. Wie setze ich die nun für mein System um? Da gibt es wenig Hilfestellung. Es gilt also zu ermitteln, welche Teile dieser Referenzarchitekturen auf die eigene Applikation zutreffen und welche Bedrohungen sich davon ableiten lassen. Alle Bedrohungen in diesen Referenz-Threat-Models können im Endeffekt auch auf die STRIDE-Kategorien umgelegt werden. Ist MAESTRO also die Threat-Modeling-Methode für KI-Anwendungen? Ich bezweifle es stark. Ich denke MAESTRO oder die oben genannten Frameworks / Threat Models sind durchaus hilfreich, aber um eine klassische Threat Modeling Session kommt man nicht herum.
Wie eine klassische Threat Modeling Session aussieht, haben wir bereits in mehreren Blogposts beschrieben!
Eine schöne Abwechslung war der Vortrag von Philipp Schubert zu Hazard Pointers in C++26 – ein tiefgehender technischer Talk ohne KI überhaupt zu erwähnen. Das Thema war Speichersicherheit und lockfreie Programmierung. Er zeigte anhand konkreter Codebeispiele, wie Hazard Pointers helfen, das ABA-Problem zu lösen und gleichzeitig Speicher sicher freizugeben, ganz ohne Garbage Collector oder Locks. Es wurden verschiedene Varianten verglichen, um das Problem zu lösen, z.B. mit anderen Ansätzen wie Read-Copy-Update, Reference Counting und Shared Pointers.
Richter hat Ergebnisse des BSI: Project 486 vorgestellt, in dem Open-Source-Projekte auditiert wurden. Ein zentrales Ergebnis dieses Projektes war, dass manuelle DAST-Tests oft kritische Probleme, wie fehlende Zugriffskontrollen erkennen konnten, während SAST-Tools daran scheiterten bzw. nicht einmal darauf hinweisen konnten. Ich würde sagen, das deckt sich mit dem “Common Wisdom” im Security Bereich: Manuelle Analysen liefern meistens immer noch die interessantesten und kritischsten Sicherheitslücken.
Der Vortragende leitet daraus die Hypothese ab, dass LLMs künftig automatisierte Code-Reviews ermöglichen könnten, um solche Schwachstellen frühzeitig zu identifizieren. Erste Proof-of-Concepts zeigen, dass dieser Ansatz vielversprechend ist – insbesondere durch die Kombination spezifischer Fragestellungen mit wachsendem Kontextwissen über den analysierten Code. Als Beispiel wurde die Analyse von Vaultwarden genannt. Das LLM wurde für jeden HTTP-Endpoint-Handler mit zwei Fragen konfrontiert:
Trifft beides zu, kann man davon ausgehen, dass hier Zugriffskontrolle tatsächlich fehlt.
Ganz ähnliche Dinge wurden auch in der DARPA AIxCC umgesetzt, worüber ich in einem meiner letzten Blogposts schon geschrieben habe. Ich bin überzeugt, dass wir in den nächsten Jahren viele Innovationen in dieser Richtung sehen werden.
Ich bin ja selbst ein Fan von Rust, daher war der Vortrag von Ingo Budde für mich ein echtes Highlight. Er hat sehr praxisnah gezeigt, wie Rust durch sein Ownership- und Borrowing-System viele klassische Speicherfehler wie Use-after-Free, Null-Pointer oder Race Conditions verhindert. Er hat auch Einblicke in „Unsafe Rust“ geliefert – wann man es braucht, welche Risiken es birgt und wie man mit Tools wie Miri, Rudra oder MIRAI trotzdem sicher bleibt. Auch die Analyse von Abhängigkeiten mit Cargo Audit, Geiger und dem Forschungsprojekt Flowcheck war spannend für den Alltag. Insgesamt ein sehr fundierter Talk mit vielen Verweisen auf praxistaugliche Tools, der gezeigt hat, wie man Rust wirklich sicher nutzt.
Mir persönlich hat nur ein Aspekt gefehlt: Fuzzing. Rust bietet mit cargo-fuzz und bolero zwei sehr gut integrierte Werkzeuge, um Fuzzing einzusetzen. Spannend ist z.B., dass bolero Property-Based Fuzzing ermöglicht, also auch Fuzzing um logische Fehler zu erkennen, die nicht automatisch zu einem Crash führen. Wer unsafe Rust nutzt, sollte meiner Meinung nach auf jeden Fall auch Fuzzing einsetzen.
Als nächstes kam ein Double Feature an Vorträgen zu Passkeys. Zuerst die Keynote von Jürgen Schmidt als Plädoyer für Passkeys als moderne, sichere und benutzerfreundliche Alternative zu Passwörtern und Multi-Faktor-Verfahren und danach ein Vortrag von Martina Kraus zur Einführung von Passkeys in der Praxis.
Jürgen Schmidt erklärte in seiner Keynote anschaulich, warum Passkeys Phishing-resistent sind, wie sie durch Public-Key-Kryptografie funktionieren und warum sie in vielen Fällen sogar sicherer als gängige Zwei-Faktor-Authentifizierung sind – insbesondere wenn sie gerätegebunden sind. Dabei wurde auch deutlich, dass viele MFA-Varianten Schwächen haben, etwa durch Session-Hijacking oder Infostealer, und dass Passkeys hier eine robuste Lösung bieten. Aber das beste Argument für Passkeys war wohl die Geschichte von Troy Hunt, der dafür bekannt, ist im Projekt haveibeenpwnd.com eine Datenbank an bekannten Passwort-Leaks zu pflegen. Diese Plattform wird mittlerweile von vielen genutzt, um auf die Wiederverwendung von bekannten Passwörtern zu prüfen. Troy Hunt ist also sicher die Person mit starker Awareness, was sicheren Umgang mit Passwörtern angeht. Doch auch er wurde Opfer eines Phishing Angriffs: Mit Jet-Lag unterwegs am Flughafen hat er sein Passwort und den dazugehörigen Multi-Faktor-Code auf einer Phishing Website eingegeben. Damit ist wohl klar: Awareness Training kann nicht die Lösung sein. Wir müssen Passwörter durch stärkere technische Maßnahmen ersetzen. Passkeys könnten eine Lösung sein.
Martina Kraus hat direkt im Anschluss sehr praxisnah gezeigt, wie man Passkeys konkret in Anwendungen integriert. Ihr Vortrag war die perfekte Ergänzung zur Keynote: Während Schmidt das „Warum“ überzeugend darlegte, ging Kraus ins „Wie“. Sie stellte verschiedene Implementierungsstrategien vor – von Self-Development über SDKs bis hin zu Passkey-as-a-Service – und beleuchtete die jeweiligen Vor- und Nachteile. Besonders hilfreich waren ihre Hinweise zu Recovery-Strategien, Migration bestehender Nutzer*innen und Fallback-Mechanismen. Für Entwickler*innen war das ein wertvoller Überblick über die technischen Herausforderungen und Lösungsansätze bei der Einführung von Passkeys.
Eine Frage aus dem Publikum hat mich etwas beschäftigt: Wieso setzen wir jetzt Passkeys ein, wenn wir doch schon seit Jahrzehnten x.509-Client-Zertifikate bei TLS-Verbindungen verwenden könnten? Beides funktioniert basierend auf Public-Key-Kryptographie und hat sehr ähnliche Eigenschaften. Diese Frage wurde durch den Vortragenden nicht eindeutig beantwortet. Ich sehe da zwei mögliche Gründe:
Den Abschluss der Konferenz bildete für mich ein angenehm technischer Vortrag von Tobias Hamann mit dem Titel „Die Kunst des Mobile-App-Pentestings für Entwickler“. Das Thema war für mich besonders spannend, da ich mich bereits während meines Studiums intensiv mit Android-Security und Malware-Analyse beschäftigt hatte – schön, hier ein Update zum aktuellen Stand zu bekommen. Der Vortrag bot einen praxisnahen Überblick über typische Schwachstellen in mobilen Apps, darunter unsichere Datenhaltung, fehlerhafte Zugriffskontrollen und Sicherheitsfehlkonfigurationen. Besonders hilfreich fand ich die strukturierte Darstellung des Analyseprozesses und den Bezug zum OWASP Mobile Application Security Projekt. Hamann hatte eine spannende Schwachstelle im Open Source Messenger ElementX als Beispiel mitgebracht und diese im Detail erklärt. Hier konnte eine Malware App eine Lücke in ElementX ausnutzen, um unbemerkt Kamera und Mikrofon zu aktivieren und z.B. sensitive Informationen aufzuzeichnen. Das Problem war hier die fehlende Absicherung eines WebViews, die über einen Android Intent von jeder anderen Android Applikation aufgerufen werden konnte.
Die diesjährige heise devSec war eine wirklich schöne Konferenz mit vielen interessanten und informativen Vorträgen. Es gab so viele spannende Themen, dass ich mich teilweise nicht entscheiden konnte, welchen Track ich besuchen sollte. Auch die anregenden Diskussionen während der Abendveranstaltung haben zum intensiven Austausch beigetragen und die Veranstaltung zu einem rundum gelungenen Erlebnis gemacht.
