Ingenieursphilosophie: Thompson & Ritchie – Eine Sache richtig gut machen

Kernpunkte

• Kleine, scharfe Werkzeuge. Jedes Programm macht eine Sache gut und sträubt sich gegen eine zweite; neue Anforderungen bekommen ein neues Werkzeug, keine weitere Option.
• Komposition statt Funktionsfülle. Macht entsteht durch das Verbinden von Programmen über die universelle Textschnittstelle – die Pipes –, sodass Leistungsfähigkeit in den Nahtstellen entsteht und nicht innerhalb eines einzelnen Programms. Der kanonische Satz „eine Sache richtig gut machen” stammt von Doug McIlroy, nicht von Thompson oder Ritchie.
• Portabilität durch C. Die Neufassung von Unix in C erlaubte es, das System auf neue Hardware zu bringen, indem man einen Compiler portierte, statt das ganze System neu zu schreiben – der Hauptgrund, warum Unix sich überall verbreitete.
• Vertrauen Sie nichts, was Sie nicht selbst gebaut haben. Thompsons „Reflections on Trusting Trust” zeigt, dass eine Hintertür im Binärprogramm leben kann, ohne Spur in irgendeinem Quelltext, den Sie prüfen – die Gründungserkenntnis der Lieferketten-Sicherheit.

Das Prinzip

„Schreibe Programme, die eine Sache tun und sie gut tun. Schreibe Programme, die zusammenarbeiten. Schreibe Programme, die mit Textströmen umgehen, denn das ist eine universelle Schnittstelle.” – Doug McIlroy, in seiner Zusammenfassung der Unix-Philosophie¹

Dieser Satz stammt nicht von Thompson und nicht von Ritchie. Geschrieben hat ihn Doug McIlroy, ihr Kollege in den Bell Labs und der Mann, der die Unix-Pipe erfand, in seinem Vorwort zur Sonderausgabe des Bell System Technical Journal von 1978.¹ Und doch ist er die sauberste Formulierung dessen, was Thompson und Ritchie tatsächlich bauten – und gerade der Grund, ihn voranzustellen statt einer Zeile aus dem Mund eines der beiden Männer, ist selbst der eigentliche Punkt: Die Unix-Philosophie war nie ein Manifest aus der Feder eines einzelnen Genies. Sie war eine Kultur, und die Kultur war das eigentliche Werk.

Das Prinzip besteht aus drei Schritten, und sie sind untrennbar. Machen Sie jedes Werkzeug klein und scharf – eine Aufgabe, gut erledigt, ohne den Ehrgeiz auf eine zweite. Machen Sie die Werkzeuge kombinierbar – die Ausgabe des einen ist die Eingabe des nächsten, sodass Leistungsfähigkeit aus der Kombination kommt und nicht daraus, dass ein Programm anschwillt. Und machen Sie die Schnittstelle zwischen ihnen universell – reinen Text, sodass jedes Werkzeug mit jedem anderen verbunden werden kann, ohne dass eines von der Existenz des anderen wissen muss. Die Macht liegt in den Nahtstellen, nicht in den Einzelteilen. Ein Programm, das Zeilen sortiert, weiß nichts über Web-Logs; ein Programm, das Duplikate zählt, weiß nichts über HTTP-Statuscodes; durch eine Pipe verbunden, beantworten sie eine Frage, für die keines von beiden gebaut wurde.

Das ist das Gegenteil des Instinkts, der die meiste Software hervorbringt. Der natürliche Sog geht dahin, ein Programm mehr tun zu lassen – eine Option hinzufügen, einen Modus hinzufügen, die nächste Anforderung in das einfalten, was man schon hat. McIlroys erste Regel benennt diesen Sog und verweigert sich ihm: „Um eine neue Aufgabe zu erledigen, baue von Grund auf neu, statt alte Programme durch das Hinzufügen neuer ‚Features’ zu verkomplizieren.”¹ Das gesamte System von Thompson und Ritchie ist der Beweis dafür, dass Einfachheit die Voraussetzung für alles andere ist und dass Komposition – nicht Funktionsfülle – der Weg ist, auf dem kleine Dinge mächtig werden.

Kontext

Unix entstand aus einem Scheitern. Mitte der 1960er Jahre hatten die Bell Labs mit dem MIT und General Electric an Multics gearbeitet, einem enorm ehrgeizigen Time-Sharing-Betriebssystem, das nahezu alles können sollte. Bis 1969 war es so komplex und so spät dran geworden, dass die Bell Labs ausstiegen, und die Forscher, die daran gearbeitet hatten – Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna –, blieben frustriert zurück, mit dem Verlust einer komfortablen interaktiven Rechenumgebung und einem starken Gespür dafür, wie man ein System nicht baut.²

Ken Thompson, geboren am 4. Februar 1943 in New Orleans, war 1966 nach einem Bachelor und Master in Elektrotechnik und Informatik an der UC Berkeley zu den Bell Labs gekommen.³ Dennis Ritchie, geboren am 9. September 1941 in Bronxville, New York, trat 1967 in das Computing Sciences Research Center ein.⁴ 1969 fand Thompson eine ausrangierte PDP-7 – einen kleinen, damals schon veralteten Minicomputer – und begann, darauf ein winziges Betriebssystem zu bauen, unter anderem, um ein selbst geschriebenes Spiel namens Space Travel laufen zu lassen. Thompson hat die Arbeitsteilung später unverblümt beschrieben: „Ich habe die erste von zwei oder drei Versionen von UNIX ganz allein gemacht. Und Dennis wurde zum Evangelisten.”³ Die erste Version war in PDP-7-Assembler geschrieben.

Der Name entstand als Scherz. Wo Multics „Multiplexed” war, war das neue System bewusst klein, also nannte die Gruppe es „UNICS” – Uniplexed Information and Computing Service – ein Wortspiel auf Kosten von Multics. Die Schreibweise verschob sich zu „Unix”, und Brian Kernighan, dem üblicherweise der Name zugeschrieben wird, merkte später an, dass sich niemand mehr genau erinnern kann, wie die endgültige Form zustande kam.² Die Kleinheit war kein Zufall und keine Beschränkung, die es zu überwinden galt. Sie war der Entwurf.

Das Werk

Unix und das Dateisystem

Das Erste, was Unix richtig machte, war ein Modell dessen, was die Ressourcen eines Rechners sind. Frühere Systeme behandelten Dateien, Geräte und Kommunikationskanäle als verschiedene Arten von Dingen, jedes mit seiner eigenen Spezialschnittstelle. Unix ließ sie in eins zusammenfallen. Es bot ein einziges hierarchisches Dateisystem – einen Baum von Verzeichnissen – und behandelte dann nahezu alles als Datei darin: nicht nur Dokumente, sondern auch Geräte und Kanäle zur Kommunikation zwischen Prozessen.² Ein Programm, das aus einer Datei lesen und in eine Datei schreiben konnte, konnte ohne jede Änderung aus einem Terminal, von einem Bandlaufwerk oder von einem anderen Programm lesen, denn für das Programm waren das alles nur Dateien.

Das ist die universelle Schnittstelle in ihrer ersten Gestalt. „Alles ist eine Datei” bedeutet, dass ein kleines Werkzeug keine andere Version für jede Art von Eingabe braucht; es braucht nur eine. Die Kosten der Komposition sinken auf nahezu null, weil jede Komponente bereits dieselbe Sprache spricht. Das hierarchische Dateisystem und die einheitliche open/read/write/close-Schnittstelle sind der Grund, warum der Rest der Philosophie überhaupt möglich war: Werkzeuge, die jeweils einen maßgeschneiderten Anschluss verlangen, lassen sich nicht zusammensetzen.

C und Portabilität

Der zweite Durchbruch bestand darin, das System portabel zu machen, und das erforderte eine Sprache. Ritchie schuf C zwischen 1969 und 1973, indem er es aus Thompsons Sprache B weiterentwickelte, die ihrerseits von BCPL abstammte.⁴ B war typenlos und interpretiert; C fügte Datentypen und Strukturen hinzu und kompilierte zu effizientem Maschinencode, nah genug an der Hardware, um ein Betriebssystem darin zu schreiben, abstrakt genug, um zwischen Maschinen zu wandern.

Der entscheidende Moment kam um 1973, als Version 4 von Unix in C neu geschrieben wurde.² Bis dahin war ein Betriebssystem Assemblersprache, dauerhaft an die eine Maschine geschweißt, für die es geschrieben war. Unix in einer Hochsprache neu zu schreiben, kam einer Ketzerei nahe – die herrschende Meinung besagte, Systemcode müsse handoptimierter Assembler sein, sonst sei er zu langsam. Thompson und Ritchie taten es trotzdem, und der Lohn war Portabilität: Unix ließ sich nun auf neue Hardware bringen, indem man einen Compiler portierte, statt das gesamte System neu zu schreiben. Diese eine Entscheidung ist der Hauptgrund, warum Unix in jeden Winkel der Datenverarbeitung vordrang, während seine Zeitgenossen an ihr ursprüngliches Blech genietet blieben. 1978 veröffentlichten Ritchie und Kernighan The C Programming Language – „K&R” –, das knappe, präzise Buch, das eine ganze Generation lehrte, C zu schreiben, und bis heute ein Vorbild technischer Prosa bleibt.⁵ Das System selbst kündigten Thompson und Ritchie der breiteren Welt im Juli 1974 in den Communications of the ACM an, im Aufsatz „The UNIX Time-Sharing System”.⁶

Pipes und das Kompositionsmodell

Wenn das Dateisystem die Werkzeuge dieselbe Sprache sprechen ließ, so brachten Pipes sie dazu, miteinander zu reden. Die Idee stammte von Doug McIlroy: Jahrelang hatte er auf einen Weg gedrängt, Programme von Ende zu Ende zu verbinden, sodass die Ausgabe des einen direkt in das nächste fließt, wie aneinandergesteckte Gartenschlauchstücke. Thompson setzte sie 1973 um – bekanntermaßen in einer einzigen Nacht – und fügte den Systemaufruf pipe() und den Operator | zur Shell hinzu.⁷ McIlroy beschrieb, was als Nächstes geschah: „Am nächsten Tag erlebten wir eine unvergessliche Orgie der Einzeiler, als alle in der Begeisterung des Klempnerns einstimmten.”⁷

Diese Orgie der Einzeiler ist die Philosophie in Aktion. Niemand musste ein neues Programm schreiben; man entdeckte, dass sich die kleinen Programme, die man schon hatte, aneinanderreihen ließen, um Fragen zu beantworten, für die keines von ihnen entworfen worden war. Eine Pipeline wie grep, dann cut, dann sort, dann uniq -c, dann sort -rn, dann head besteht aus sechs Stufen, jede unwissend über die anderen, jede macht eine Sache, von links nach rechts durch einen Textstrom zusammengesetzt. Die Leistungsfähigkeit entsteht emergent. Sie lebt im |, nicht in irgendeinem einzelnen Befehl.

Das ist die tiefste Idee im ganzen System. Die meiste Software wächst durch Anlagerung: Ein Programm nimmt jede neue Anforderung in sich auf, bis es ein Monolith ist, den nur seine Autoren verstehen. Unix wächst durch Komposition: Das System bleibt ein Baukasten kleiner Teile, und neue Leistungsfähigkeit entsteht aus neuen Anordnungen alter Teile. Der Textstrom ist die universelle Schnittstelle, die die Anordnung kostenlos macht. Das ist der Grund, warum eine Unix-Shell fünfzig Jahre später noch immer eine der ausdrucksstärksten Programmierumgebungen ist, die es gibt – nicht trotz, sondern weil sie aus winzigen Programmen mit jeweils nur einem Zweck besteht.

Trusting Trust und das spätere Vermächtnis

1983 teilten sich Thompson und Ritchie den ACM Turing Award. Die Begründung lautet „für ihre Entwicklung der allgemeinen Theorie von Betriebssystemen und insbesondere für die Implementierung des Betriebssystems UNIX”, und die Stellungnahme des Komitees benennt das Prinzip genau: „Der Erfolg des UNIX-Systems beruht auf seiner geschmackvollen Auswahl einiger weniger Schlüsselideen und deren eleganter Umsetzung.”⁸ Geschmackvolle Auswahl einiger weniger Schlüsselideen – der Preis wurde im Grunde für Zurückhaltung verliehen.

Thompsons eigene Turing-Vorlesung, 1984 veröffentlicht als „Reflections on Trusting Trust”, richtete dieselbe minimalistische Strenge auf die Sicherheit. Er zeigte, dass man einem Compiler beibringen kann, eine Hintertür in das Programm login einzufügen – und die Einfügung dieser Hintertür in jeden künftigen Compiler einzubauen, den er kompiliert –, sodass der Schadcode allein im Binärprogramm lebte, ohne Spur in irgendeinem Quelltext, den Sie prüfen könnten. Sein Schluss ist einer der meistzitierten Sätze der Informatik: „Sie können Code nicht trauen, den Sie nicht völlig selbst erstellt haben … Keine noch so gründliche Überprüfung oder Kontrolle auf Quelltextebene schützt Sie davor, nicht vertrauenswürdigen Code zu verwenden.”⁹ Es ist der Gründungstext des Denkens über Lieferketten-Sicherheit – die Erkenntnis, dass das, worauf Sie vertrauen, nicht der Quelltext ist, sondern die gesamte Werkzeugkette, die das Binärprogramm hervorgebracht hat.

Die späteren Laufbahnen der beiden verlängerten dieselben Instinkte. Thompson blieb rastlos: In den Bell Labs baute er das Betriebssystem Plan 9 (das „alles ist eine Datei” noch weiter trieb, über ein Netzwerk hinweg), den Editor ed und die praktische Theorie der regulären Ausdrücke und grep. 1992 entwarfen er und Rob Pike UTF-8 – die Textkodierung mit variabler Breite, die heute nahezu sämtlichen Text der Welt trägt – an einem einzigen Abend, der Legende nach auf einem Tischset skizziert.³ Und 2007 entwarf Thompson bei Google gemeinsam mit Robert Griesemer und Rob Pike die Programmiersprache Go, die 2009 öffentlich vorgestellt wurde: eine bewusst kleine, schnell kompilierende, kombinierbare Sprache, die sich wie eine bewusste Rückkehr zu den Werten von Unix liest.¹⁰ Ritchie, der am 12. Oktober 2011 starb, hinterließ eine stillere, aber durchdringendere Spur; wie der Historiker Paul Ceruzzi es ausdrückte: „Hätten Sie ein Mikroskop und könnten in einen Computer hineinsehen, sähen Sie seine Arbeit überall darin.”⁴

Die Methode

Die Methode ist über vierzig Jahre und bei zwei Männern hinweg gleichbleibend, die sie selten erklären mussten.

Bauen Sie kleine, scharfe Werkzeuge. Jedes Programm erledigt eine Aufgabe. Die Disziplin liegt in der Verweigerung: Taucht eine neue Anforderung auf, ist die Antwort ein neues Werkzeug, keine neue Option, die an ein altes geschraubt wird. „Baue von Grund auf neu, statt alte Programme zu verkomplizieren.”¹

Komponieren Sie, statt anzulagern. Leistungsfähigkeit soll aus der Kombination entstehen. Ein System bleibt begreifbar, solange es ein Baukasten kleiner Teile ist und durch Umordnung wächst, nicht dadurch, dass ein Teil zum Monolithen anschwillt.

Standardisieren Sie die Schnittstelle, nicht die Werkzeuge. Der vereinheitlichende Schritt – „alles ist eine Datei”, reine Textströme zwischen Programmen – besteht darin, die Verbindung universell zu machen, damit die Komponenten einander gegenüber unwissend bleiben können. Billige Nahtstellen sind es, die kleine Teile mächtig machen.

Wählen Sie einige wenige Schlüsselideen, mit Geschmack. Die Formulierung des Turing-Komitees war keine Schmeichelei; sie war die Methode. Unix ist berühmt für das, was es weggelassen hat. Portabilität durch C, die Datei-Abstraktion, die Pipe – eine Handvoll Entscheidungen, jede von enormem Gewicht, mit dem Ballast bewusst abwesend.

Misstrauen Sie dem, was Sie nicht prüfen können. „Trusting Trust” ist die Methode nach innen gerichtet: Einfachheit und Lesbarkeit sind nicht nur ästhetische Tugenden, sondern die einzige reale Grundlage für Vertrauen, denn Komplexität ist der Ort, an dem sich das verbergen kann, was Sie nicht sehen.

Einflusskette

Wer sie prägte

Multics, als Gegenbeispiel. Der mit Abstand prägendste Einfluss war ein System, das sie mitbauten und dann verließen. Multics lehrte Thompson und Ritchie auf die teuerstmögliche Weise, was Überehrgeiz kostet – und Unix ist zu großen Teilen eine disziplinierte Reaktion dagegen. (Prägender Einfluss)

Doug McIlroy. Als Leiter des Computing Sciences Research Center erfand McIlroy die Pipe, formulierte die Philosophie des „eine Sache richtig gut machen” schriftlich aus und wirkte als unermüdlicher Geschmackskritiker der Gruppe. Das Kompositionsmodell ist ebenso sehr seines wie das von irgendjemandem, und er ist die richtige Zuschreibung für die kanonische Formulierung der Philosophie. (Direkter Einfluss)

Die Forschungskultur der Bell Labs. Eine kleine Gruppe von Gleichgesinnten, mit Freiheit und guten Maschinen ausgestattet, die untereinander auf Eleganz optimierten statt auf einen Produktfahrplan. Unix wurde nicht vom Management spezifiziert; es lagerte sich aus einer Kultur an, die das Geschmackvolle schätzte und das Aufgeblähte verspottete. (Prägender Einfluss)

Wen sie prägten

Jeder Unix-Nachfahre. Linux, die BSDs und macOS sind direkte Erben in gerader Linie; das System, das Thompson und Ritchie auf einer ausrangierten PDP-7 schrieben, läuft heute auf den meisten Servern, Telefonen und eingebetteten Geräten der Erde.

Jede Shell und jede Kommandozeile. Die Pipe und das Kompositionsmodell sind die tägliche Arbeitsumgebung praktisch jedes Programmierers und Systemadministrators, fünfzig Jahre später – in ihrem Kern unverändert, weil der Kern richtig war.

C und seine Kinder. C wurde zur Lingua franca der Systemprogrammierung, und seine Syntax und Semantik hallen durch C++, Java, Go, Rust und das meiste, was heute geschrieben wird. K&R bleibt die Vorlage dafür, wie man eine Sprache dokumentiert.

Die Unix-Philosophie selbst. „Eine Sache richtig gut machen” wuchs über Unix hinaus und wurde zu einem allgemeinen Entwurfsprinzip – für Microservices, für Kommandozeilenwerkzeuge, für den buildfreien Ansatz kleiner Teile im Web und dafür, wie man KI-Systeme klein genug hält, um sicher und lesbar zu bleiben.

Der rote Faden

Thompson und Ritchie sind der systemnahe Ausdruck derselben Überzeugung, die sich durch diese Reihe zieht. Edsger Dijkstra argumentierte, dass Einfachheit die Voraussetzung für Zuverlässigkeit ist; Unix ist dieses Argument kompiliert und ausgeliefert – ein Kern aus einigen wenigen Schlüsselideen, klein genug gehalten, um ihm zu trauen. Linus Torvalds’ „guter Geschmack”, die Neufassung, in der der Sonderfall verschwindet, ist „eine Sache richtig gut machen” innerhalb einer einzigen Funktion statt über eine Pipeline hinweg; und Torvalds baute Linux und Git unmittelbar auf dem Fundament, das diese beiden legten. John Carmacks schneller, einfacher Kern ist dieselbe Subtraktion, gerichtet auf die Leistungsgrenze der Hardware. Und Yukihiro Matsumotos Entwurf von Ruby für das menschliche Glück ist der Unix-Instinkt – kombinierbare, ausdrucksstarke kleine Teile –, hinaufgetragen in eine Hochsprache. Der rote Faden ist ein einziger Satz: Macht soll aus dem Zusammensetzen kleiner, begreifbarer Teile über eine universelle Schnittstelle kommen, nicht daraus, dass ein einzelnes Teil anschwillt. (Reihenbrücke)

Was ich daraus mitnehme

Die Lektion, die mir bleibt, ist, dass die Schnittstelle die Architektur ist. Wenn ich heute irgendetwas entwerfe – einen Agenten, eine Werkzeugschleife, eine Pipeline aus Skripten –, ist die Versuchung immer, eine Komponente klüger zu machen, die nächste Anforderung in das einzufalten, was ich schon habe, bis es zu einem Monolithen wird, den nur ich verstehe. Der Unix-Schritt ist das Gegenteil: Halte jedes Teil klein genug, um es vollständig zu verstehen, und lege die Intelligenz in die Art, wie die Teile sich verbinden. Eine saubere, universelle Nahtstelle zwischen dummen Teilen schlägt jedes Mal ein cleveres Teil ohne saubere Nahtstellen. Das ist derselbe Maßstab wie der, dass Qualität die einzige Variable ist – die Frage lautet nie „kann dieses eine Programm mehr tun?”, sondern „besteht dieses System noch aus Teilen, über die ich nachdenken kann?”.

In der Welt, in der ich jetzt baue – KI-Agenten, durch Werkzeuge und Text miteinander verdrahtet –, ist der Entwurf von Thompson und Ritchie relevanter, als er es mit über fünfzig Jahren sein dürfte. Ein Agent ist ein kleines Programm; ein Werkzeug ist ein kleines Programm; was sie mächtig macht, ist eine saubere, universelle Schnittstelle zwischen ihnen, die heute meist aus strukturiertem Text besteht. Das ist die Pipe, neu gebaut. Und „Trusting Trust” ist die Warnung, die ich am ernstesten nehme: Wenn ein System Code schneller erzeugt, als irgendjemand ihn lesen kann, ist die einzige dauerhafte Grundlage für Vertrauen, die Teile klein und die Nahtstellen lesbar zu halten, denn Komplexität ist genau der Ort, an den sich das verzieht, was Sie nicht sehen können. Diese Überzeugung – dass Geschmack ein technisches System ist und dass kleine, kombinierbare, prüfbare Teile keine Annehmlichkeit, sondern das ganze Spiel sind – verläuft schnurgerade von einer PDP-7 von 1969 zu einem Agentenrahmen von 2026.

FAQ

Was ist die Unix-Philosophie?

Die Unix-Philosophie ist ein Entwurfsansatz, der auf kleinen Werkzeugen mit einem einzigen Zweck aufbaut, die sich über eine universelle Schnittstelle zusammensetzen. Ihre kanonische Formulierung, von Doug McIlroy aus dem Jahr 1978, lautet: „Schreibe Programme, die eine Sache tun und sie gut tun. Schreibe Programme, die zusammenarbeiten. Schreibe Programme, die mit Textströmen umgehen, denn das ist eine universelle Schnittstelle.” Der erste Grundsatz lautet, ein neues Werkzeug zu bauen, statt einem bestehenden Funktionen hinzuzufügen, und die Macht des Systems entsteht aus der Kombination kleiner Teile – über Pipes und reinen Text – und nicht daraus, dass ein einzelnes Programm anschwillt.¹

Hat Ken Thompson „eine Sache richtig gut machen” gesagt?

Nein. Die Maxime „eine Sache richtig gut machen” und die weiter gefasste Unix-Philosophie wurden schriftlich von Doug McIlroy formuliert, dem Leiter des Computing Sciences Research Center der Bell Labs, in seinem Vorwort zur Sonderausgabe des Bell System Technical Journal von 1978 über Unix.¹ Thompson und Ritchie bauten das System, das die Philosophie verkörpert, und McIlroy – der auch die Unix-Pipe erfand – war ihr klarster Formulierer und der hauseigene Geschmackskritiker der Gruppe. Die Maxime Thompson zuzuschreiben, ist eine gängige, aber falsche Abkürzung.

Was schufen Thompson und Ritchie tatsächlich?

Ken Thompson baute ab 1969 die ersten Versionen des Betriebssystems Unix auf einer PDP-7 und schuf später die Sprache B, den Editor ed, die praktische Suche mit regulären Ausdrücken (grep), das System Plan 9, UTF-8 (mit Rob Pike) und entwarf bei Google Go mit.³ Dennis Ritchie schuf die Programmiersprache C (1969–1973), benutzte sie, um Unix 1973 neu zu schreiben und portabel zu machen, und verfasste 1978 gemeinsam mit Brian Kernighan The C Programming Language.⁴⁵ Den ACM Turing Award von 1983 teilten sie sich für Unix.⁸

Was ist „Reflections on Trusting Trust”?

Es ist Ken Thompsons Vorlesung zum ACM Turing Award von 1984, veröffentlicht in den Communications of the ACM. Er zeigte, dass man einen Compiler dazu bringen kann, eine versteckte Hintertür in ein Programm einzufügen und diese Hintertür jedes Mal zu reproduzieren, wenn er eine neue Version seiner selbst kompiliert – sodass der Schadcode allein im Binärprogramm existierte und keine Spur in irgendeinem Quelltext hinterließ, den Sie lesen könnten. Sein Schluss: „Sie können Code nicht trauen, den Sie nicht völlig selbst erstellt haben … Keine noch so gründliche Überprüfung oder Kontrolle auf Quelltextebene schützt Sie davor, nicht vertrauenswürdigen Code zu verwenden.” Es ist ein Gründungstext der Software-Lieferketten-Sicherheit.⁹

Quellen