Inhalt (4 Abschnitte)
Alle Sicherheitsanalysen Ihrer Abhängigkeiten beruhen auf derselben Annahme: Die Lock-Datei sagt die Wahrheit. Sie hält Version für Version, Hash für Hash fest, was Ihre Anwendung tatsächlich mitbringt. Der Scanner liest sie und fällt sein Urteil.
Vor ein paar Tagen haben wir entdeckt, dass diese Annahme in unseren eigenen CI-Pipelines falsch sein konnte, ohne dass eine Warnleuchte anging. Folgendes ist passiert.
Die Wiederherstellung, die korrigiert, statt zu warnen #
Wenn ein Build startet, stellt er die Abhängigkeiten wieder her. Passt die Lock-Datei nicht mehr zu den deklarierten Abhängigkeiten (weil jemand eine Version geändert hat, ohne die Lock-Datei neu zu erzeugen), verhalten sich die meisten Werkzeuge standardmäßig hilfsbereit: Sie aktualisieren die Lock-Datei und machen weiter.
In der Entwicklung ist das sehr bequem. In der Continuous Integration ist es eine stille Katastrophe. Der Build wird grün. Die Tests werden grün. Und die Lock-Datei, die in die Produktion geht, beschreibt nicht mehr, was das Team geprüft hat.
Die Korrektur besteht aus einem Flag: eine Wiederherstellung im Locked Mode verlangen. In diesem Modus wird eine inkonsistente Lock-Datei nicht mehr heimlich repariert, sondern lässt den Build mit einer klaren Meldung scheitern. Wir haben das Flag in alle betroffenen Pipelines eingebaut.
Allerdings mit einer Vorsichtsmaßnahme, auf die es ankommt: Wir haben zuerst Repository für Repository geprüft, ob der Hauptzweig diese Kontrolle besteht. Wer ein strenges Flag in ein Projekt einbaut, das schon inkonsistente Lock-Dateien hat, färbt dessen Pipeline über Nacht rot und bringt das Team dazu, das Flag abzuschalten. Einen Schutzmechanismus führt man erst ein, wenn man gemessen hat, was er blockieren wird.
Versionen wirklich anheben #
Eine korrekte Lock-Datei nützt nichts, wenn sie Versionen vom letzten Jahr festschreibt. Parallel haben wir deshalb den Rückstau an offenen Updates in allen unseren Repositorys abgearbeitet: sechsundzwanzig Merge Requests, gebaut, getestet und (das ist der Teil, den niemand macht) vor dem Merge in einem echten Browser Seite für Seite geöffnet und nach dem Deployment auf der produktiven Website geprüft.
Dieser letzte Schritt ist kein Übereifer. Ein Major-Upgrade einer UI-Bibliothek kompiliert einwandfrei und liefert eine weiße Seite. Die Unit-Tests sehen es nicht. Die CI-Pipeline sieht es nicht. Nur ein Browser sieht es.
Die Lücke, die niemand testet: die Lizenz #
Der lehrreichste Moment der Woche hatte nichts mit einer technischen Lücke zu tun.
Eine im .NET-Ökosystem sehr verbreitete Testbibliothek hat zwischen zwei Hauptversionen ihre Lizenz geändert: Von einer permissiven freien Lizenz wechselte sie zu einer proprietären Lizenz, die kommerzielle Nutzung ohne Kauf verbietet. Das automatische Upgrade hat sie vorgeschlagen wie jedes andere.
Sie kompilierte. Alle 1.159 Tests liefen durch. Absolut nichts in der Pipeline hatte auch nur einen Grund zu protestieren, denn keine CI-Pipeline testet Lizenzen. Wir haben es beim Lesen der Paket-Metadaten bemerkt, in der Lizenzdatei überprüft und noch am selben Tag rückgängig gemacht, mit einer Sperrregel, damit der Vorschlag nicht wiederkommt.
Ein Lizenzwechsel ist eine unsichtbare rechtliche Regression. Er bricht keinen Test, taucht in keinem Schwachstellenscan auf und wird meist im ungünstigsten Moment entdeckt: bei einem Audit, einer Finanzierungsrunde, einer Abmahnung.
Wir haben versucht, diese Erkennung zu automatisieren. Wir sind gescheitert, und das ist schon ein Ergebnis: Die getesteten Lizenzscanner lesen die Lizenzdateien, die im Verzeichnisbaum liegen, nicht die Metadaten der heruntergeladenen Pakete. Sie sehen also weder diese Bibliothek noch die anderen. Statt noch ein eigenes Werkzeug zu schreiben, haben wir entschieden: Für jede Abhängigkeit unter restriktiver Lizenz gibt es ein Ticket für ihren Ersatz, das wie gewöhnliche technische Schulden verfolgt wird.
Was sich für Sie ändert #
- Ihre Sicherheitsanalysen lesen die echten Versionen. Eine veraltete Lock-Datei lieferte ein beruhigendes und falsches Urteil; jetzt lässt sie den Build scheitern.
- Updates kommen laufend, in kleinen, lesbaren Merge Requests, statt in einem jährlichen Paket, das sich nicht prüfen lässt und deshalb nie gemacht wird.
- Ihre Lizenzen werden geprüft. Wechselt eine Bibliothek, die Sie nutzen, zu Bedingungen, die mit kommerzieller Nutzung unvereinbar sind, sehen wir das und sagen es Ihnen, bevor Ihr Anwalt davon erfährt.
- Nichts wird gemergt, nur weil ein Build grün ist. Was die Oberfläche betrifft, wird vor und nach der Produktivsetzung in einem Browser geöffnet.
Wenn Sie diesen Monat nur eine einzige Kontrolle bei sich durchführen, dann diese: Nehmen Sie Ihre Lock-Datei und prüfen Sie, ob Ihre CI-Pipeline scheitert, wenn die Datei inkonsistent ist. Repariert die Pipeline sie selbst, misst Ihr Sicherheits-Dashboard etwas anderes als Ihre Produktion.
