Blog

Von der Erstellung bis zur Ausführung: Hinweise zur sicheren Bereitstellung

Jeroen Willemsen
Ben de Haan

Jeroen Willemsen, Ben de Haan

Aktualisiert Oktober 21, 2025
6 Minuten

Unsere Erfahrung mit Ressourcen zur sicheren Bereitstellung

Haben Sie schon einmal nach Ressourcen zum Thema "Sichere Software-Bereitstellung" gesucht? Die meisten Ergebnisse drehen sich um das Pentesting oder den Einsatz von Sicherheitstools in Ihrer CI/CD-Pipeline. Es wäre dasselbe, als wenn Sie recherchieren würden, wie Sie Ihre Fähigkeiten beim Kuchenbacken verbessern können, aber am Ende bei den Anleitungen für Küchengeräte landen. Wir möchten diese Lücke schließen: In diesem Blog möchten wir Ihnen wichtige Hinweise für eine sichere Bereitstellung geben.

Person hält schwarze Früchte in der Nähe des Kuchens für den sicheren Einsatz Analogie
Sie möchten diesen Kuchen auf jeden Fall vor böswilligen Akteuren schützen, indem Sie ihn "sicher verteilen" :)

Woran sollten Sie also denken? Wir beginnen mit ein paar Aspekten, die unserer Meinung nach wichtig sind, wenn Sie an einer sicheren Bereitstellung arbeiten. Danach gehen wir auf die Bereiche ein, an denen Sie arbeiten müssen, um dies tatsächlich zu erreichen. Und schließlich geben wir Ihnen Ratschläge, wie Sie weiter vorgehen sollten.

Komponenten einer sicheren Bereitstellung

Bei der Bereitstellung Ihrer Software geht es normalerweise um die Migration Ihrer Artefakte in eine bestimmte Zielumgebung. Eine solche Bereitstellung erfordert oft Anweisungen, die im Code enthalten sind. Oft ist der Build-Prozess noch Teil der Bereitstellung, da einige Artefakte zusätzliche Build-Schritte in der Zielumgebung erfordern.

Damit bleiben uns vier Hauptkomponenten, die für eine Bereitstellung relevant sind:

  1. die Anweisungen für das Artefakt und seine Bereitstellung als Code;
  2. die Erstellung des Artefakts;
  3. die Bereitstellung des Build-Artefakts in der Zielumgebung;
  4. die Zielumgebung.

Hier konzentrieren wir uns auf die Bereitstellung selbst - sichere Builds und sichere Artefakte sind Bausteine, von denen die Bereitstellung abhängt.

Komponenten für eine sichere Bereitstellung
Komponenten für eine sichere Bereitstellung

Die Build-Tools, die Sie benötigen, die Art und Weise, wie Sie programmieren möchten, und wie Sie Codeänderungen integrieren, sind Themen, die einen eigenen Artikel wert sind. Konzentrieren wir uns stattdessen auf den Schritt der Bereitstellung. Was würden Sie also brauchen?

Anforderungen, Anforderungen, Anforderungen...

Lassen Sie uns mit einer wichtigen Anmerkung beginnen: Eine sichere Bereitstellung über eine sichere CI/CD-Pipeline ist schwierig. Es erfordert kontinuierliche Anstrengungen, die die Verbesserung der Sicherheit der gerade erwähnten Komponenten beinhalten. Um Ihnen den Einstieg zu erleichtern, haben wir eine Liste von Hinweisen zusammengestellt, die auf unseren Erfahrungen und den Ressourcen am Ende dieses Blogs basieren.

Wir fahren fort mit dem, worauf Sie achten sollten, und behandeln dabei Prozesse, Technologie und Menschen:

Eine sichere Bereitstellung umfasst Menschen, Prozesse und Technologien.

Prozess

  • Formalisierung und Wiederholbarkeit: Stellen Sie zunächst sicher, dass Sie verstehen, was Sie erreichen wollen. Dokumentieren Sie dies entweder in einem formalen Prozess oder in Code - oder beides zusammen -, um den Aufbau und die Bereitstellung automatisieren zu können.
  • Reproduzierbarkeit: Jeder Einsatz sollte reproduzierbar sein. Das wird deutlich, wenn Sie einen Vorfall in einer anderen Umgebung wiederholen möchten. Sie möchten herausfinden, was schief gelaufen ist und warum. Das bedeutet, dass Sie einige der erzeugten Artefakte über einen längeren Zeitraum aufbewahren müssen. Alternativ sollte ein Prozess zur Bereitstellung von Artefakten Garantien dafür bieten, dass am Ende derselbe Zustand mit genau denselben Eigenschaften vorliegt wie bei der vorherigen Bereitstellung der Artefakte.
  • Möglichkeit zum Rollback: Dies wird oft übersehen, aber wenn Sie nach einer kompromittierenden Bereitstellung kein Rollback durchführen können... sind Sie in Schwierigkeiten.
  • Provenienz und Rückverfolgbarkeit: Um sicherzustellen, dass Sie wissen, wer oder was eine Aufgabe gestartet hat, müssen Sie sicher sein, dass Sie den Ursprung zurückverfolgen können - ob es sich um einen Commit, eine Genehmigung eines Pull-/Merge-Requests oder eine Bereitstellungsgenehmigung handelt. Stellen Sie also sicher, dass dies auch für Ihre Audit-Protokollierung und Ihre Build- oder Deployment-Pipeline gilt.
  • Zugriffsverwaltung: Ein DevOps-Ingenieur sollte nicht einfach alles irgendwo einsetzen dürfen. Es sollte eine Aufgabentrennung vorhanden sein. Dies gilt auch für die eingesetzte Technologie: Sie sollten sicherstellen, dass Ihre Mittel zur Bereitstellung (z.B. Agenten/Runner) nur in der vorgesehenen Zielumgebung eingesetzt werden dürfen. Wenn Ihr Runner beispielsweise einen Container in der Testumgebung für die Datenwissenschaft bereitstellt, sollte derselbe Runner nicht gleichzeitig zur Bereitstellung in Ihrer Produktionsumgebung berechtigt sein.

Technologie

  • Überprüfung der Integrität: Es gibt ein paar Stellen, an denen Integrität wichtig ist:
    • die Integrität des Artefakts, wenn es abgerufen/bereit für die Bereitstellung gemacht wird
  • Automatisierte Sicherheitsprüfungen: Sie können verschiedene automatisierte Sicherheitsprüfungen durchführen, um "niedrig hängende Früchte" aufzuspüren, die oft über die Build-, Deployment- und Post-Deployment-Phase verteilt sind. Denken Sie an Abhängigkeitsprüfungen, SAST, DAST, Docker-Container-Prüfungen, Host-Audits und/oder Sicherheitsprüfungen der Cloud-Anbieter-Konfiguration. Wo Sie welche Prüfung ansetzen, hängt von der Prüfung, der Art des Artefakts und der Zielumgebung ab.
  • Sicherheit der Build- und Deployment-Pipeline: Es gibt viel über die Sicherheit Ihrer CI/CD-Pipeline zu sagen. Es ist Ihre "Produktionsumgebung", um die Sie sich genauso gut kümmern sollten wie um Ihre eigentliche Produktionsumgebung. Weitere Hinweise finden Sie in dieser Präsentation.
  • Wie Sie mit Ihren Geheimnissen umgehen: Natürlich sollten Sie vorsichtig damit sein, was Sie veröffentlichen. Sei es Ihr geistiges Eigentum im Quellcode oder die persönlichen Daten Ihrer Benutzer. Die eigentlichen Geheimnisse, die in dieser Phase zusätzlichen Schutz benötigen, sollten Ihre Authentifizierungs-, Verschlüsselungs- und Signiermittel sein. Denken Sie dabei an Anmeldedaten, andere Passwörter, Schlüssel und dergleichen. Vergewissern Sie sich, dass Sie sie sicher bereitstellen, verwenden Sie nach Möglichkeit temporäre Zugangsdaten oder wechseln Sie die Geheimnisse auf andere Weise rechtzeitig aus.

Menschen

  • Manuelle Überprüfung (oder "4 Augen"): Tools können nicht alles finden, schon gar nicht am Anfang. Stellen Sie sicher, dass Sie eine manuelle Überprüfung durchführen. Wo dies geschieht, hängt von Ihrem Prozess ab. Oft geschieht dies auf der Ebene der Pull-/Merge-Anfrage oder es gibt eine Freigabe für die Bereitstellung. Stellen Sie sicher, dass der Autor des Codes nicht derjenige ist, der die manuelle Überprüfung vornimmt. Andernfalls kann er die Bereitstellung seiner eigenen Malware genehmigen.
  • Schulung: Schulen Sie Ihre Techniker, damit sie die Ziele verstehen, die Sie mit einer sicheren Bereitstellung erreichen möchten, und damit sie die Tools gut nutzen können. Es könnte sogar eine gute Idee sein, sie darin zu schulen, die Pipeline selbst zu erstellen, um optimale Ergebnisse zu erzielen.
  • Erkennen und melden: Ihre Techniker sollten in der Lage sein, die Umgehung der Sicherheitskontrollen zu erkennen und zu melden. Belohnen Sie sie für die Meldung!

Natürlich gibt es noch viele weitere Aspekte einer sicheren Bereitstellung. Zum Beispiel: Sollte Ihr Artefakt in der Zielumgebung unveränderlich sein? Wie sollte Ihre Strategie zur Beförderung von Artefakten aussehen? (z.B. welche Umgebungen haben Sie außerhalb der Produktionsumgebung? und wie propagieren Sie diese?). Und dann müssen wir über den Umfang der Tests sprechen, die in jeder Phase der Erstellung und Bereitstellung durchgeführt werden müssen.

Wie geht es jetzt weiter?

Das waren eine ganze Menge Hinweise für den Anfang! Was sollten Sie jetzt tun?

  • Beginnen Sie risikobasiert. Erstellen Sie ein Bedrohungsmodell für Ihren SDLC-Prozess und kümmern Sie sich um die Hinweise auf der Basis eines bestimmten Risikos.
  • CI/CD-Sicherheit ist komplex und eine kontinuierliche Teamarbeit. Stellen Sie sicher, dass Sie diese Reise gemeinsam antreten.
  • Bleiben Sie nicht in der Analyse-Lähmung gefangen. Fangen Sie klein an, aber was noch wichtiger ist: Fangen Sie an!

Wenn Sie Fragen, Anmerkungen oder Ergänzungen haben, zögern Sie nicht, uns zu kontaktieren!

Ressourcen

 

Verfasst von

Jeroen Willemsen

Typical security jack-of-all-trades. Hands-on security architect with a nack for security, automation, and risk management. Jeroen has been involved in various OWASP projects. He enjoys a pentest every now and then, while helping organizations to get secure enough. Jeroen is often engaged in knowledge sharing through talks, blogs, projects at github, and trainings. Want to reach out? Check his allmylinks page.

Contact

Let’s discuss how we can support your journey.