Websites herunterladen, die Jenkins nutzen

Über Jenkins

Jenkins ist ein Automatisierungsserver und keine Website-Technologie. Dass er in einem Web-Technologieprofil überhaupt auftaucht, liegt daran, dass sein Controller eine Weboberfläche mitbringt. Ein Build-System gehört in ein internes Netz, hinter ein VPN oder eine Firewall im Büro. Wenn ein Crawler ein solches System vom öffentlichen Internet aus erkennen kann, hat jemand den Controller veröffentlicht, absichtlich oder versehentlich, und die Zeile in unseren Daten sagt ebenso viel über die Exponierung aus wie über die Werkzeuge.

Die Software steht unter der Lizenz MIT, ist in Java geschrieben und wird seit 2011 unter ihrem heutigen Namen entwickelt. Self-Hosting ist die Regel, jede Installation ist also eine Maschine, die ein Team selbst warten und patchen muss. Das Plugin-Ökosystem ist der Grund, warum Installationen jahrelang bestehen bleiben, und zugleich der Grund, warum sich die Angriffsfläche schwer einschätzen lässt: Der Fingerprint identifiziert den Kern und sagt nichts über die Plugins, die daneben geladen sind.

Die Versionsdaten machen das Bild konkret. Über die sichtbaren Controller hinweg erfassen wir 43 verschiedene Versionen, am häufigsten Version 2.528.2. Die breite Streuung zeigt, dass der Bestand nicht im Gleichschritt aktualisiert wird, was bei einer Software, die neben einer schnelllebigen Linie auch eine Long-Term-Support-Linie veröffentlicht, wenig überrascht. Ein exponierter Controller mit einem alten Build ist ein dokumentiertes Ziel und kein theoretisches Risiko. Für die Erforschung von Angriffsflächen ist die Versionsspalte daher die entscheidende Spalte.

Das Vorhandensein verrät auch etwas darüber, wie eine Domain genutzt wird. Ein Hostname, der mit einem Build-Controller antwortet, ist meist keine Marketing-Website, sondern Infrastruktur, die zufällig öffentlich auflösbar ist: eine Subdomain für Continuous Integration, ein Entwicklerportal, ein übrig gebliebener Host aus einer Migration. Gruppiert man diese Hostnamen nach ihrer Mutterorganisation, kartiert man eine Entwicklungslandschaft statt einer öffentlichen Web-Landschaft, und das ergibt ein anderes Bild eines Unternehmens als der Stack seiner Homepage.

Verschiedene Käufer lesen dieselben Zeilen unterschiedlich. Sicherheitsteams und Schwachstellenforscher wollen die exponierten Instanzen, weil ein erreichbarer Build-Controller ein Weg zu Quellcode, Deployment-Zugangsdaten und Signaturschlüsseln ist. Anbieter von gehosteter Continuous Integration und von Tools für die Software-Lieferkette lesen die Liste als Nachfrage, weil eine Organisation mit eigenem Controller die Kosten dieser Kategorie bereits akzeptiert hat und schneller zu gewinnen ist als eine, die gar nichts automatisiert hat. Beratungen nutzen sie zur Größenschätzung, unter der vernünftigen Annahme, dass hinter jeder Installation ein Entwicklungsteam von einiger Größe steht.

Stand Oktober 2026 erkennen wir die Software auf 103 Websites, und die Zahl verdient eher einen Vorbehalt als eine Schlagzeile. Fast jede reale Installation weltweit bleibt einem öffentlichen Crawl verborgen, weil sie auf einer privaten Adresse liegt oder hinter einem Authentifizierungs-Proxy, der nichts Identifizierbares zurückgibt. Die Liste enthält das Exponierte und das Halb-Exponierte: Controller auf öffentlichen Hostnamen, auf Staging-Domains zurückgelassene Instanzen und Login-Seiten, die Produkt und Version nennen, bevor sie irgendjemanden authentifizieren. Als Erhebung der Nutzung liegt die Zahl um Größenordnungen daneben. Als Erhebung dessen, was von außen erreichbar ist, und das ist die Frage, die sich zu stellen lohnt, ist die Liste genau das, worauf es ankommt.