Bewährte Verfahren für DevSecOps-Toolchains

In den folgenden Abschnitten werden die Best Practices für die einzelnen DevSecOps-Toolchains beschrieben: Continuous Integration (CI), CI für Infrastructure as Code ( IaC ), Continuous Deployment (CD) und Continuous Compliance (CC).

Bewährte Verfahren für die Toolchain zur kontinuierlichen Integration (CI)

Die DevSecOps-CI-Toolchain folgt diesen Vorgehensweisen:

  • Wird in detect-secrets den Anwendungs-Repositorys ausgeführt, um die Offenlegung vertraulicher Informationen im Anwendungsquellcode zu verhindern.
  • Führt Unit-Tests und Anwendungstests für den Anwendungscode durch.
  • Führt statische Code-Scans in den Anwendungs-Repositorys durch, um Sicherheitslücken im Quellcode zu identifizieren.
  • Führt Compliance-Prüfungen mithilfe von Compliance-Scannern wie dem Code Risk Analyzer für alle Anwendungs-Repositorys durch, einschließlich Schwachstellen-Scans und einer Stücklistenprüfung (Bill of Materials, BOM) aller Paketabhängigkeiten.
  • Erfasst Compliance-Daten zu Peer-Reviews für alle Pull-Anfragen, die seit dem letzten Build zusammengeführt wurden.
  • Erstellt bei jedem Git-Commit ein Container-Image und vergibt ein Tag, das sich aus der Build-Nummer, dem Zeitstempel und der Commit-ID zusammensetzt, um die Rückverfolgbarkeit zu gewährleisten.
  • Signiert das erstellte Container-Image.
  • Überprüft das Container-Image auf Sicherheitslücken.
  • Stellt das erstellte Artefakt in einer Entwicklungsumgebung bereit und führt dynamische Scans (ZAP-API- und UI-Scans) der laufenden Anwendung durch, um Schwachstellen zur Laufzeit zu erkennen.
  • Führt Abnahme- und Integrationstests für das bereitgestellte Artefakt in der Entwicklungsumgebung durch.
  • Sammelt am Ende jedes Pipeline-Laufs alle Nachweise (Scan-Ergebnisse, Testergebnisse, Protokolle, Peer-Review-Daten und Pipeline-Laufdaten) in einem Nachweisspeicher.

Bewährte Verfahren für die kontinuierliche Integration (CI) der Toolchain für Infrastructure as Code ( IaC )

Die DevSecOps-CI-Toolchain für IaC befolgt folgende Vorgehensweisen:

  • Wird auf detect-secrets den IaC-Repositorys ausgeführt, um das Durchsickern vertraulicher Daten in der Terraform-Konfiguration zu verhindern.
  • Führt bei jedem Git-Commit Unit-Tests für die IaC-Konfiguration durch.
  • Führt einen statischen Code-Scan der IaC-Repositorys durch, einschließlich Terraform-spezifischer Tools wie tflint für Linting und die Durchsetzung von Best Practices sowie terraform fmt und terraform validate für Formatierungskonsistenz und Konfigurationsgültigkeit.
  • Führt Compliance-Prüfungen der IaC-Repositorys durch, indem IaC-specific e Tools (wie Code Risk Analyzer oder checkov) verwendet werden, um nach Compliance-Problemen zu suchen.
  • Erstellt bei jedem Git-Commit eine Tar-Datei, die die Terraform-Konfiguration enthält.
  • Signiert das erstellte Tar-Artefakt.
  • Stellt die IaC-Konfiguration mithilfe von IBM Cloud Schematics oder der Terraform-CLI in einer Entwicklungsumgebung bereit.
  • Führt Abnahme- und Integrationstests an der bereitgestellten Konfiguration in der Entwicklungsumgebung durch.
  • Fügt die erstellten Artefakte dem Inventar-Repository hinzu, um die Rückverfolgbarkeit zu gewährleisten und die Bereitstellung in nachgelagerte Umgebungen zu ermöglichen.
  • Sammelt am Ende jedes Pipeline-Laufs alle Nachweise (Scan-Ergebnisse, Testergebnisse, Signaturdaten, Protokolle und Pipeline-Laufdaten) in einem Nachweisspeicher.

Bewährte Verfahren für die Continuous-Deployment-Toolchain (CD) zur Bereitstellung einer sicheren Anwendung

Um eine sichere Anwendung bereitzustellen, befolgt die DevSecOps-CD-Toolchain die folgenden Vorgehensweisen:

  • Verwendet einen Promotion-Pull-Request gegenüber dem Inventar-Repository, um den Bereitstellungsumfang zu definieren und das Bereitstellungs-Delta zu berechnen, d. h. die Menge der Artefakte, die sich seit der letzten abgeschlossenen Bereitstellung geändert haben.
  • Stellt sicher, dass alle Pull-Anfragen im aktuellen Bereitstellungsumfang einer Begutachtung durch Fachkollegen unterzogen und genehmigt werden, bevor der Vorgang fortgesetzt wird. Die Bereitstellung wird angehalten, wenn ein Pull-Request nicht genehmigt ist.
  • Stellt sicher, dass jedes für die Bereitstellung vorgesehene Artefakt korrekt signiert ist. Blockiert die Bereitstellung, wenn eine gültige Signatur fehlt.
  • Berechnet die Stückliste (BOM) der Bereitstellung anhand des Bereitstellungs-Deltas und erstellt eine Zusammenfassung der Nachweise sowohl aus dem zugehörigen CI-Pipeline-Lauf als auch aus dem aktuellen CD-Pipeline-Lauf.
  • Erstellt einen Änderungsantrag im konfigurierten Änderungsmanagementsystem und fügt die Deployment-Stückliste, die Nachweiszusammenfassung sowie die Daten zur Einhaltung der Peer-Review-Anforderungen bei.
  • Genehmigt den Änderungsantrag automatisch, wenn alle Compliance-Kriterien erfüllt sind. Unterstützt die manuelle Freigabe oder die Notfallkennzeichnung, wenn die Kriterien nicht vollständig erfüllt sind.
  • Stellt die Artefakte aus dem Bestand in der Zielumgebung (z. B. Staging oder Produktion) bereit, sobald der Änderungsantrag genehmigt oder als Notfall gekennzeichnet wurde.
  • Führt nach der Bereitstellung Abnahme- und Integrationstests durch, um zu überprüfen, ob die Bereitstellung erfolgreich war und die Anwendung wie erwartet funktioniert.
  • Führt bei einem Fehler während der Bereitstellungs- oder Abnahmetestphase automatisch ein Rollback der Bereitstellung innerhalb desselben Pipeline-Laufs durch, wodurch der letzte bekannte fehlerfreie Zustand im Bestand beibehalten wird.
  • Schließt die Änderungsanforderung mit einem close_category oder Successful ab Successful with issues und verschiebt das <target-environment>_latest Inventar-Tag in den bereitgestellten Commit.
  • Sammelt und lädt alle Protokolldateien, Artefakte und Nachweise am Ende jedes Pipeline-Durchlaufs in den Evidence Locker hoch.
  • Optional werden zusammengeführte Pull-Anfragen nach deploy:{region}:{env} einer erfolgreichen Bereitstellung mit gekennzeichnet, um eine lückenlose Rückverfolgbarkeit der Bereitstellung zu gewährleisten, ohne dass Zugriff auf Pipeline-Details erforderlich ist.

Bewährte Verfahren für die Toolchain zur kontinuierlichen Compliance (CC)

Die DevSecOps-CC-Toolchain folgt diesen Vorgehensweisen:

  • Wird detect-secrets auf allen Quellcode-Repositorys im Bestand ausgeführt, um die Offenlegung vertraulicher Daten im Anwendungsquellcode zu erkennen.
  • Führt einen statischen Code-Scan (mit SonarQube oder einer benutzerdefinierten Implementierung) für alle im Bestand gefundenen Quellcode-Repositorys durch.
  • Führt einen dynamischen Sicherheitsscan (OWASP ZAP) der bereitgestellten Anwendung durch, um Schwachstellen zur Laufzeit zu erkennen.
  • Führt mithilfe von Tools (wie dem Code Risk Analyzer) Compliance-Prüfungen für alle im Bestand befindlichen Quell-Repositorys durch, einschließlich Schwachstellenscans, CIS-Prüfungen von Kubernetes-Bereitstellungsmanifesten, BOM-Prüfungen aller Paketabhängigkeiten und der Überprüfung des Zweigschutzes.
  • Überprüft alle bereitgestellten Container-Images auf Sicherheitslücken.
  • Erstellt oder aktualisiert Vorfallmeldungen für jede einzelne CVE, Schwachstelle oder Warnung, die während des Pipeline-Laufs gefunden wurde, und legt für jede Meldung ein Fälligkeitsdatum fest.
  • Sammelt Nachweise für jede Phase im Nachweisspeicher, fügt Scan- und Prüfergebnisse den entsprechenden Problemen bei und aktualisiert den Compliance-Status aller gescannten Artefakte.