Der zweite kritische Punkt ist für mich die „Buildpipeline“. Dabei ist nicht nur zum Beispiel ein Jenkins-Job zu betrachten, sondern alle Tools, Server und Scripte, wie zum Entwickeln und zum „Bauen“ der Software genutzt werden. Im Prinzip muss dies bis auf Betriebssystemebene betrachtet werden. In der Annahme, dass es auf dieser Ebene eine ausreichende Sicherung gibt, möchte ich mir lediglich die Tool-Landschaft anhand eines Beispiels ansehen:
Nehmen wir an, zur Entwicklung wird ein Visual Studio Code (VSC) mit Plugins für Java verwendet, Code wird per Git auf einem Server verwaltet und die Builds werden automatisch durch einen Jenkins-Server ausgeführt. Am Ende der Pipeline wird noch per Skript auf eine virtuelle Maschine (VM) ausgerollt, in meinem Falle ein Docker Container, und gestartet. So oder so ähnlich kann man dieses Setup auch bei diversen Firmen im Einsatz vorfinden. Es finden sich bereits die ersten Kompromittierungsvektoren im VSC. Der Code ist zwar OpenSource und für jeden einsehbar, gleichzeitig ist es aber für ein einzelnes Projekt eine kaum zu stemmende Aufgabe, dies komplett zu durchleuchten. Das gleiche „Problem“ stellt sich auch mit anderen Entwicklungsumgebungen (IDE) (wie Eclipse oder Netbeans), dabei sind für mich Closed Source Umgebungen noch problematischer, da man sich auf die Aussagen des Herstellers verlassen muss und nicht selbst prüfen kann. Das Problem mit eventuell kompromittierten IDEs wird durch die Nutzung von Plug-Ins noch verschärft. Ein Verzicht ist keine Lösung, da z. B. VSC ohne Plug-Ins nichts kann. Auch die Plug-Ins sind Open Source und bedeuten eine Menge zu prüfenden Code. Der entwickelte Code selbst würde per Git verwaltet werden. Auch ein Git kann falsch eingerichtet oder angegriffen werden. An dieser Stelle der kurze Hinweis, dass schon öfter Entwicklerteams sensible Daten auf einem öffentlichen Git Server (z. B. github) abgelegt haben, obwohl diese sogar explizit private Repositories anbieten. Aber auch ein selbst eingerichteter Git Server kann zum Ziel werden. Beispielsweise wenn der Server fehlerhaft eingerichtet oder auch hier das Tool selbst kompromittiert wurde. Eine Möglichkeit wäre ein „geknacktes“ Git, das entweder eine Backdoor öffnet oder den eingecheckten Code nach außen kopiert.
Die nächste Komponente in diesem Konstrukt ist der Jenkins-Server (auch hier gibt es natürlich andere Varianten). Sofern jemand auf diesen Server Zugriff hat, können u. a. Codeprüfungen deaktiviert, ein anderes Repository (mit „besseren Bibliotheken“), Passwörter eingesehen und Prozesse verändert werden. Zwar hat der Jenkins selbst eine History darüber, welche Jobs von wem konfiguriert wurden, jedoch nicht darüber, welche Einstellungen von wem durchgeführt wurden. Es ist zum Beispiel durch Anpassung der Jobs möglich, einen anderen Java Truststore zum Bauen mitzugeben, damit wäre ein großer Teil der gut gemeinten Security ausgehebelt.
Der letzte Teil meines Gedankenexperimentes sind die Skripte zum Ausbringen und Starten von gebauten Artefakten auf einer VM. Diese sehe ich am wenigsten kritisch, da sie im Normalfall übersichtlich gehalten sind und imperativen Code, also keine Klassen o. ä. enthalten. Jedoch können auch diese Skripte verändert werden und zum Beispiel für einen Rollout weitere Parameter mitgeben, oder weitere -ungewollte- Artefakte ausbringen.
