Kontinuierliche Compliance-Pipeline

Die kontinuierliche Compliance-Pipeline (CC-Pipeline) scannt in regelmäßigen Abständen die implementierten Artefakte und ihre Quellenrepositorys.

Die CC-Pipeline verarbeitet die Einträge aus dem Repository inventory, indem der Wert environment-tag verwendet wird, um zu ermitteln, welcher der zuletzt bereitgestellte Status ist, der angezeigt werden soll. Nach dem Scannen und Ausführen von Prüfungen für Artefakte und Quellenrepositorys erstellt die Pipeline ein neues Vorfallproblem oder aktualisiert die vorhandenen Vorfallprobleme im Vorfallrepository. Schließlich sammelt die Pipeline anhand dieser Fragen und Ergebnisse Beweise und fasst sie zusammen, um den Konformitätsstatus der gefundenen Artefakte zu aktualisieren.

Stages und Tasks

In der folgenden Tabelle sind die Aufgaben aufgeführt, die in einer CC-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 liegt bei den Benutzern 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.

Kontinuierliche Compliance-Pipeline-Phasen und -Aufgaben
Aufgabe oder Phase	Kurzbeschreibung	Anpassung zulässig in `.pipeline-config.yaml`	Standardreferenzimplementierung	Angabensammlung	Überspringen zulässig
`start`	Richten Sie die Pipeline-Umgebung ein.	Nein	Ja	Pipeline	Nein
`setup`	Richten Sie Ihre Build-und Testumgebung ein.	Ja	Nein	Nein	Nein
`detect-secrets`	Führen Sie den Scan zum Erkennen geheimer Schlüssel für den Anwendungscode aus.	Ja	Ja	Pipeline	Nein
`static-scan`	Statischen Scan-Code für den Anwendungscode ausführen.	Ja	Ja	Pipeline	Ja
`dynamic-scan`	Führen Sie den dynamischen Scan für die Anwendung aus.	Ja	Ja	Pipeline	Ja
`compliance-checks`	Führen Sie Code Risk Analyzer-Scans und andere Konformitätsprüfungen für App-Repositorys durch.	Ja	Ja	Pipeline	Ja
`scan-artifact`	Scannen Sie die erstellten Artefakte.	Ja	Ja	Pipeline	Ja
`finish`	Erfassen, erstellen und laden Sie die Protokolldateien, Artefakte und Angaben in das Angabenfach hoch.	Ja	Ja	Pipeline	Ja

Weitere Informationen über die Anpassung von Phasen mithilfe der Datei .pipeline-config.yaml finden Sie unter Benutzerdefinierte Skripte und Pipeline-Parameterlisten.

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`
`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`
`dynamic-scan`	`com.ibm.dynamic_scan`
`scan-artifact`	`com.ibm.cloud.image_vulnerability_scan`
`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.

Bestand für Artefakte und Repositorys verarbeiten

Die Startphase klont den Bestand und verarbeitet die neuesten Einträge in der Produktionsumgebung. Sie können diese Umgebung angeben, indem Sie die folgenden Pipelineparameter bereitstellen:

Kontinuierliche Compliance-Pipeline-Artefakte und -Repositorys
Name	Typ	Beschreibung	Erforderlich oder optional
`environment-tag`	Text	Tag, der die neueste Zielumgebung im Bestand darstellt. Beispiel: `prod_latest` oder `us-south_prod_latest`	Erforderlich
`environment-branch`	Text	Filialname, der die Zielumgebung im Bestand darstellt. Beispiel: `prod`	Veraltet-stattdessen `environment-tag` bevorzugen
`region-prefix`	Text	Regionsname als Präfix für den Tag `latest` für die Zielumgebung. Beispiel: `us-south`	Veraltet-stattdessen `environment-tag` bevorzugen

Die Bestandseinträge enthalten implementierte Artefakte und Repository-Quellen. Die Pipeline verarbeitet und erfasst die Bestandseinträge und registriert sie für die Pipelineausführung mithilfe der folgenden pipelinectl-Befehle:

Die Startphase klont auch die gefundenen Repositorys, jedes Repository und jedes Commitpaar. So werden beispielsweise repo1 mit Commit sha1 in einem Ordner geklont, aber die Pipeline klont dasselbe repo1 mit Commit sha2 in einem separaten Ordner.

Die Pipeline registriert Artefakte und Repositorys für die Pipelineausführung unter Verwendung einer einfachen Benennungsnotation und eines Inkrementierungsindex, wie in den folgenden Beispielen gezeigt:

repo-1, repo-2, repo-3
artifact-1 artifact-2, artifact-3

Sie können diese Einträge in den angepassten Stages mithilfe der folgenden pipelinectl-Befehle auflisten:

Wenn Sie die Verzweigungsinformationen in Ihrer CC-Pipeline mit dem pipelinectl-Befehl load_repo "$repo" branch abrufen, wird immer master als Verzweigung zurückgegeben. Verwenden Sie daher commit hashes anstelle von Verzweigungen.

Konfigurationsstage

Die Setup-Phase in der CC-Pipeline führt das Script aus, das sich in der setup-Phase befindet, die von Ihrem .pipeline-config.yaml definiert wird. Mit dem folgenden Befehl können Sie ermitteln, in welcher Pipeline das Script ausgeführt wird:

get_env pipeline_namespace

Dieser Befehl gibt abhängig von der ausgeführten Pipeline entweder cc, cd, ci oder pr zurück. Auf diese Weise können Sie das Setup-Script bei Bedarf zwischen Pipelines wiederverwenden.

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 für statischen Code-Scan führt ein Tool für die Codeanalyse für die angegebenen App-Repository-Codebasen aus.

Die CC-Pipeline stellt die Repositorys bereit, die im Bestand für den Scanner gefunden werden.

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. Die Aufgabe static-scan führt einen Scan in den angegebenen Repos durch.
Fügen Sie Ihren Code der benutzerdefinierten Stufe static-scan in Ihrer .pipeline-config.yaml Datei für eine benutzerdefinierte Implementierung hinzu.

Dynamischer Scan

Die Stage 'Dynamic Scan' führt ein Tool für dynamische Anwendungssicherheitstests aus, um Schwachstellen in der implementierten Anwendung zu finden.

Fügen Sie Ihren eigenen dynamischen Scan-Code in die benutzerdefinierte dynamic-scan-Stufe in Ihrer .pipeline-config.yaml-Datei ein, um eine benutzerdefinierte Implementierung zu erhalten.

Weitere Informationen zum Konfigurieren des dynamischen Scans mit OWASP-ZAP finden Sie unter ZAP-Scan für CC-Pipeline konfigurieren.

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'.

Diese Scripts werden für alle App-Repositorys ausgeführt, von denen die Pipeline Kenntnis besitzt. Die CC-Pipeline verwendet die Schnittstelle pipelinectl save_repo, um Repositorys zu registrieren, die in den Bestandseinträgen gefunden werden, und verwendet anschließend die Befehle list_repos und load_repo, um Repositorys zu iterieren und an Scanner zu senden.

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

Artefakte scannen und signieren

Die Stage 'Artefaktscan' bietet ein Standardverhalten für Docker-Images mit einem anpassbaren Schritt:

Container Registry Vulnerability Advisor scannen

Die CC-Pipeline verwendet die Schnittstelle pipelinectl save_artifact, um Artefakte zu registrieren, die in den Bestandseinträgen gefunden werden. Anschließend iteriert sie über diese Artefakte, indem sie die Befehle list_artifacts und load_artifact verwendet.

Stellen Sie Ihre Artefakte für die Pipeline über die pipelinectl-Schnittstelle bereit, um mit dieser Phase zu beginnen. Es ist nicht erforderlich, die Build-Scripts und die Konfiguration von .pipeline-config.yaml zu aktualisieren.

Um einen anderen Scanprozess zu verwenden oder um andere Artefakte als Docker Bilder in icr.io zu verarbeiten, können Sie diese Schritte mithilfe der Konfiguration .pipeline-config.yaml in Ihrem Projekt anpassen.

Compliancedaten beim Buildvorgang erfassen

Die CC-Pipeline versucht, die Ergebnisse von Prüfungen und Scans zu verarbeiten und die Ergebnisse für jedes gefundene CVE, jede gefundene Schwachstelle oder jeden gefundenen Alert in einzelne Probleme aufzuteilen. Die Probleme, die von der CC-Pipeline gefunden werden, sind mit einer Bezeichnung continuous-compliance-check markiert, die Probleme identifiziert, die in der Produktionsumgebung erkannt werden.

Die Pipeline erfasst Angaben für alle Prüfungen und Scans und speichert sie im Schließfach für Angaben. Der Angabenkollektor speichert auch die Pipelineprotokolldateien, die Pipelinedaten selbst, die die Tekton-Definitionen enthalten. Die Probleme, die gemäß Scan und Prüfung erstellt werden, dass die Ergebnisse auch an die Angaben angehängt werden.