Wenn Softwarefehler auftreten, passiert das meistens unbemerkt und unauffällig, gelegentlich aber auch höchst spektakulär und kostspielig. Von fehlgeschlagenen Raumfahrtmissionen über Börsencrashs bis hin zu fehlerhaften medizinischen Geräten gibt es eine lange Liste berühmter Softwarepannen. Wer sie studiert, stellt schnell fest: Die meisten dieser Fehler wirken auf den ersten Blick wie einmalige Katastrophen, sind in Wahrheit aber Wiederholungen bekannter Muster.

Diese Artikelserie stellt neun dieser typischen Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Der Bug in der Rechenanlage

Eine der beliebtesten Anekdoten der Softwaregeschichte ist die von Grace Hopper und der berühmten Motte. 1947 arbeitete Grace Hopper an der Harvard-Mark-II-Rechenanlage, in der sich eine echte Motte in einem Relais verfangen hatte. Nachdem ein Teammitglied sie gefunden und entfernt hatte, klebte dieser sie mit dem Kommentar „first actual case of bug being found“ ins Protokollbuch. Dieses Protokollbuch wird heute in einem Smithsonian Museum in Washington ausgestellt.

Diese Episode ist zu einer Legende der IT-Kultur geworden – das Wort „Bug“ wurde damals aber nicht erfunden. Schon Thomas Edison sprach 1878 in Briefen über „Bugs“ in Maschinen, also kleine, schwer zu findende Fehler. Trotzdem prägte Grace Hopper die Vorstellung, dass Softwarefehler etwas sind, das man wie ein Insekt finden und entfernen kann.

Doch die Realität ist oft subtiler: Bugs sind meist Symptome systematischer Schwächen. Hinter fast jeder spektakulären Panne steckt ein Muster, das sich in abgewandelter Form immer und immer wieder findet. Deshalb lohnt sich ein Blick nicht nur auf die einzelnen Vorfälle, sondern vor allem auf die Fehlerkategorien, die sie repräsentieren.

Teil 1: Einheiten und Maße: Wenn Zahlen irreführend werden

Am Beginn dieser Serie steht ein Thema, mit dem Entwicklerinnen und Entwickler jeden Tag wie selbstverständlich hantieren – und das vielleicht gerade deshalb so gefährlich ist. Es wird allzu leicht unterschätzt: Die Rede ist vom Umgang mit Zahlen.

Kaum ein Beispiel für Softwarefehler wird so häufig genannt wie der Verlust der NASA-Sonde Mars Climate Orbiter im Jahr 1999. Ziel der Mission war es, die Marsatmosphäre zu untersuchen. Nach einer monatelangen Reise näherte sich die Sonde dem Planeten – und verglühte. Die Ursache war fast grotesk simpel: Die Entwickler hatten in der Software metrische und imperiale Maßeinheiten verwechselt. Das Ergebnis war ein systematischer Navigationsfehler, der die Sonde auf eine zu niedrige Umlaufbahn führte.

Dieser Vorfall zeigt, dass Zahlen ohne Kontext gefährlich sind. Eine Zahl wie 350 kann das Maß einer Geschwindigkeit, einer Kraft oder einer Energie bedeuten – oder eben etwas ganz anderes. Solange eine Software Daten als rohe Zahlen behandelt, besteht die Gefahr, dass jemand sie falsch missinterpretiert. In großen Projekten mit mehreren Teams potenziert sich dieses Risiko, wenn jede Seite implizite Annahmen trifft, die niemand irgendwo explizit dokumentiert oder technisch abgesichert hat.

Aus Sicht der Qualitätssicherung sind solche Fehler besonders tückisch, denn Unit Tests können ebenso wie Integrationstests durchaus korrekt durchlaufen – solange die falschen Einheiten konsistent falsch sind. Das Problem zeigt sich oft erst in der Realität, wenn Sensoren, Aktoren oder externe Systeme ins Spiel kommen, deren Daten den zuvor getroffenen Annahmen nicht entsprechen. Die Lehre aus diesem Vorfall ist klar: Zahlen brauchen Bedeutung. Moderne Programmiersprachen und Frameworks bieten verschiedene Möglichkeiten, diese Bedeutung explizit zu machen:

• Value Objects oder Wrapper-Typen: Statt double oder float kommt ein eigener Typ wie ForceInNewton oder VelocityInMetersPerSecond zum Einsatz. Damit wird die Einheit Teil der Typinformation. Manche Programmiersprachen, beispielsweise F#, bieten Unterstützung für Einheiten sogar bereits als Teil der Sprache an.
• Bibliotheken für physikalische Einheiten: Sie ermöglichen automatische Umrechnungen und erzwingen korrekte Kombinationen.
• Schnittstellenverträge und End-to-End-Tests: API-Definitionen sollten Einheiten benennen. Tests mit echten Daten decken Diskrepanzen auf, bevor sie zu Katastrophen führen.

Neben diesen technischen Maßnahmen spielt außerdem auch die Teamkultur eine große Rolle. Projekte, die früh auf eine gemeinsame Sprache für ihre Daten achten – sei es durch Domain-Driven Design (DDD) oder einfach durch konsequente Dokumentation –, vermeiden solche Fehler deutlich häufiger.

Der Verlust des Mars Climate Orbiter hat die NASA hart getroffen. Doch er hat auch dazu geführt, dass Entwicklerinnen und Entwickler zumindest in manchen Projekten stärker auf Einheitenfehler achten und diese Fehlerklasse seither (hoffentlich) ernster nehmen. Für Softwareteams im Alltag gilt dasselbe: Wer Zahlen ohne Kontext weitergibt, lädt zum nächsten Bug geradezu ein.

Im nächsten Teil lesen Sie: Überlauf, Arithmetik und Präzision: Wenn Zahlen kippen

(who)

Mit dem rasanten Wachstum von APIs steigt auch die Notwendigkeit für deren qualitativ hochwertige Entwicklung. Doch viele APIs sind schlecht programmiert, was zu einer ineffizienten Nutzung und schlechter Developer Experience führt. In unserem Workshop API-Design und -Entwicklung mit HTTP, REST und OpenAPI zeigen wir Ihnen, wie Sie effiziente und benutzerfreundliche APIs entwickeln und geben Ihnen Best Practices für das Design von HTTP-basierten REST-Schnittstellen.

Der Workshop umfasst eine Einführung in HTTP und REST sowie das Design von RESTful APIs. Sie lernen, wie Sie HTTP- und REST-Standards korrekt anwenden, standardisierte Referenzdokumentationen erstellen und für API-Konsistenz sorgen. Sie machen sich mit der OpenAPI-Spezifikation vertraut und lernen, wie Sie OpenAPI-Beschreibungen für REST APIs erstellen und die Qualität dieser Beschreibungen überprüfen können.

Interaktives Lernen und Üben

Der Workshop ist interaktiv gestaltet und besteht aus Theorie- und Praxisblöcken. Während der Übungen arbeiten Sie in Kleingruppen und wenden die Standards und Werkzeuge praktisch an. Anhand von Beispielen aus der langjährigen Praxiserfahrung der Trainer können Sie das Gelernte direkt anwenden und vertiefen.

Diese Schulung richtet sich an Entwickler und Entwicklerinnen, die HTTP, REST und OpenAPI noch nicht angewendet haben oder ihr Wissen bezüglich dieser Standards auffrischen möchten. Besonders wichtig sind diese Standards für Entwicklungsteams, deren APIs von anderen Teams oder sogar Externen verwendet werden.

Ihre Trainer Daniel Kocot und Miriam Greis arbeiten gemeinsam in einem Team der codecentric AG und betreuen dort Kunden im Bereich API-Entwicklung mit dem Schwerpunkt API Experience & Operations. Ein besonderes Augenmerk liegt dabei auf der kontinuierlichen Verbesserung und Automatisierung von Prozessen.

(ilk)

Beim Thema Agentic AI und Sicherheit denken viele zuerst und oft sogar ausschließlich an Prompt Injections. Die sind aber nur eine von vielen Sicherheitsherausforderungen bei Agentic AI – und oft nicht einmal die dringendste. Agentic-AI-Systeme sind komplex und bestehen aus vielen einzelnen Bestandteilen. Aus Securitysicht erben diese Systeme damit die Sicherheitsanforderungen aller beteiligten Komponenten. Die folgende Abbildung zeigt die Schichten, die dieser Artikel näher betrachtet.

Die Systemschicht umfasst alle allgemeinen Supportkomponenten wie Bibliotheken, Compute- und Netzwerkressourcen. Die Datenschicht beinhaltet den Lang- und Kurzzeitspeicher, sowohl für die Nutzung durch Agenten als auch für die Protokollierung. Die Modelle selbst und ihre Trainingsdaten sind ebenfalls in dieser Schicht beheimatet. In der Agentenschicht interagieren die KI-Agenten untereinander und mit den verfügbaren Werkzeugen.

Die Orchestrationsschicht verwaltet Aktionen im Zusammenhang mit der Verarbeitung, wie die Aktivierung ausgewählter Agenten zur Erarbeitung von (Teil-)Ergebnissen. Alle für Benutzer, Administratoren und APIs von außen sichtbaren Schnittstellen ins Agentic-AI-System befinden sich auf der Interaktionsschicht. Zu den externen Einheiten gehören Bibliotheken von Drittanbietern, öffentliche Trainingsdatensätze, externe Tools und vieles mehr. Aus Sicht der Lieferkettensicherheit sind dies die ersten externen Einstiegspunkte.

Das war die Leseprobe unseres heise-Plus-Artikels „Künstliche Intelligenz: Agentic AI aus Securitysicht – Angriffe und Verteidigung“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.