Der Kanarienvogel im Code

Ein Versprechen, das sich prüfen lassen muss

Dokumentation ist geduldig. Man kann in ein Handbuch schreiben, dass ein Programm nur mit bestimmten, eingerichteten Zielen spricht, und das mag sogar stimmen — bis zur nächsten Abhängigkeit, die eine winzige Funktion mitbringt, die irgendwo im Hintergrund still eine Verbindung öffnet, ohne dass es jemandem auffällt. Genau dieses Szenario ist in der Softwarelieferkette real: Eine harmlos wirkende Bibliothek, tief unten in einem Abhängigkeitsbaum, wird kompromittiert oder verhält sich anders, als ihre Beschreibung suggeriert, und beginnt, Daten irgendwohin zu senden, wo sie nichts zu suchen haben.

Für ein Werkzeug wie JiCo, das ohnehin mit sensiblen Jira- und Confluence-Daten arbeitet, wäre ein solcher stiller Abfluss der worst case schlechthin — und ausgerechnet der Fall, gegen den ein Versprechen im Handbuch am wenigsten hilft. Deshalb steht neben der Beschreibung ein tatsächlicher, automatisierter Test, der genau das prüft.

Ein präparierter Eindringling, extra dafür gebaut

Der Test — im Code liebevoll „Kanarienvogel" genannt, in Anlehnung an das Tier, das in Bergwerken vor unsichtbarer Gefahr warnte — simuliert genau das befürchtete Szenario: eine präparierte Bibliothek, die aktiv versucht, Rohdaten aus dem Prozess auszuleiten. Läuft dieser Test in der Continuous-Integration-Pipeline, bei jedem einzelnen Commit, ohne Netzwerkzugriff, und prüft er, dass tatsächlich nichts den Prozess verlässt.

Das Entscheidende an diesem Testaufbau ist, dass er ohne Netz läuft. Es wird nicht geprüft, ob ein Zielserver die Daten empfangen hat — das wäre eine schwächere, nachträgliche Kontrolle. Geprüft wird direkt am Ausgang des Prozesses, ob überhaupt versucht wurde, etwas zu senden. Ein Test, der auf einem echten Netzwerkaufruf beruht, könnte durch einen einzelnen erfolgreichen Blockversuch täuschen; ein netzloser Test hat diese Schwäche nicht, weil er den Versuch selbst am Ursprung abfängt.

Die zweite Schicht: eine Wache, die zur Laufzeit mitläuft

Der Kanarienvogel prüft das Verhalten im Test. Im tatsächlichen Betrieb übernimmt eine zweite, unabhängige Schicht dieselbe Aufgabe: der Egress-Wächter. Er läuft im laufenden Prozess mit und lässt grundsätzlich nur Verbindungen zum eigenen Loopback, zu ausdrücklich eingerichteten Hosts und zu den eigenen, über ihren kanonischen Pfad erkannten Programmen zu — mit einer Vorgabe, die im Zweifel sperrt, statt durchzulassen. Jeder Versuch daneben wird nicht nur verhindert, sondern auch im Audit-Trail und im Protokoll festgehalten, sichtbar und nachträglich überprüfbar.

Diese zwei Schichten ergänzen sich, statt sich zu wiederholen: Der Kanarienvogel prüft in der Entwicklung, bevor Code überhaupt ausgeliefert wird. Der Egress-Wächter prüft im Betrieb, bei jeder einzelnen Kundin, mit ihrer eigenen tatsächlichen Konfiguration. Ein Fehler, der durch die eine Schicht rutscht, muss noch immer durch die andere.

Warum nicht einmal die Lizenzprüfung eine Ausnahme bekommt

Der eigentliche Härtetest für eine solche Regel ist nicht der offensichtliche Fall, sondern die naheliegende Ausnahme. Bei JiCo wäre das die eigene Lizenzprüfung gewesen — ein legitimer, eigener Zweck, für den man versucht sein könnte, dem Egress-Wächter eine kleine Sonderregel einzuräumen. Genau das passiert nicht: Die Lizenz holt JiCo nur auf Klick beim Lizenz-Portal ab — wie „Auf Update prüfen“ und den optionalen Fernzugriff eine eng begrenzte, benannte Ausnahme, stets von einem Menschen ausgelöst und nie mit Jira-Inhalten; geprüft wird die Lizenz anschliessend vollständig offline. Wer im Firewall-Protokoll nachsieht, findet für JiCo selbst keine Verbindung, die nicht zum eingerichteten Jira-Host oder einem ausdrücklich freigegebenen Ziel gehört.

Wo die Bibliotheken selbst herkommen

Der Kanarienvogel prüft das Verhalten zur Laufzeit. Eine weitere Schicht setzt schon davor an, bei der Frage, welche fremden Bibliotheken überhaupt in JiCo landen dürfen. Jede Abhängigkeit wird ausschließlich mit einem geprüften kryptografischen Hash eingebunden — eine nachträglich ausgetauschte oder manipulierte Version derselben Bibliothek würde beim nächsten Bauversuch schlicht nicht mehr passen und den Bau abbrechen lassen, statt unbemerkt durchzurutschen. Aus genau diesem Lockfile leitet sich außerdem automatisch eine Stückliste ab (SBOM, Software Bill of Materials) — eine vollständige Liste aller enthaltenen Komponenten, wie sie für Audits und Sicherheitsprüfungen ohnehin gebraucht wird, statt separat von Hand gepflegt zu werden. Aktualisiert wird diese Liste dabei nie einfach nebenbei in einem laufenden Thema, sondern als eigener, klar erkennbarer Vorgang mit eigenem Pull Request.

Ein Baustein unter mehreren, nicht der einzige

Der Kanarienvogel und der Egress-Wächter beantworten eine Frage sehr konkret: Verlässt etwas den Prozess, das nicht verlassen sollte? Sie beantworten damit ausdrücklich nicht jede denkbare Sicherheitsfrage — ein gezielter Angriff auf JiCo selbst, ausgeführt von jemandem mit Zugriff auf denselben Rechner, ist eine andere Kategorie von Bedrohung, für die andere Maßnahmen wie Betriebssystem-eigene Netzwerkregeln je Programm zuständig sind. Das steht so auch offen im eigenen Prüfprogramm für Sicherheitsverantwortliche — als benannte Grenze, nicht als verschwiegene Lücke.

Zusammen mit den ebenfalls hash-gesperrten Abhängigkeiten und der aus dem Lockfile abgeleiteten Stückliste (SBOM) ergibt sich daraus kein einzelner Beweis, sondern eine Kette überlappender Kontrollen — jede für sich unvollständig, gemeinsam aber deutlich schwerer zu umgehen als ein einzelnes Versprechen im Handbuch.