Die Automatisierung von Softwarebereitstellung durch Continuous Integration und Continuous Deployment (CI/CD) hat die Softwareentwicklung in den letzten Jahren revolutioniert. Unternehmen profitieren von schnellen Release-Zyklen, stabileren Builds und effizienteren Entwicklungsprozessen. Gleichzeitig sind jedoch neue Angriffsflächen entstanden: moderne Softwareprojekte basieren oft auf komplexen Lieferketten mit zahlreichen Abhängigkeiten, Tools und Open-Source-Bibliotheken. Diese wachsende Komplexität macht Anwendungen anfällig für Supply-Chain-Angriffe. Meine Bachelorarbeit „Entwicklung einer CI/CD-Pipeline: DevSecOps- und Shift-Left-Strategien zur Prävention von Supply-Chain-Angriffen“, die ich in den vergangenen Monaten bei der avocado software engineering GmbH verfasst habe, entwickelt einen praxisnahen Prototypen einer sicheren CI/CD-Pipeline. Ziel war es, mit Hilfe moderner Security-Ansätze wie DevSecOps und Shift-Left die Resilienz gegenüber Supply-Chain-Angriffen deutlich zu erhöhen.

Motivation

Die Relevanz des Themas lässt sich anhand prominenter Vorfälle belegen. Der Angriff auf SolarWinds, bei dem ein kompromittiertes Update Schadcode in tausende Systeme brachte, verdeutlichte die Verwundbarkeit von Build-Umgebungen. Weitere Details finden sich auch im zugehörigen Blogbeitrag von SolarWinds. Die Log4Shell-Sicherheitslücke zeigte, wie eine einzige Open-Source-Komponente kritische Infrastrukturen weltweit bedrohen kann. Und mit dem XZ-Utils-Vorfall wurde deutlich, dass Angreifer in der Lage sind, langfristig Vertrauen in Open-Source-Communities zu missbrauchen, um gezielt Backdoors einzuschleusen. Diese Angriffe haben ein gemeinsames Muster: Sie nutzen die Komplexität moderner Software-Lieferketten aus. Klassische Abwehrmechanismen, die erst in späten Entwicklungsphasen greifen, sind hier wirkungslos. Unternehmen benötigen deshalb Strategien, um Sicherheit von Beginn an mitzudenken und in alle Schritte des Softwareentwicklungszyklus einzubinden.

DevSecOps und Shift-Left

Der DevOps-Ansatz hat gezeigt, dass durch Automatisierung, enge Zusammenarbeit und kontinuierliche Bereitstellung erhebliche Effizienzgewinne möglich sind. DevSecOps setzt auf genau diese Prinzipien, erweitert sie jedoch um den Aspekt der Sicherheit. Statt Sicherheit als isolierte Disziplin zu betrachten, wird sie zur Querschnittsaufgabe. Alle Beteiligten – vom Entwickler bis zum Betriebsteam – tragen Verantwortung für sichere Software. Das Shift-Left-Prinzip verstärkt diesen Gedanken, indem es fordert, dass Prüfungen möglichst früh stattfinden. Sicherheit wird nicht als Hürde am Ende, sondern als ständige Begleiterin des Entwicklungsprozesses verstanden. Praktisch bedeutet das: Code wird bereits beim Commit geprüft, Abhängigkeiten werden kontinuierlich analysiert, und Infrastrukturkonfigurationen werden automatisiert validiert. Fehler lassen sich so früh entdecken, wodurch nicht nur Risiken, sondern auch Kosten reduziert werden.

Grafik basiert auf: Shifting Left: How to Test Your Code Like a Time Traveler — Shift Left Strategy

Herausforderungen in bestehenden Pipelines

Die Untersuchung der bestehenden Pipeline offenbarte mehrere Problemfelder. Ein wesentliches Hindernis war die Wahrnehmung von Sicherheit als „Bremse“. Auch die Vielzahl an Tools und deren komplexe Konfiguration erschwerten eine reibungslose Integration. Hinzu kommt, dass viele Scanner eine große Menge an False Positives produzieren. Das führte dazu, dass Warnungen ignoriert oder Sicherheitsprüfungen ganz umgangen wurden. Besonders kritisch war das Thema Secrets Management: Übliche Fälle sind Zugangsdaten die in Konfigurationsdateien hinterlegt werden. Solche Praktiken stellen ein erhebliches Risiko dar, insbesondere wenn Repositories öffentlich zugänglich sind oder externe Partner Zugriff erhalten.

Konzeption und Aufbau der Pipeline

Der in meiner Arbeit entwickelte Prototyp sollte diesen Schwächen entgegenwirken. Im Kern basiert er auf Jenkins als Orchestrierungstool, das die verschiedenen Stages koordiniert. Statische Codeanalysen werden mit SonarQube und Semgrep durchgeführt, während Syft und Dependency-Track die eingesetzten Abhängigkeiten erfassen und auswerten. Damit entsteht eine vollständige Software Bill of Materials, die Transparenz über alle Komponenten schafft. Container-Images werden mit Trivy überprüft und in Harbor abgesichert, sodass nur geprüfte Artefakte in die Deployment-Stages gelangen. Checkov übernimmt die Analyse von Infrastructure-as-Code-Dateien, etwa in Terraform oder Kubernetes-Manifests, um Fehlkonfigurationen und potenzielle Sicherheitslücken frühzeitig zu identifizieren. Für das Deployment kommt ArgoCD zum Einsatz, das nach dem GitOps-Prinzip arbeitet und damit eine klare Trennung zwischen Entwicklungs- und Produktionsumgebung ermöglicht. Das Konzept sieht außerdem die konsequente Nutzung von Security Gates vor. Diese verhindern, dass Builds mit kritischen Schwachstellen weiterlaufen, und zwingen Entwickler dazu, Probleme zeitnah zu beheben. Ergänzt wird dies durch Pre-Commit Hooks, die verhindern, dass unsicherer Code überhaupt erst in das zentrale Repository gelangt. Dazu muss eine .pre-commit.config.yaml Datei ins Verzeichnis des Repos gelegt werden, damit die lokalen Hooks auch funktionieren.

repos: - repo: https://github.com/gitleaks/gitleaks rev: v8 .25.1 hooks: - id: gitleaks - repo: https://github.com/returntocorp/semgrep rev: v1.63.0 hooks: - id: semgrep args: ["--config = auto"]

repos:
    - repo: https://github.com/gitleaks/gitleaks
      rev: v8 .25.1
      hooks:
          - id: gitleaks

    - repo: https://github.com/returntocorp/semgrep
      rev: v1.63.0
      hooks:
          - id: semgrep
            args: ["--config = auto"]

Nachfolgend sind verschiedene Stages zu sehen wie sie in einer Pipeline in der Praxis aussehen können.

stage ( ’ Checkout Code ’) { agent { label ’ built - in ’ } steps { cleanWs () script { git credentialsId : ’ bitbucket_auth ’ , url : ’ http :// docker - compose - bitbucket -1:7990/ scm / avc / av -core . git ’ , branch : ’ develop ’ } } }

stage ( ’ Checkout Code ’) {
     agent { label ’ built - in ’ }
         steps {
         cleanWs ()
         script {
             git credentialsId : ’ bitbucket_auth ’ ,
             url : ’ http :// docker - compose - bitbucket -1:7990/ scm / avc / av -core . git ’ ,
             branch : ’ develop ’
         }
     }
 }

stage ( ’ IaC Scan : API ’) { steps { dir ( ’ api / ’) { sh ( label : " Checkov Scan " , script : " checkov -d . -- output sarif || true " ) } } }

stage ( ’ IaC Scan : API ’) {
    steps {
        dir ( ’ api / ’) {
            sh (
                label : " Checkov Scan " ,
                script : " checkov -d . -- output sarif || true "
            )
        }
    }
}

Implementierung und Evaluation

Der Prototyp wurde anhand einer Beispielanwendung praktisch umgesetzt und getestet. Dabei zeigte sich, dass die Integration von Sicherheitsmechanismen die Build-Zeiten zwar leicht verlängert, die gewonnenen Vorteile jedoch deutlich überwiegen. Schwachstellen wurden bereits früh entdeckt, und durch die automatisierte Erstellung einer SBOM konnte jederzeit nachvollzogen werden, welche Abhängigkeiten genutzt wurden und welche Risiken mit ihnen verbunden waren. Besonders wertvoll war die Kombination aus statischer Analyse, Abhängigkeitsprüfung und Container-Scanning. Während einzelne Tools jeweils nur einen Teilbereich abdecken, entsteht durch ihre Kombination ein ganzheitliches Sicherheitsbild. Auch die Überwachung im Betrieb spielte eine wichtige Rolle: Durch Rancher konnten die Kubernetes-Cluster zuverlässig überwacht werden, während Sentry half, Laufzeitfehler zu identifizieren und schnell zu beheben. Die Evaluation machte deutlich, dass der Erfolg nicht allein von den Tools abhängt. Entscheidend ist, dass Sicherheit reibungslos in den Workflow eingebettet wird und klare, verständliche Ergebnisse liefert. Erst dadurch wurde Akzeptanz im Team geschaffen. Entwickler nahmen die zusätzlichen Prüfungen nicht als Hindernis, sondern als sinnvolle Unterstützung wahr.

Fazit

Die Arbeit hat gezeigt, dass Sicherheit und Agilität in modernen CI/CD-Umgebungen keine Gegensätze sind. Durch die konsequente Anwendung von DevSecOps und Shift-Left können Unternehmen ihre Softwarelieferketten widerstandsfähiger machen, ohne die Vorteile automatisierter Deployments zu verlieren. Der entwickelte Prototyp bietet eine konkrete Blaupause, wie sich Sicherheit von Beginn an in den Entwicklungsprozess integrieren lässt. Ein zentrales Ergebnis ist die Erkenntnis, dass Sicherheit kein einmaliges Projekt, sondern ein kontinuierlicher Prozess ist. Nur wenn Unternehmen bereit sind, ihre Kultur zu verändern und Sicherheit als gemeinsame Verantwortung zu verstehen, können sie langfristig gegen Supply-Chain-Angriffe bestehen.