Compliance mit Prüfungen durch Peers

Peer-Code-Prüfungen sind eine Schlüsselkomponente für die Bereitstellung sicherer und konformer Software. Die Referenzimplementierung DevSecOps hilft dabei, die Überprüfung von Codeänderungen durchzusetzen, bevor diese zusammengeführt und in die Produktion überführt werden.

Peer-Review-Check-in-CI/CD-Toolchains verwalten

Diese Dokumentation enthält Anweisungen zum Aktivieren und Inaktivieren der Überprüfung durch Peers in Continuous Integration (CI) und optional in CD-Toolchains ( Continuous Delivery ).

CI-Toolchain (Continuous Integration)

Standardmäßig ist die Peer-Review-Prüfung in der CI-Toolchain aktiviert. So ändern Sie diese Einstellung:

Um die Prüfung auf Peerüberprüfung zu aktivieren, setzen Sie den Wert der Umgebungsvariablen peer-review-compliance auf 1.
Um die Prüfung auf Peerprüfung zu inaktivieren, setzen Sie den Wert der Umgebungsvariablen peer-review-compliance auf 0.

Continuous Delivery (CD) Toolchain

Die folgenden Umgebungsvariablen ermöglichen Ihnen die Verwaltung der Peer-Review-Prüfung in Ihrer CD-Toolchain:

Um eine Liste der Pull-Anforderungen und der zugehörigen Titel für Ihre laufende Bereitstellung abzurufen, setzen Sie die Umgebungsvariable peer-review-collection auf 1. Beachten Sie, dass diese Variable standardmäßig auf 1 gesetzt ist. Um diese Liste zu inaktivieren, setzen Sie peer-review-collection auf 0.
Um die Validierung der Peerüberprüfung für alle Pull-Anforderungen zu aktivieren, die Ihrer aktuellen Bereitstellung zugeordnet sind, setzen Sie die Umgebungsvariable peer-review-compliance auf 1. Standardmäßig ist diese Variable auf 0 gesetzt. Um diese Validierung zu umgehen, setzen Sie peer-review-compliance auf 0.

Wichtige Punkte

Sie müssen Peerprüfungen nur in der geschützten (Basis-) Verzweigung durchführen, in der der Bestand aktualisiert wird. Wenn Sie eine CI-Pipeline für eine Featureverzweigung ausführen, setzen Sie die Umgebungsvariable peer-review-compliance für diesen speziellen Auslöser auf 0, um die Prüfung der Peerüberprüfung für die Featureverzweigung zu verhindern.

Die Einhaltung der Einhaltung der Peer-Review-Konformität hängt vom Abschluss einer erfolgreichen Ausführung der Pipeline für kontinuierliche Integration (Continuous Integration, CI) und dem anschließenden Einstieg in den Bestand ab. Daher wird bei der ersten Ausführung der CI-Pipeline die Konformitätsprüfung für die Peerprüfung übersprungen.

Um die Einhaltung von Peer-Review-Standards sicherzustellen, wird davon ausgegangen, dass Bestandsaktualisierungen in der Stufe ci-finish in der Verzweigung master stattfinden. Wenn Ihre Bestandsaktualisierungen jedoch in einer anderen Verzweigung als der Masterverzweigung ausgeführt werden, können Sie die Umgebungsvariable inventory-repo-branch festlegen, um die Verzweigung anzugeben, in der die Bestandsaktualisierungen stattfinden.

Es wird erwartet, dass in der Continuous-Deployment-Pipeline (CD-Pipeline) alle Inventarisierungsaktualisierungen, die im Inventarisierungs-Repository vorgenommen werden, in den zu verteilenden Zielzweig übertragen werden, um sicherzustellen, dass keine Commits verpasst werden. Standardmäßig wird das Inventar-Repository während der Bereitstellung in den Zielzweig ausgecheckt. Wenn Ihr Zielzweig für die Inventarisierung jedoch einige Commits zwischen dem Basiszweig und dem Zielzweig vermisst, können Sie die Umgebungsvariable inventory-repo-branch setzen, um den Basiszweig anzugeben, in dem sich alle Inventarisierungs-Commits befinden.

Standardmäßig führt die CI-Pipeline (Continuous Integration) am Ende der Ausführung automatisch eine Festschreibung im Bestandsrepository durch, wobei der Anwendungsname als Bestandseintrag verwendet wird. Wenn Sie jedoch beabsichtigen, den Bestandseintrag während der Releasephase zu ändern, wird empfohlen, eine Umgebungseigenschaft mit dem Namen inventory-entry-name in Ihre Toolchain zu integrieren. Diese Eigenschaft sollte den geänderten Bestandsnamen für den Peer-Prüfprozess enthalten.

Wenn Sie eine Automatisierung haben, die Commits direkt in Ihren geschützten Zweig überträgt und Sie Probleme mit der Überprüfung der Einhaltung von Peer-Reviews vermeiden wollen, stellen Sie sicher, dass Ihre Commit-Nachricht ##AUTOMATED_COMMIT## enthält.

Die Referenzimplementierung deckt Fälle von Code auf, der nicht von Fachkollegen geprüft wurde, sammelt Beweise und erstellt Vorfallsprobleme, um diese Punkte zu verfolgen.

Bevor Sie den Code im Master-Zweig (geschützter Zweig) zusammenführen können, muss der Code von einer Person überprüft werden, die den geänderten Code nicht hochgeladen hat.

Das Code-Repository (Repo) muss mindestens zwei Mitglieder haben: ein Mitglied mit Admin-Rechten und ein weiteres Mitglied mit Schreibrechten. Wenn Code ohne Prüfung in einem Repository zusammengeführt wird, muss die Aktion im Prüfprotokoll des Code-Repositorys sichtbar sein. Überprüfen Sie in regelmäßigen Abständen das Prüfprotokoll, um diese außergewöhnlichen Situationen zu identifizieren und zu analysieren.

Die Pipeline sammelt Daten zur Einhaltung von Peer-Reviews während der Builds und Implementierungen, um einen Prüfpfad von der Zusammenführung von Code-Pull-/Merge-Anfragen bis hin zu Änderungsanforderungen zu erstellen.

In diesem Diagramm sind PR1, PR2 die Pull-/Zusammenführungsanforderungen, die vor der Zusammenführung genehmigt wurden. Ähnlich gilt für PR4, PR5und PR7. Die rot hervorgehobenen PR3 und PR6werden jedoch ohne Genehmigung zusammengeführt. Dies ist ein Konformitätsverstoß bei der Peerprüfung. Dies wird als Angabe erfasst.

Standardmäßig versucht die Beispielanwendung in der CI-Toolchain, die Mindestanzahl der Prüfer auf 1 zu setzen. Wenn Sie die Anzahl der Prüfer ändern wollen, legen Sie die Umgebungseigenschaft peer_review_approvers wie erforderlich fest. Weitere Informationen zum Festlegen der Mindestanzahl der Prüfer, die für eine Pull-/Merge-Anforderung erforderlich sind, finden Sie in den folgenden GitHub-und GitLab-Ressourcen:

Erfasste Daten bei kontinuierlichen Integrationsläufen

Diese Datensammlung enthält eine Liste aller Commits für die Pull/Merge-Requests, die seit dem letzten Build in App-Repos zusammengeführt wurden.

Daten von Pull-Anforderungen werden direkt aus den App-Repositorys erfasst. Es werden Daten für jede Pull/Merge-Anfrage gesammelt, die sich auf Commits zwischen dem Repo-Commit, der den vorherigen Build ausgelöst hat, und dem aktuell verfügbaren Commit beziehen.

Commits, die keinen Pull-/Merge-Antrag enthalten, führen in den folgenden Versionen der Pipeline zu einem Problem mit der Einhaltung von Vorschriften. Sie können nicht direkt auf den Master-Zweig übertragen.

Ein Konformitätsvorfall enthält normalerweise die folgenden Daten:

Liste der Pull-/Merge-Anforderungs-URLs für die zugehörige Commit-ID.
Anwendungsrepository.
Commit-ID.
Erforderliche Anzahl Genehmigungen.

Die gesammelten Daten werden als Artefakt gespeichert, das in den Asservatenschrank hochgeladen wird, und auf das dann im Asservat selbst verwiesen wird. Das endgültige Beweisergebnis wird durch die genehmigten Pull-/Merge-Anforderungen bestimmt. Nicht genehmigte, aber zusammengeführte Pull-/Merge-Anfragen können diese Art von Beweis nicht erbringen.

Daten, die in kontinuierlichen Bereitstellungsläufen gesammelt werden

Diese Datensammlung enthält eine Liste aller Pull-/Merge-Anfragen, die seit der letzten Bereitstellung in App-Repos zusammengeführt wurden.

Pull Request-Daten werden aus dem Evidence Locker und dem Incident Issue Repo gesammelt.

Der Bestand erfasst Daten aus allen Builds zu zugehörigen Artefakten seit der letzten Bereitstellung.
Das Angabenschließfach erfasst gespeicherte Daten von Prüfungen durch Partner (Peers) aus den Builds.
Das Vorfall-Repos sammelt Informationen über offene Pull-/Merge-Anfragen zu Vorfällen.

Auf die App-Repositorys wird während dieser Datenerfassung nicht zugegriffen. Da davon ausgegangen wird, dass sich die Pipelines für die kontinuierliche Bereitstellung in isolierten Umgebungen befinden, können Sie diese Grenzen nicht überschreiten.

Inhalt von Änderungsanforderungen

Die folgenden Daten sind in der automatisch generierten Änderungsanforderung enthalten:

Liste der Vorfälle von Pull-/Merge-Anfragen, die nicht behoben wurden. Diese Daten umfassen die Details des Vermögenswerts und den Vorfall URL.

Nicht behobene Vorfälle bei Pull-/Merge-Anfragen wirken sich auf die Bereitschaft zur Bereitstellung der Änderungsanfrage aus. Wenn Vorfälle von Pull-/Merge-Anforderungen gefunden werden, werden sie als Schwachstellen betrachtet und die Änderungsanforderung muss manuell geprüft und genehmigt werden.

Korrektur von Vorfällen zu Pull-Anforderungen

Vorfälle zu Pull-Anforderungen werden als Schwachstellen betrachtet, da sie darauf hinweisen, dass nicht geprüfter Code in den freigegebenen Artefakten enthalten ist. Führen Sie die folgenden Schritte aus, um diese Vorfälle zu korrigieren:

Überprüfen Sie die zusammengeführte Änderung rückwirkend.
Erstellen Sie ein Problem des Typs 'Vorfall' mit Informationen zum Beheben vorhandener Probleme mit dem Code.
Fügen Sie die Bezeichnung exempt hinzu oder schließen Sie das Problem mit dem Vorfall der Pull-/Zusammenführungsanforderung.

Der Autor des Pull-/Merge-Requests und die Person, die den Pull-/Merge-Request abschließt, können nicht dieselbe Person sein.

Fehlerbehebung

Fall 1:

Problem

Ein Fehler in der Stufe collect_peer_review_commits in prod-start der CD-Pipeline führt dazu, dass andere Stufen mit Fehlern fehlschlagen. Wenn der folgende Fehler in der Stufe prod_start auftritt

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').

Lösung

Benutzer, die Bestandseinträge besitzen, die von der Ein-Pipeline nicht unterstützt werden, müssen eine Ignorierungsdatei im Bestand hinzufügen. Diese Aktion stellt sicher, dass diese Dateien bei Berechnungen nicht berücksichtigt werden.

Bekannte Probleme

Die Konformität mit der Peer-Prüfung hängt von der Einbeziehung des Bestandseintrags in den Release-Schritt nach jeder Iteration der Pipeline für kontinuierliche Integration (Continuous Integration, CI) ab. Das Überspringen, um den Bestandseintrag für jede fehlgeschlagene CI-Pipeline-Ausführung einzuschließen, kann dazu führen, dass die Peer-Review-Angaben für diese spezielle CI-Pipeline-Ausführung in Ihrer CD-Pipeline ( Continuous Delivery ) ignoriert werden.