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)

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.

Seit Jahren drängt Amazon.com mit unschönen Methoden Prime-Abos auf und erschwert deren Kündigung. Jetzt setzt es eine US-Strafe von einem halben Tagesumsatz. Das beläuft sich auf eine Milliarde US-Dollar und ist das Ergebnis eines Vergleichs zwischen dem Unternehmen, zwei Amazon-Managern und der US-Handelsaufsicht. Derweil zahlt die Neon-App 15 bis 30 Cent pro Minute dafür, dass sie Telefongespräche von Nutzern der App mitschneidet. Die Aufnahmen sollen für KI-Training weiterverkauft werden. In den USA ist die App sowohl für iPhones als auch Android-Smartphones derzeit enorm erfolgreich, aber die Vertragsklauseln sind ein juristisches Minenfeld. Ebenfalls in den USA wirft die dortige Börsenaufsicht den Käufern der insolventen US-Elektronikkette RadioShack vor, ein millionenschweres Schneeballsystem betrieben zu haben. Sie hätten sich durch weitere Investitionen aufgrund falscher Versprechungen finanziert und sich dabei auch persönlich bereichert – die wichtigsten Meldungen im kurzen Überblick.

Amazon.com soll Millionen Verbrauchern in den USA durch verwirrende und irreführende Designs kostenpflichtige Prime-Abonnements untergeschoben haben. Gleichzeitig soll der Online-Händler die Kündigung von Prime-Abos absichtlich erschwert haben. Mit diesen Vorwürfen hat die US-Handelsaufsicht FTC (Federal Trade Commission) Amazon 2023 verklagt. Das Unternehmen sowie zwei verantwortliche Amazon-Manager akzeptieren jetzt einen Vergleich, in dessen Rahmen der Konzern eine Milliarde US-Dollar Strafe zahlt. Das entspricht größenordnungsmäßig der Hälfte des weltweit erzielten Konzernumsatzes an einem durchschnittlichen Tag. Zusätzlich muss Amazon 1,5 Milliarden US-Dollar an übervorteilte US-Kunden zurückzahlen: Amazon.com zahlt Rekordstrafe für untergeschobene Prime-Abos.

Freiwillig zahlt hingegen „Neon – Money Talks„, die auf iPhones in den USA derzeit viertmeistinstallierte Anwendung, noch vor Google und WhatsApp. In der Sparte Soziale Netzwerke liegt sie sogar auf Platz 2, nur geschlagen von Threads. Der Grund für den rasanten Aufstieg ist Geld. Neon zeichnet die mithilfe der App initiierten Telefongespräche auf und schüttet dafür 15 US-Cent pro Minute aus, maximal 30 US-Dollar pro Tag. Die Aufnahmen, so der Betreiber, würden dann für Trainings Künstlicher Intelligenzen weiterverkauft, bereinigt um personenbezogene Daten. Allerdings gibt es kein Versprechen, dass die Aufnahmen geheim gehalten oder ausschließlich für KI-Trainings genutzt werden: App (ver)kauft Telefonaufnahmen für KI-Training – Lass Dich für 15 Cent abhören!

Gekauft wurde auch RadioShack, doch zwei E-Commerce-Unternehmer, die die US-Elektronikkette vor fünf Jahren aus der Insolvenz heraus erstanden haben, werden beschuldigt, ein sogenanntes Schneeballsystem betrieben zu haben. Die US-Börsenaufsichtsbehörde SEC wirft den Gründern des in Miami ansässigen Unternehmens Retail Ecommerce Ventures (REV), Alex Mehr und Tai Lopez, vor, Investoren um rund 112 Millionen US-Dollar betrogen zu haben. In der Klage heißt es, dass Mehr und Lopez zwischen 2020 und 2022 gegenüber Hunderten Investoren „wesentliche Falschangaben“ über die von ihnen erworbenen insolventen Unternehmen gemacht hätten. Zudem hätten sie etwa 16,1 Millionen US-Dollar an Investitionen für persönliche Zwecke abgezweigt, sagt die SEC: „RadioShack-Käufer betrieben ein Ponzi-Schema“.

Eine gute Nachricht gibt es für Windows-10-Nutzer: Der Konzern macht die „Extended Security Updates“ (ESU) ein Jahr lang für Privatnutzer im Europäischen Wirtschaftsraum (EU-Staaten und Island, Norwegen und Liechtenstein) bis zum 14. Oktober 2026 kostenfrei verfügbar. Das geht aus einem Schriftwechsel zwischen einer Verbraucherorganisation und Microsoft hervor. Microsoft hat das inzwischen bestätigt. Anders als etwa in den USA, wo das Update-Jahr 30 US-Dollar kosten soll, können Verbraucher in Europa die Sicherheitsupdates kostenfrei erhalten. Das sicherte Microsoft dem Verband Euroconsumers zu. Die Sicherheitsupdates bekommen allerdings nur Privatnutzer, die ihre Windows-10-Installation mit einem Microsoft-Konto verknüpft haben: Microsofts Windows-10-Sicherheitsupdates in Europa kostenlos.

Wer online einen Vertrag abschließt, etwa mit einem Energieversorger oder Telekommunikationsanbieter, erwartet in der Regel sofortigen Zugriff auf das Kundenportal. Dort sind schließlich alle Vertragsunterlagen, Rechnungen und persönliche Daten hinterlegt. Bleibt dieser Zugang gesperrt, stehen Verbraucher nicht rechtlos da. Ein systematisches Vorgehen hilft, den Anspruch auf Information und Transparenz über die eigenen Daten durchzusetzen. Dabei helfen klar formulierte Beschwerden, in denen Betroffene einschlägige Gesetze benennen und weitere Schritte ankündigen, etwa die Einbindung der Bundesnetzagentur. Wie Kunden genau vorgehen und auf welche Gesetze sie sich berufen sollten, besprechen wir in der aktuellen Folge des c’t-Verbraucherschutz-Podcasts Vorsicht Kunde: Kein Zugriff aufs Online-Kundenkonto.

Auch noch wichtig:

(fds)