Entwicklung & Code
Aus Softwarefehlern lernen – Teil 6: Eine Zeile Code mit fatalen Auswirkungen
In der Softwareentwicklung gibt es Bereiche, in denen schon ein einziger Fehler katastrophale Folgen haben kann. Besonders anfällig sind dabei Kryptografiebibliotheken und Parser – also genau jene Bausteine, die Daten validieren, entschlüsseln oder die Integrität von Kommunikation sicherstellen.
Weiterlesen nach der Anzeige

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Die Teile der Serie „Aus Softwarefehlern lernen“:
In diesen Bereichen gilt: Ein vermeintlich kleiner Bug kann globale Auswirkungen haben. Zwei der bekanntesten Vorfälle der letzten Jahre illustrieren das eindrücklich, nämlich Heartbleed und Apples „goto fail“.
Muster 6: Kryptografie- und Parser-Fehler: Wenn eine einzige Codezeile die Sicherheit kippt
Heartbleed war ein Fehler in OpenSSL, einer der meistgenutzten Kryptografiebibliotheken der Welt. Der Bug betraf die Implementierung des TLS-Heartbeat-Mechanismus. Heartbeats sind kleine Nachrichten, mit denen Client und Server prüfen, ob die Verbindung noch lebt. Ein Client sendet (im Falle von TLS) dazu eine Nachricht, in der er unter anderem die Länge der eigenen Daten angibt. Der Server spiegelt diese Daten zurück.
Der fatale Fehler dabei war, dass die angegebene Länge nicht validiert wurde. Ein Angreifer konnte also behaupten, er sende zum Beispiel 64 KByte Daten, sendete tatsächlich aber nur 1 Byte. OpenSSL las daraufhin blind die fehlenden 63.999 Bytes aus seinem Speicher und schickte sie zurück. Diese Out-of-Bounds-Reads erlaubten es, mit ein bisschen Glück sensible Informationen wie Passwörter, Session Keys oder private Schlüssel auszulesen.
Die Tragweite war enorm. Millionen von Webservern waren betroffen, und weil TLS-Private-Keys kompromittiert waren, mussten die Betreiber zahllose Zertifikate austauschen. Der Bug bestand dabei über zwei Jahre in der OpenSSL-Codebasis, obwohl er nur wenige Zeilen lang war.
Fast zeitgleich machte Apple mit einem ebenfalls winzigen, aber folgenschweren Fehler namens goto fail Schlagzeilen. In der Implementierung der SSL-Zertifikatsprüfung in iOS und macOS fand sich eine verdoppelte Codezeile:
Weiterlesen nach der Anzeige
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
Die zweite goto fail-Zeile war dabei falsch eingerückt, sodass Reviewer den Fehler schlecht erkennen konnten. Das System führte die zweite Zeile nämlich immer aus, unabhängig vom Ergebnis der if-Anweisung. Das wiederum hatte zur Folge, dass das System einen Teil der sicherheitskritischen Zertifikatsprüfung übersprang. Dadurch konnte ein Angreifer einen Man-in-the-Middle-Angriff durchführen, weil macOS, iOS und andere Apple-Betriebssysteme gefälschte Zertifikate akzeptierten. Wie bei Heartbleed war der betroffene Code winzig, die Folgen jedoch massiv.
Was haben beide Fehler gemein? Sicherheitskritischer Code ist oft alt und wenig verändert: Entwicklerinnen und Entwickler fassen Parser, Krypto-Routinen oder Protokollimplementierungen selten an – und wenn, dann oft unter Zeitdruck.
- Einzelne Zeilen können sicherheitsentscheidend sein: Die Logik ist komplex, Tests decken selten alle Pfade ab, und Compiler warnen nicht vor falscher Einrückung oder fehlender Längenvalidierung.
- Fehler bleiben lange unentdeckt: Heartbleed war über zwei Jahre im Code.
goto failfiel erst auf, als unabhängige Forscher den Code analysierten.
Wer sicherheitskritische Software entwickelt oder integriert, sollte daher einige Prinzipien beherzigen:
- Vier-Augen-Prinzip und Code-Reviews: Kein sicherheitsrelevanter Commit sollte von nur einer Person geschrieben und gemerged werden.
- Fuzzing und Differential-Tests: Automatisierte Tests, die zufällige und manipulierte Eingaben erzeugen, decken viele Parser- und Memory-Bugs auf.
- Reproduzierbare Builds und Dependency-Audits: Developer müssen sicherheitskritische Software in derselben Version reproduzierbar bauen und signieren. Änderungen in Libraries müssen sie aktiv verfolgen und bewerten.
- Minimaler und isolierter Code: Krypto- und Parser-Funktionen sollten möglichst klein und möglichst isoliert sein, um die Angriffsfläche zu minimieren.
- Proaktive Schlüssel- und Zertifikatsrotation: Selbst wenn ein Fehler wie Heartbleed auftritt, kann ein schneller Schlüsselaustausch die Folgen begrenzen.
Die beiden Fälle zeigen: Security-Bugs entstehen oft in den unscheinbarsten Codezeilen. Wer sie ignoriert, riskiert nicht nur Ausfälle, sondern auch Vertrauensverlust und juristische Folgen. Für Unternehmen ist daher klar: Sicherheitskritische Bereiche benötigen besondere Prozesse, zusätzliche Tests und regelmäßige Audits.
(who)
Entwicklung & Code
Model-Schau 1: Schlanke KI-Spezialmodelle im Trend
Beim Blick auf Large Language Models vergeht fast keine Woche ohne neue Modelle, die sich in bestimmten Nischen positionieren oder neue Techniken ausprobieren. Das hat uns dazu bewogen, regelmäßig über diese Updates zu berichten. Bei größeren Neuerungen werden wir den geplanten Zweiwochentakt unterbrechen und neue Modelle direkt untersuchen.
Weiterlesen nach der Anzeige

Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.
Dieses erste Update fällt etwas umfangreicher aus. Aktuelle Modelle finden sich bei Hugging Face oder durch konsequentes Mitlesen im sehr aktiven LocalLLaMa-Subreddit. Gerne nehmen wir auch Vorschläge über Modelle entgegen, die wir uns näher anschauen sollen.
Kleine Spezialmodelle
Der Trend muss nicht zu immer größeren Modellen gehen. Bei Hugging Face finden sich einige Modelle, die sehr beliebt, aber nicht besonders groß sind.
Ganz vorn steht hier VibeThinker von WeiboAI. Das Reasoning-Modell ist vor allem darauf ausgelegt, mathematische Fragen zu beantworten oder Programmcode zu erzeugen. Für diese Aufgaben ist es sehr gut geeignet. Laut den Benchmarks spielt es in der gleichen Liga wie das (ältere) Gemini 2.5 Flash und überholt teilweise sogar DeepSeek R1.
(Bild: Bridgman/AdobeStock)

Am 22. und 23. April 2026 findet die Minds Mastering Machines in Karlsruhe statt. Im Mittelpunkt der von iX und dpunkt.verlag veranstalteten Konferenz stehen praxisnahe Themen von klassischem Machine Learning bis zu LLMs und Agentic AI. Das Programm bietet unter anderem Vorträge zu folgenden Themen:
- Predictive Maintenance in der Praxis
- Kommunikationsprotokolle für Agentic AI
- Embeddings richtig verstehen
- MCP sicher im Unternehmen einsetzen
- Lokale LLMs in der Praxis
Erstaunlich ist, dass das Modell mit nur 1,5 Milliarden Parametern auskommt. Die anderen genannten Modelle haben 400-mal mehr Gewichte zu verarbeiten und sind dadurch entsprechend langsam. Die Größe spielt besonders bei Coding-Modellen eine entscheidende Rolle: Erstens will man die Modelle möglicherweise auch lokal ausführen, nachdem man sie potenziell feingetunt hat, und zweitens generieren diese Modelle sehr viele Token – je schneller das geht, desto kürzer ist die Wartezeit auf den generierten Code.
Weiterlesen nach der Anzeige
Mit vier Milliarden Parametern etwas größer, aber noch spezialisierter ist AesCoder, das mithilfe von GRPO (Group Relative Policy Optimization) auf die Erledigung von Web-Designaufgaben spezialisiert ist.
Konkurrenzfähige offene Modelle von Olmo
Auch wenn man häufig von Open-Source-Modellen spricht, sind meist lediglich die Gewichte der Modelle frei verfügbar. Nur wenige Anbieter veröffentlichen die Trainingsdaten und die Algorithmen, mit denen sie die Modelle trainiert haben. Neben Hugging Face mit SmolLM gibt es offene Trainingsdaten für das Modell Apertus aus der Schweiz und vor allem für die Olmo-Modelle vom Allen AI Institute. Letzteres braucht sich aufgrund der Investitionen durch Microsoft-Mitgründer Paul Allen keine großen Gedanken um die Finanzierung zu machen.
Besonders die jüngsten Olmo-3-Modelle integrieren viele innovative Techniken und machen damit einen gewaltigen Sprung nach vorn. Sie stehen in zwei Größen mit 7 und 32 Milliarden Parametern zur Verfügung. Das größere Modell gibt es in einer Reasoning-Variante, das kleinere zusätzlich noch als Instruction-Following-Modell ohne Reasoning. Für diejenigen, die die Modelle feintunen möchten, stellt Olmo anders als die meisten anderen Anbieter die Basismodelle zur Verfügung.
Im Vergleich zu anderen Modellen wie Qwen3 hat Olmo 3 deutlich weniger Token im Training erhalten: 5,9 Billionen aus dem Datensatz Dolma 3 Mix. Das macht sich leider in der Modellperformance bemerkbar, die nach ersten Tests nicht mit den Qwen3-Modellen in der gleichen Größenordnung mithalten kann. Die Strawberry-Challenge mit der Frage nach der Anzahl der „e“ in „Erdbeere“ (oder „r“ in „strawberry“) beantwortet das Modell konsequent falsch. Auch die deutschen Sprachfähigkeiten der kleineren Modelle sind nicht besonders gut ausgeprägt:

Bei der Antwort von Olmo 3 7B sind nicht nur die Inhalte falsch, auch die sprachliche Ausführung ist mangelhaft (Abb. 1).
(Bild: datanizing)

Das Modell Olmo 3 32B macht zwar ebenfalls Fehler, liegt aber häufiger richtig und formuliert deutlich bessere Sätze (Abb. 2).
(Bild: datanizing)
Der Artikel zu Olmo 3 enthält viele Details über die Architektur und das Training des Modells. Das gibt interessante Einblicke in den Trainingsprozess. Insbesondere das Post-Training ist sehr anspruchsvoll, weil Olmo dabei mit unterschiedlichen Datensets arbeitet, um die Qualität zu verbessern. Viele Innovationen gibt es beim Reinforcement Learning des Reasoning-Modells (bei Olmo „Thinking“ genannt).
Einige der GRPO-Optimierungen sind von anderen Modellen bekannt, kommen aber in dieser Kombination erstmals bei Olmo zum Einsatz. Das Modell setzt außerdem die weiterentwickelte Version des Verfahrens Reinforcement Learning with Verifiable Rewards (RLVR) ein, mit dem auch das neue Training von DeepSeek arbeitet. Mit RLVR kann man automatisiert überprüfen, ob Sprachmodelle die richtigen Ergebnisse vorhersagen. Die Besonderheit der weiterentwickelten Version ist, dass man damit Trainingsdaten automatisiert erzeugen kann – in Grenzen und bestimmten fachlichen Domänen.
Entwicklung & Code
Software Testing: Autismus und Softwaretests
Richard Seidl und Robert (Name geändert) sprechen in dieser Episode des Podcasts über Autismus im Softwaretesten. Robert bleibt anonym. Die Diagnose Autismus kam nach Jahren und mehreren Burnouts. Im Arbeitsalltag zehren Multitasking, spontane Meetings und ständige Kontextwechsel. Was hilft: klare Agenden, Pausen und Eins-zu-eins-Gespräche. Gleichzeitig zeigt Robert Stärken, die Tests schärfen wie eine Lupe: tiefer Fokus, Mustererkennung, starkes Gedächtnis und ehrliches Feedback. Fehler fallen ihm sofort auf, Ursachen denkt er systemisch.
Weiterlesen nach der Anzeige
Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.
Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Autismus und Software Test – Robert“ und steht auf YouTube bereit.
(mdo)
Entwicklung & Code
BOB-Konferenz 2026: Vorträge zur funktionalen Programmierung und mehr
Das Programm der dreizehnten BOB-Konferenz, die am 13. März 2026 wie gewohnt in Berlin im Scandic-Hotel Potsdamer Platz stattfindet, steht fest. Traditionell liegt die funktionale Programmierung im Fokus, in der Agenda für das nächste Jahr finden sich aber auch zahlreiche weitere Themen – auf eines verzichten die Organisatoren von der Active Group jedoch: KI. Die BOB 2026 soll ganz bewusst zeigen, „dass es immer noch IT jenseits der KI gibt“.
Weiterlesen nach der Anzeige
Vorträge und Tutorials
In seinem Eröffnungsvortrag zur BOB 2026 begibt sich Stefan Kaufmann auf die „Suche nach der Bedeutung in einem Magischen Konzept“. Der Medieninformatiker und Open-Data-Sachverständige geht dabei der Frage nach, was „Digitale Souveränität“ eigentlich genau sein soll.
Das weitere Programm der BOB-Konferenz umfasst 16 Talks und acht Tutorials, unter anderem zu Themen wie OCaml, Scala, Java, funktionale Softwarearchitektur und funktionale Programmierung mit SwiftUI. Über Beiträge zu Barrierefreiheit, UI-Entwicklung, Datenbank-Joins, Domain-Driven Design und Reactive Systems hinaus verspricht etwa Lutz Hühnken Einblicke in einige exotische Programmiersprachen noch jenseits von Haskell, Rust, Whitespace oder Brainf**k.
Registrierung mit Early-Bird-Rabatt eröffnet
Die BOB 2026 bietet sowohl englischsprachige als auch deutsche Vorträge und Tutorials an. Mit der Veröffentlichung des Programms hat die Registrierung begonnen. Bis zum 16. Januar 2026 gilt der Early-Bird-Rabatt. Auf Anfrage gibt es verschiedene ermäßigte Tickets sowie einige kostenlose für unterrepräsentierte Gruppen. Weitere Details lassen sich der Ankündigung entnehmen.
(map)
-
UX/UI & Webdesignvor 2 MonatenIllustrierte Reise nach New York City › PAGE online
-
Künstliche Intelligenzvor 2 MonatenAus Softwarefehlern lernen – Teil 3: Eine Marssonde gerät außer Kontrolle
-
Künstliche Intelligenzvor 2 Monaten
Top 10: Die beste kabellose Überwachungskamera im Test
-
UX/UI & Webdesignvor 3 MonatenFake It Untlil You Make It? Trifft diese Kampagne den Nerv der Zeit? › PAGE online
-
UX/UI & Webdesignvor 2 MonatenSK Rapid Wien erneuert visuelle Identität
-
Entwicklung & Codevor 4 WochenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
Künstliche Intelligenzvor 2 MonatenNeue PC-Spiele im November 2025: „Anno 117: Pax Romana“
-
Künstliche Intelligenzvor 2 MonatenDonnerstag: Deutsches Flugtaxi-Start-up am Ende, KI-Rechenzentren mit ARM-Chips
