Pipeline für Pull-Anforderungen

Die Pull-Request-Pipeline führt eine Reihe von Konformitätsprüfungen für einen Pull-Request für das angegebene Anwendungs-Repository durch.

Der Versuch, eine Pull-Anforderung in die Masterverzweigung einzufügen, kann aufgrund der fehlgeschlagenen Konformitätsprüfungen blockiert werden. Durch das Öffnen oder Aktualisieren einer Pull-Anforderung für den Masterverzweigung wird die Ausführung der Pipeline für Pull-Anforderungen ausgelöst. Sie können Ihre eigene Konfiguration für die Pipelines und Tests in benutzerdefinierten Skripten ausführen.

Stages und Tasks

In der folgenden Tabelle sind die Aufgaben aufgeführt, die in einer PR-Pipeline ausgeführt werden. Darüber hinaus enthält die Tabelle auch eine Übersicht über jede dieser Stufen:

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.
Standard-Referenzimplementierung: Hier wird angegeben, ob die DevSecOps-Pipelines mit einer vordefinierten oder Standardimplementierung für die Stufe geliefert werden. Insbesondere für bestimmte Phasen wie unit-tests oder setup bietet die DevSecOps-Pipeline keine fertige 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. Wenn DevSecOps Pipeline eine Referenzimplementierung für eine Stufe bereitstellen, wird die Beweissammlung 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 in den Phasen, in denen die DevSecOps-Pipeline keine sofort einsatzbereite Implementierung bietet, so dass sie die Beweissammlung selbst durchführen müssen. 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.yamlauf '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.

Pipeline-Auftrag
Aufgabe oder Phase	Kurzbeschreibung	Anpassung zulässig in `.pipeline-config.yaml`	Standardreferenzimplementierung	Anforderung der Angabensammlung	Überspringen zulässig
`start`	Richten Sie die Pipeline-Umgebung ein.	Nein	Ja	NA	Nein
`setup`	Richten Sie Ihre Build-und Testumgebung ein.	Ja	Nein	NA	Nein
`detect-secrets`	Führen Sie den Scan zum Erkennen geheimer Schlüssel für den Anwendungscode aus.	Ja	Ja	NA	Nein
`unit-tests`	Komponententests und App-Tests für App-Code ausführen.	Ja	Nein	NA	Ja
`compliance-checks`	Führen Sie Code Risk Analyzer-Scans und andere Konformitätsprüfungen für App-Repositorys durch.	Ja	Ja	NA	Ja
`finish`	Konsolidieren Sie den Pipelinestatus.	Ja	Ja	NA	Ja

Weitere Informationen dazu, wie Stages mithilfe der Datei .pipeline-config.yaml angepasst werden können, enthalten die Listen Angepasste Scripts und Pipelineparameter.

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.

Scans und Prüfungen bei Compliance-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'.

| Überprüfung der Repository-Konformität | Überprüft, ob die Einstellungen für den Verzweigungsschutz korrekt sind. |

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.

Taskjobs

Compliance-Scans und -Prüfungen
Taskjob	Beschreibung
`code-pr-start`	Klont Apps und DevSecOps-Repositorys und legt Anfangsstatus 'pending' (anstehend) für Statusprüfungen von Git Repos and Issue Tracking-Repositorys fest.
`code-setup`	Der Platzhalter für ein angepasstes Script für eine benutzerdefinierte Konfiguration, mit dem Benutzer die Pipelinekonfiguration abschließen können.
`code-detect-secrets`	Führt den Scan zum Erkennen geheimer Schlüssel aus, um festzustellen, wo geheime Schlüssel im App-Code sichtbar sind.
`code-unit-tests`	Der Platzhalter für ein angepasstes Script für benutzerdefinierte Tests, mit dem Benutzer ihre eigenen Tests ausführen können.
`code-pr-finish`	Führt alle erforderlichen Konformitätsprüfungen aus, kommentiert die Ergebnisse für die Pull-Anforderung und setzt ihr Ergebnis in die Git Repos and Issue Tracking-Repositorys.

Verwendung von PR/MR-Änderungen für Pipeline-Konfigurationsrepositorium

Wenn die PR-Pipeline die Änderungen der Konfigurationsdateien/Skripte, die vom PR/MR kommen, berücksichtigen soll, sollten das Konfigurations-Repository und der Zweig leer sein, was wie folgt eingestellt werden kann:

Die Umgebungsvariablen one-pipeline-repo, one-pipeline-config-repo und pipeline-config-repo sind leer oder nicht in den Umgebungsvariablen angegeben
Die Umgebungsvariablen one-pipeline-config-branch und pipeline-config-branch sind leer oder nicht in den Umgebungsvariablen angegeben.

Pull-Anforderungen mit Problemen zusammenführen

Als Benutzer mit Administratorrechten können Sie Pull-Anforderungen mit fehlgeschlagenen Statusprüfungen im Repository zusammenzuführen. Diese Pull-Anforderungen registrieren jedoch ein Ergebnis des Typs failure (fehlgeschlagen) in ihrem Nachweis für die fehlgeschlagene Task. Dieses Ergebnis ist in der Zusammenfassung der Nachweise und der Beschreibung des Änderungsantrags enthalten.

Ermöglichung der Beweiserhebung in der PR-Pipeline

Die PR-Pipeline unterstützt die Sammlung von Beweisen und das Problemmanagement. Standardmäßig sammelt die PR-Pipeline keine Beweise oder öffnet keine Probleme, aber die Benutzer können diese Funktion aktivieren. Um die Sammlung von Beweisen und die Verwaltung von Problemen zu ermöglichen, setzen Sie die Umgebungsvariable collect-evidence-in-pr als eine der folgenden Aufzählungen:

none: (Standard) Setzen Sie collect-evidence-in-pr auf none, um die Sammlung von Beweisen in der PR-Pipeline zu verhindern.
all: Setzen Sie collect-evidence-in-pr auf all, um alle Nachweise unabhängig vom Status der PR-Pipeline zu sammeln. Ausgaben werden gemäß dem collect-evidence-Skript geöffnet, aktualisiert oder geschlossen.
success: Setzen Sie collect-evidence-in-pr auf success, um nur dann Nachweise zu sammeln, wenn die gesamte PR-Pipeline erfolgreich verlaufen ist. Wenn die PR-Pipeline fehlschlägt, werden keine Beweise gesammelt oder in der Asservatenkammer veröffentlicht und es findet kein Problemmanagement statt.

Hinweis: Da PR-Pipelines im Allgemeinen recht häufig ausgeführt werden, erspart die Wahl des richtigen Modus von collect-evidence-in-pr eine unnötige Sammlung von Beweisen. Es wird empfohlen, den Modus success während der Entwicklungsphase oder in Fällen, in denen Ausfälle zu erwarten sind, zu wählen, um die Beweiserhebung zu verhindern, wenn die Pipeline ausfällt.

Wenn die PR-Pipeline eine Async-Pipeline auslöst, wird der Modus collect-evidence-in-pr, der auf success eingestellt ist, nicht unterstützt. Falls die PR-Pipeline eine asynchrone Pipeline auslöst, setzen Sie collect-evidence-in-pr auf all, um Beweise zu sammeln.

Hinweis: Wenn es sich bei dem Anwendungs-Repository um ein GitLab-Repository handelt und die MR (Merge Request) aus einem geforkten Repository stammt, muss der Benutzer einen Wert für die git-token Umgebungsvariable env angeben, die Zugriff auf das Quell- und das Ziel-Repository hat, um den richtigen Status für die Merge Request festzulegen. Das bedeutet, dass der Git-Token einem Benutzer gehören müsste, der sowohl im Basis-Repository als auch im geforkten Repository einen Beitrag leistet, und der Token über die Berechtigung verfügt, den Status bei einem Commit festzulegen.

Auftauchen von CVE in der PR

Wenn ein PR erstellt wird und die PR-Pipeline Sicherheitslücken findet, fügt die Pipeline die Informationen über die Sicherheitslücke, wie Schweregrad, Kennung der Sicherheitslücke, Paket mit Beschreibung und, falls vorhanden, die Korrektur als Kommentar hinzu. Auf diese Weise können die Benutzer schnell prüfen, welche Schwachstellen im PR behoben werden sollen, anstatt die Pipeline-Protokolle zu durchsuchen.

Ein Opt-in-Flag opt-in-pr-updates ermöglicht es, diese Funktion in der PR-Pipeline zu aktivieren oder zu deaktivieren. Diese Option ist standardmäßig aktiviert.

Einrichten einer PR-Pipeline zur Bearbeitung von Github Merge Queue PRs

Eine Merge Queue ist eine Github-Funktion, die dazu beiträgt, die Geschwindigkeit zu erhöhen, indem sie die Zusammenführung von Pull Requests in einen belegten Zweig automatisiert und sicherstellt, dass der Zweig nicht durch inkompatible Änderungen unterbrochen wird. Mehr zum Einrichten und Verwenden von Github Merge Queue hier.

Obwohl der Zweck von „Merge Queue“ darin besteht, die Geschwindigkeit zu erhöhen, ist zu beachten, dass für einen bestimmten Pull-Request ( Git ) die PR-Pipeline zweimal durchlaufen wird: Zunächst wird der „Standard“-PR ausgeführt. Sobald dies abgeschlossen ist, führen Sie den PR „Merge Queue“ aus.

Erstellen Sie einen neuen Git Auslöser

Erstellen Sie einen neuen Git Auslöser oder duplizieren Sie einen vorhandenen Auslöser. Behalten Sie alle Standardeinstellungen bei, setzen Sie nur die folgenden Eigenschaften außer Kraft:

Name: Sie bevorzugen einen Triggernamen, der den Kontext der Merge Queue widerspiegelt - z. B: PR - Merge Queue
EventListener: auswählen pr-listener-merge-queue
Trigger on: auswählen CEL filter
- CEL filter: eingeben body.action == 'checks_requested'

Merge Queue-PRs verwenden ephemere Zweige - die dynamisch erstellt werden, wenn der ursprüngliche PR zur Merge Queue hinzugefügt wird - aus denen der Merge Queue-PR erstellt wird. Infolgedessen enthält die entsprechende Payload des Ereignisses „ Git “ (die die Pull-Request-Pipeline auslöst) keine Informationen über PR URL oder HTML URL.

Irrelevant im Kontext von Merge Queue, müssen die folgenden DevSecOps Funktionen durch Hinzufügen der entsprechenden Texteigenschaften deaktiviert werden:

skip-merge-pr-to-base: sollte auf true gesetzt werden (Standardwert false)
opt-in-pr-updates: sollte auf 0 gesetzt werden (Standard 1)

Speichern Sie den Auslöser.

Testen des Auslösers für die Zusammenführungswarteschlange

Erstellen Sie einen neuen Pull Request für den Hauptzweig des Quellcode-Repositorys der Anwendung.
Beobachten Sie: die "Standard"-PR-Pipeline DevSecOps wird ausgelöst
Klicken Sie auf der PR-Seite auf Merge when ready und dann auf Attempt merge when ready- dadurch wird der PR unter enqueue in die Warteschlange für die Zusammenführung aufgenommen, sobald der "normale" PR abgeschlossen ist.
Warten Sie auf den erfolgreichen Abschluss des "Standard" DevSecOps PR
Beachten Sie: Sobald die PR-Pipeline abgeschlossen ist, wird der PR zur Merge Queue hinzugefügt und der PR in der Merge Queue wird ausgelöst:
- Warten Sie auf die Fertigstellung der Warteschlangenzusammenführung PR
- Wenn erfolgreich, wird der PR mit einem Kommentar wie Merged via the queue into main with commit abcdefg
- Wenn der PR nicht erfolgreich ist (z.B.: fehlgeschlagene Konformitätsprüfung), wird er nicht automatisch zusammengeführt und aus der Zusammenführungs-Warteschlange entfernt.

PR-Nutzlast Übersicht

Nutzdaten

Ein Payload ist ein allgemeiner Begriff, der einen strukturierten Datenblock, in der Regel im JSON-Format, beschreibt, der als Teil eines Ereignisses oder einer Anfrage übertragen wird. Payloads werden häufig in Webhooks, APIs und Automatisierungssystemen verwendet, um relevante Informationen in einer maschinenlesbaren Form zu übermitteln.

Payloads können je nach Kontext eine breite Palette von Inhalten darstellen, z. B. Build-Metadaten, Benutzeraktivitäten, Issue-Updates oder, wie in diesem Fall, Details zu Pull Requests.

PR-Nutzlast

#cd-devsecops-pr-Nutzlast

Der PR-Payload ist eine spezifische Instanz eines Payloads, der Metadaten und Kontextinformationen über einen Pull Request (PR) kapselt. Sie wird generiert, wenn ein Pull-Request-Ereignis eintritt, und bietet einen strukturierten Zugriff auf Schlüsselattribute, die mit diesem PR zusammenhängen.

Diese Nutzlast umfasst eine breite Palette von Daten wie z. B:

PR-Titel und Beschreibung
Autor und Gutachter
Quell- (Kopf) und Zielzweige (Basis)
Commit-Historie und SHA-Referenzen
Repositorydetails
Zeitstempel, Etiketten, Status und mehr

Während die vollständige Nutzlast umfangreiche Informationen enthält, wird derzeit nur eine bestimmte Teilmenge der Felder extrahiert und als Umgebungsvariablen zur Verwendung in Pipelines, Skripten und Konfigurationsdateien bereitgestellt.

Aus der PR-Nutzlast extrahierte Umwelteigenschaften

Die folgenden Umgebungsvariablen werden derzeit von der PR-Payload abgeleitet und aktiv verwendet:

Variablenname	Beschreibung
`head-branch`	Der Quellzweig des PR (Zweig, aus dem zusammengeführt wird)
`head-sha`	Die SHA der letzten Übergabe im Hauptzweig
`head-repo`	Das Repository, aus dem der PR stammt
`base-branch`	Der Zielzweig des PR (Zweig, in den zusammengeführt wird)
`base-repo`	Der vollständige Verweis auf das Basis-Repository
`base-repo-name`	Der Name des Basis-Repositorys
`base-repo-owner`	Der Eigentümer (Benutzer oder Organisation) des Basis-Repositorys
`commit-timestamp`	Der Zeitstempel der letzten Übertragung im PR
`pr-url`	Die API URL der Pull-Anfrage
`pr-html-url`	Das Web (HTML) URL der Pull-Anfrage
`pr-title`	Der Titel der Pull-Anfrage
`action`	status der PR
`base_ref`	zielzweig der PR

Diese Werte werden als Umgebungsvariablen injiziert, um den Zugriff während der Ausführung in automatisierten Arbeitsabläufen zu vereinfachen.

Die PR-Nutzlast enthält viele zusätzliche Felder, die über die oben aufgeführten hinausgehen. Allerdings wird derzeit nur die extrahierte Teilmenge für operative Zwecke genutzt. Bei Bedarf kann der Zugriff auf die gesamte Nutzlast für fortgeschrittene Anwendungsfälle oder zukünftige Erweiterungen bereitgestellt werden.