Pipeline für kontinuierliche Integration (Continuous Integration)

Die Continuous-Integration-Pipeline erstellt die bereitstellbaren Artefakte aus den Repositorys der Anwendungen.

Bevor die Pipeline ein Artefakt erstellt, überprüft sie, ob der Code gescannt und getestet wurde – genau wie bei der Bearbeitung von Pull-Anfragen. Erstellte Artefakte werden auch auf Sicherheitslücken gescannt und in der Pipeline signiert, bevor sie im Bestand als release- und bereitstellungsfähig gekennzeichnet werden. Anders als die Pipeline für Pull-Anforderungen erfasst die Pipeline für kontinuierliche Integration Angaben und Ergebnisartefakte zu jeder Stage (Phase) des Buildvorgangs, wie dem Testen, Scannen und Signieren. Diese Daten werden mit den erstellten Artefakten korreliert und können über den Bereitstellungsprozess und das Änderungsmanagement verfolgt werden.

Stages und Tasks

In der folgenden Tabelle sind die Aufgaben aufgeführt, die in einer CI-Pipeline ausgeführt werden. Darüber hinaus enthält die Tabelle auch einen Überblick über jede dieser Phasen:

  • Task oder Phase: Dies bezieht sich auf den Namen der Phase, der in der Konfigurationsdatei .pipeline-config.yaml definiert ist.

  • Kurzbeschreibung: Enthält eine kurze Erläuterung der Aktionen, die während der Ausführung der Phase ausgeführt werden.

  • Anpassung zulässig: Gibt an, ob Benutzer die Flexibilität haben, das Standardverhalten der Stage durch Einfügen eines benutzerdefinierten Scripts in die Datei .pipeline-config.yaml zu ändern oder zu ersetzen.

  • Standardreferenzimplementierung: Hiermit wird angezeigt, ob dieDevSecOps Pipelines werden mit einer vordefinierten oder Standardimplementierung für die Phase geliefert. Insbesondere für bestimmte Phasen wie unit-tests oder setup, DieDevSecOps Pipeline bietet keine sofort einsatzbereite Implementierung. Stattdessen müssen Benutzer angepasste Scripts oder Code bereitstellen, die auf die Anforderungen ihrer Anwendung zugeschnitten sind.

  • Angabensammlung: Gibt an, ob die Phase die Erfassung von Standardangaben durchführt. WannDevSecOpsPipeline Stellen Sie eine Referenzimplementierung für eine Phase bereit. Die Beweissammlung wird sofort durchgeführt. Wenn Benutzer diese vordefinierten Phasen jedoch ändern oder ersetzen möchten, müssen sie sicherstellen, dass ihre angepassten Implementierungen die entsprechende Angabensammlung enthalten. Die gleiche Verantwortung tragen die Benutzer für Phasen, in denen dieDevSecOps Pipeline bietet keine sofort einsatzbereite Implementierung, sodass eine Beweissammlung erforderlich ist. Die Spalte gibt die Entität (Benutzer/Pipeline) an, die für die Angabensammlung verantwortlich ist.

  • Überspringen zulässig (gültig für Version > = v10): Gibt an, ob Benutzer die Ausführung dieser Phase ausschließen können, indem sie die Eigenschaft zum Überspringen in der .pipeline-config.yaml auf 'true' setzen. Bei der Verwendung dieser Funktion ist jedoch Vorsicht geboten, insbesondere bei der Erfassung von Angaben in Stadien. Das Überspringen solcher Phasen kann zu fehlenden wichtigen Angaben für den Build führen.

Phasen und Aufgaben der kontinuierlichen Integration
Task oder Stage Kurzbeschreibung Anpassung zulässig in .pipeline-config.yaml Standardreferenzimplementierung Nachweiserfassung Überspringen zulässig
start Richten Sie die Pipeline-Umgebung ein. Nein Ja Pipeline Nein
setup Richten Sie Ihre Build- und Testumgebung ein. Ja Nein Nicht zutreffend Nein
detect-secrets Führen Sie den Scan zum Erkennen geheimer Schlüssel für den Anwendungscode durch. Ja Ja Pipeline Nein
test Führen Sie Komponententests und Anwendungstests für den Anwendungscode aus. Ja Nein User Ja
static-scan Führen Sie Code für statische Scans für den Anwendungscode aus. Ja Ja Pipeline Ja
compliance-checks Führen Sie Code Risk Analyzer-Scanläufe und andere Konformitätsprüfungen für Anwendungsrepositorys aus. Ja Ja Pipeline Ja
peer-review Erfassen Sie Compliance-Daten zu Peer-Reviews für zusammengeführte Pull-Anfragen. Ja Ja Pipeline Ja
containerize Erstellen Sie die Artefakte. Ja Nein Nicht zutreffend Nein
sign-artifact Signieren Sie die durch den Build erstellten Artefakte. Ja Ja Pipeline Nein
deploy Stellen Sie die durch den Build erstellten Artefakte in der Entwicklungsumgebung (dev) bereit. Ja Nein Nicht zutreffend Nein
dynamic-scan Führen Sie einen dynamischen Scan für die Anwendung durch. Ja Ja Pipeline Ja
acceptance-test Führen Sie Akzeptanz- und Integrationstests für die bereitgestellten, durch den Build erstellten Artefakte in der Entwicklungsumgebung (dev) durch. Ja Nein User Ja
scan-artifact Scannen Sie die durch den Build erstellten Artefakte. Ja Ja Pipeline Ja
release Fügen Sie die durch den Build erstellten Artefakte zum Bestand hinzu. Ja Nein Nicht zutreffend Ja
finish Sammeln und erstellen Sie Protokolldateien, Artefakte und Nachweise und laden Sie diese in das Nachweisschließfach hoch. Ja Ja Nicht zutreffend Ja

Weitere Informationen dazu, wie Sie Phasen mithilfe der Datei „ .pipeline-config.yaml “ anpassen können, finden Sie unter „ Benutzerdefinierte Skripte “ und „Liste der Pipeline-Parameter “.

Phasen und Angaben

Die folgende Tabelle zeigt die Beziehung zwischen den verschiedenen Arten von Beweismitteln und den spezifischen Phasen innerhalb der Pipeline, in denen ihre Erhebung stattfindet.

Kontinuierliche Integrationsphasen und zugehörige Nachweise
Task oder Stage Angabentyp
start Nicht zutreffend
setup Nicht zutreffend
detect-secrets com.ibm.detect_secrets
test com.ibm.unit_tests
static-scan com.ibm.static_scan
compliance-checks com.ibm.code_bom_check, com.ibm.code_cis_check, com.ibm.code_vulnerability_scan, com.ibm.branch_protection
peer-review com.ibm.peer_review
containerize Nicht zutreffend
sign-artifact com.ibm.cloud.image_signing
deploy Nicht zutreffend
dynamic-scan com.ibm.dynamic_scan
acceptance-test com.ibm.acceptance_tests
scan-artifact com.ibm.cloud.image_vulnerability_scan
release Nicht zutreffend
finish com.ibm.pipeline_logs, com.ibm.pipeline_run_data

Weitere Informationen zum Erfassen von Angaben in den anpassbaren Benutzerphasen mithilfe des Scripts collect-evidence finden Sie unter collect-evidence script.

Scan 'Geheime Schlüssel erkennen'

Das Tool IBM Detect Secrets stellt fest, wo im Code der App geheime Schlüssel sichtbar sind. Weitere Informationen zum Einrichten Ihres Repositorys für den Scan finden Sie hier.

Statischer Code-Scan

Die Stage 'Static Code Scan' führt eine Reihe von Analysetools für statischen Code in den angegebenen App-Repositorys aus. Die durch den Befehl pipelinectl save_repo angegebenen Repositorys und das Standard-App-Repository werden gescannt.

Zum Hinzufügen von statischem Code zu Ihrer Pipeline können Sie eine der folgenden Methoden verwenden:

  • Geben Sie den Namen, die URL und die zugehörigen Berechtigungsnachweise für eine bereits aktive Instanz von SonarQube an, indem Sie das Werkzeug SonarQube zu Ihrer Toolchain hinzufügen. Mit der Task 'static-scan' wird ein Scanlauf für die angegebenen Repositorys ausgeführt.

  • Wenn Sie keine eigene SonarQube-Instanz haben, erstellt die Pipeline während der Pipelineausführung eine SonarQube-Instanz. Sie können auf diese Instanz zugreifen, nachdem die Stage "static-scan" erfolgreich ausgeführt wurde.

  • Durch Verwendung des Parameters opt-in-gosec zum Ausführen des gosec-Scans für Golang-Sicherheitsprüfungen.

  • Fügen Sie für eine angepasste Bereitstellung Ihren eigenen statischen Scan-Code zu der angepassten Stage 'static-scan' in der Datei .pipeline-config.yaml hinzu.

SonarQube-Scan zu Ihren Pipelines hinzufügen

Weitere Informationen zur Integration von SonarQube mit der Pipeline für kontinuierliche Integration finden Sie unter SonarQube.

Gosec-Scanintegration zu Ihren Pipelines hinzufügen

Verwenden Sie gosec, um Golang-Quellcode in Ihren gescannten Repositorys zu untersuchen.

Geben Sie den folgenden Parameter an und setzen Sie den Wert auf 1, um den Gosec-Scan zu aktivieren.

gosec-Scan-Parameter
Name Typ Beschreibung Erforderlich oder optional
opt-in-gosec text Option zum Aktivieren des gosec-Scans optional

Weitere Informationen zum Einrichten des Gosec-Scans in der Pipeline für kontinuierliche Integration finden Sie unter GoSec.

Andere statische Scanner verwenden

Wenn Sie stattdessen Ihre eigene statische Scan-Implementierung verwenden möchten, können Sie Ihre .pipeline-config.yaml-Datei ändern und Ihr eigenes benutzerdefiniertes Skript zur static-scan-Phase hinzufügen.

Scans und Prüfungen bei Compliance-Prüfungen

Compliance-Scans und -Prüfungen
Scannen oder prüfen Beschreibung
Code Risk Analyzer-Scans auf Sicherheitslücken Macht Sicherheitslücken für alle Abhängigkeiten des App-Pakets, für Container-Basisimages und für Betriebssystempakete ausfindig. Verwendet das Tool 'Code Risk Analyzer'.
CIS-Prüfung durch Code Risk Analyzer Führt Konfigurationsprüfungen für Kubernetes-Bereitstellungsmanifeste aus Verwendet das Tool 'Code Risk Analyzer'.
Prüfung der Code Risk Analyzer-Stückliste (BOM, Bill of Material) Die Stückliste (BOM, Bill of Material) für ein angegebenes Repository, in der der Herkunftsnachweis aller Abhängigkeiten erfasst ist. Diese Stückliste wird mit unterschiedlichen Granularitätsebenen erfasst. Die Stückliste erfasst beispielsweise die Liste der Basisimages, die im Build verwendet werden, die Liste der Pakete aus den Basisimages und die Liste von App-Paketen, die über das Basisimage installiert werden. Die Stückliste fungiert als Ground Truth für die Analyseergebnisse und kann potenziell zur Durchsetzung von Richtliniengates verwendet werden. Verwendet das Tool 'Code Risk Analyzer'.
Prüfung der Repository-Compliance Prüft, ob die Einstellungen für den Schutz von Verzweigungen korrekt sind. Zum Beispiel sollte der Master-/Hauptzweig immer die Kraftübertragung beschränken. Weitere Informationen finden Sie unter Git Repos and Issue Tracking-Repository konfigurieren.

Diese Scripts werden für alle App-Repositorys ausgeführt, von denen die Pipeline Kenntnis besitzt. Verwenden Sie zum Hinzufügen von Repositorys zu diesen Scans die Schnittstelle pipelinectl, die in Ihrer Konfigurationsstage bereitgestellt wird.

Weitere Informationen zu der erwarteten Ausgabe aus Benutzerscriptstages finden Sie in Angepasste Scripts.

Hinweis: CI-Pipelines werden nicht auf Tags ausgelöst, da sie Funktionen wie branch protection checks oder peer review check nicht unterstützen. Wenn Sie sich entscheiden, eine CI-Pipeline auf Tags laufen zu lassen, stellen Sie sicher, dass Sie die Eigenschaften peer-review-compliance und branch-protection-check deaktivieren, indem Sie sie auf 0 setzen. Beachten Sie jedoch, dass in diesem Fall keine Beweiserhebung durchgeführt wird.

Build

In der Stage 'Build' können Sie eigene Artefakte per Build erstellen. Auch wenn die Pipeline einige Standardfunktionen für Artefakte des Docker-Image-Typs bereitstellt, können Sie in dieser Stage jeden beliebigen Typ von Artefakt erstellen.

Verwenden Sie die Umgebungsvariablen aus der Pipeline-Benutzerschnittstelle, um Berechtigungsnachweise, geheime Schlüssel und Parameter für Ihren Build bereitzustellen. Auf diese Umgebungsvariablen können Sie in dieser Stage sowie in allen angepassten Stages zugreifen. Weitere Informationen dazu, wie Sie in Stages angepasster Scripts auf Parameter und geheime Schlüssel zugreifen, finden Sie unter Angepasste Scripts.

Artefakte scannen und signieren

Die Stages zum Scannen und Signieren von Artefakten stellen ein Standardverhalten für Docker-Images mit anpassbaren Schritten bereit:

  • Signieren von Images mit GPG-Schlüssel.
  • Scannen der Containerregistry mit Vulnerability Advisor.

Wenn Sie mit diesen Stages beginnen möchten, stellen Sie Ihre Artefakte für die Pipeline bereit, um die Schnittstelle pipelinectl zu verwenden. Es ist nicht erforderlich, die Build-Scripts und die Konfiguration von .pipeline-config.yaml zu aktualisieren.

Wenn Sie einen anderen Prozess zum Scannen oder Signieren verwenden oder andere Artefakte als Docker-Images in icr.io verarbeiten möchten, können Sie diese Stages mithilfe der Konfiguration von .pipeline-config.yaml in Ihrem Projekt anpassen.

In Entwicklung (dev) bereitstellen

In der Stage zum Bereitstellen werden per Build erstellte Artefakte in einer Entwicklungsumgebung implementiert.

Dynamischer Scan

Bei einem dynamischen Code-Scan handelt es sich um eine Form von Blackbox-Schwachstellenscans, mit denen Softwareteams aktive Anwendungen scannen und Schwachstellen erkennen können.

Die Stage 'Dynamic Scan' wird unmittelbar nach der Stage Deploy to dev nach einer erfolgreichen Bereitstellung in der Entwicklungsumgebung ausgeführt.

Standardmäßig unterstützt die Pipeline die Ausführung von Zed Attack Proxy (ZAP) Scan, einem kostenlosen Open-Source-Penetrationstesttool, das unter dem Dach von OWASP verwaltet wird. Er führt sowohl dynamische API-als auch UI-Scans aus, die beide in der Beispiel-App "hello-compliance-app" ausgeführt werden können.

Um den dynamischen Scan auszuführen, setzen Sie den Pipelineparameter opt-in-dynamic-scan auf einen nicht leeren Wert. Um die Ausführung dynamischer Scans durch die Stage zu inaktivieren, setzen Sie den Pipelineparameter opt-in-dynamic-scan auf leer. Weitere Informationen zum Festlegen von Pipelineparametern finden Sie unter Pipelineparameter.

Die CI-Pipeline erstellt Probleme im Problemrepository auf der Basis der Wertigkeit. Die Bezeichnung, die dem Problem zugeordnet ist, gibt den Schweregrad der Sicherheitslücke an.

ZAP-API-Scan

Die ZAP-API scannt die Anwendungsendpunkte auf mögliche Datenlecks, Inhaltstypfehler, externe Umleitungen, Code-Injection, SQL-Injection, ferne OS-Befehlsinjektion und andere Sicherheitslücken, die von der Anwendung offengelegt werden. Die ZAP-API-Scans helfen Entwicklern, die Anwendung zu schützen, indem sie diese Schwachstellen in einer Phase oder Testumgebung erkennen und beheben, bevor die Anwendung in einer Produktionsumgebung bereitgestellt wird.

ZAP-API-Scans erfordern die folgenden Eingaben, um Ihre Anwendung zu scannen:

  • Swagger-Definitionsdatei – Beschreibung der HTTP-APIs und der zugehörigen Parameter, wie sie von der App offengelegt werden.
  • API-Schlüssel-Authentifizierungstoken, das für die Authentifizierung bei den API-Endpunkten erforderlich ist.
  • API-Endpunkt-Endpunkte aus den Swagger-Definitionen, die ZAP scannen soll.
  • Ausgeschlossene URLs-Die vom ZAP-Scanner zu ignorierenden URLs.

Der ZAP-API-Scanner verwendet die genannten Eingaben, um einen Scan auszuführen und einen Bericht zu erstellen.

Setzen Sie opt-in-dynamic-api-scan auf einen nicht leeren Wert, damit ZAP-API-Scans ausgeführt werden. Setzen Sie diesen Parameter auf einen leeren Wert, wenn Sie ihn ausschließen möchten.

ZAP-UI-Scan

ZAP UI überprüft die Endpunkte der Anwendung auf Schwachstellen auf den Webseiten selbst, wie beispielsweise das Setzen unsicherer Cookies, fehlerhafte Caching-Header-Einstellungen, domänenübergreifende Dateieinbindungen, fehlerhafte „ CORS “-Einstellungen und andere Schwachstellen, die von der Anwendung offengelegt werden.

UI-Scans funktionieren ähnlich wie API-Scans, aber sie verwenden ein UI-Testscript anstelle einer Swagger-Datei. Das Benutzerschnittstellentestscript startet einen Browser ohne GUI, der als Proxy über den Proxy des ZAP-Scanners konfiguriert ist, und führt einen Benutzerschnittstellentest für den Benutzerschnittstellendpunkt aus. Der Prozess zum Ausführen von ZAP-UI-Tests lautet wie folgt:

  • Kopieren Sie die Testscripts in die ZAP Scanner-Container.
  • Führen Sie den ZAP-Proxy aus.
  • Führen Sie die zap-Testscripts aus.

Der ZAP-Proxy zeichnet den Datenverkehr auf und erkennt die zu scannenden Endpunkte. Nach Abschluss der Scans erstellt der Proxy einen Bericht und generiert Probleme auf dieselbe Weise wie beim ZAP-API-Scan.

Setzen Sie opt-in-dynamic-ui-scan auf einen nicht leeren Wert, damit ZAP-API-Scans ausgeführt werden. Setzen Sie diesen Parameter auf einen leeren Wert, wenn Sie ihn ausschließen möchten.

  • Fügen Sie Ihren eigenen dynamischen Scan-Code in die benutzerdefinierte „dynamic-scan“-Stage in Ihrer Datei „ .pipeline-config.yaml “ ein, um eine eigene Implementierung zu erstellen.

Weitere Informationen zum ZAP-API-Scan und ZAP-UI-Scans finden Sie unter ZAP-Scans konfigurieren.

An Bestand freigeben

Verwenden Sie die Benutzerscript-Stage für die Freigabe an den Bestand, um Artefakte mithilfe des CLI-Befehls cocoa inventory add zum Bestand hinzuzufügen. Weitere Informationen zu diesem Befehl finden Sie im Abschnitt Kakao-Lagerbestand hinzufügen.

Wenn Sie die Bestandsaktualisierung bei Problemen in der Pipeline überspringen wollen, verwenden Sie die folgenden Umgebungsvariablen, um den Status der Pipeline zu überprüfen. Überprüfen Sie ihren Status, bevor Sie den Bestand aktualisieren:

  • skip-inventory-update-on-failure Opt-in-Umgebungsvariable aus Pipeline, um anzugeben, ob eine Bestandsaktualisierung durchgeführt werden soll.
  • one-pipeline-status ist auf 1 gesetzt, wenn in der Pipelineausführung ein Phasenfehler auftritt.

Über die Schnittstelle „ pipelinectl “ können Sie mit den Befehlen „ list_repos “, „ load_repo “, „ list_artifacts “ und „ load_artifact “ auf Ihre Repos und Artefakte zugreifen. Weitere Informationen zu den Befehlen finden Sie in der Dokumentation zu pipelinectl.

Compliancedaten beim Buildvorgang erfassen

Wenn die Pipeline erfolgreich ausgeführt wird, können Sie Informationen zum Build erfassen.

Es werden Nachweise zu allen Prüfungen, Scanläufen, Tests und Vorgängen der Artefaktsignierung im Nachweisschließfach gesammelt. Die Protokolldateien der Pipeline werden zusammen mit den eigentlichen Pipelinedaten, die die Tekton-Definitionen enthalten, ebenfalls in diesem Schließfach gespeichert. Bei diesem Schritt werden auch Compliance-Daten zu Prüfungen durch Peers erfasst. Die Pipeline verwendet pipelinectl, um nach Repositorys mit Pull-Anforderungen zu suchen, die seit dem letzten Buildvorgang zusammengeführt wurden. Außerdem überprüft sie deren Überprüfungsstatus, speichert diesen als Artefakt und erstellt auf der Basis des Ergebnisses Nachweise.

Beim letzten Script handelt es sich um ein Auswertungsprogramm, das den Status der Pipeline abhängig von den Nachweisstatus grün oder rot kennzeichnet. Enthalten die Nachweisstatus Fehler, wird der Ausführungslauf der kontinuierlichen Integration (CI) in roter Farbe markiert.