Skip to main content

​
Übersicht

​
Funktionsweise

Blocking Rules sind Guardrails, die festlegen, welche Findings einen Pull-Request-Check oder eine CI-Pipeline fehlschlagen lassen. So stellen Sie sicher, dass Ihre Codebasis den Sicherheits- und Qualitätsstandards Ihrer Organisation entspricht. Sie können drei Arten von Blocking Rules erstellen:
  • Code Vulnerability Rules: Blockieren PRs aufgrund von Sicherheitslücken, Code-Quality-Befunden oder beidem
  • Dependency Vulnerability Rules: Blockieren PRs aufgrund anfälliger Abhängigkeiten, die bei SCA-Scans gefunden wurden
  • License Compliance Rules: Blockieren Abhängigkeiten mit bestimmten SPDX-Lizenzen oder Lizenzfamilien

​
Zielgruppe

Blocking Rules richten sich hauptsächlich an:
  • Entwicklungsteams
  • Projektmanager
  • Security Engineers
Diese Funktion ist besonders nützlich für Organisationen mit strengen Compliance-Anforderungen oder für diejenigen, die an geschäftskritischen Anwendungen arbeiten, bei denen Code Quality und Sicherheit von größter Bedeutung sind.

​
Hauptmerkmale und Vorteile

Definieren Sie Regeln anhand von Common Weakness Enumerations (CWEs), um Pull Requests zu blockieren, die bestimmte Schwachstellen oder Code-Quality-Probleme einführen.
Weisen Sie verschiedenen Arten von Problemen Dringlichkeitsstufen zu (z. B. kritisch, hoch, mittel, niedrig), sodass Sie sie entsprechend priorisieren und bearbeiten können.
Definieren Sie für Dependency Vulnerability Rules einen einschließlich der Grenzwerte geltenden CVSS-Bereich, um anfällige Abhängigkeiten anhand ihres CVSS-Scores zu blockieren.
Blockieren Sie Abhängigkeiten anhand bestimmter SPDX-Lizenz-IDs oder der Lizenzfamilien Copyleft, Permissive und Commercial.
Wenden Sie Blocking Rules auf bestimmte Projekte, Projekt-Tags oder Ihre gesamte Organisation an. So steuern Sie präzise, welche Regeln für welche Projekte gelten.
Erstellen, bearbeiten und löschen Sie Blocking Rules über eine übersichtliche Oberfläche, damit die Regeln mit Ihren Anforderungen Schritt halten.
Schalten Sie den Status von Blocking Rules um, um sie bei Bedarf vorübergehend zu aktivieren oder zu deaktivieren, ohne ihre Konfigurationen zu verlieren.

​
Regeltypen

Blocking Rules unterstützen für eine umfassende Absicherung drei verschiedene Typen:

Code Vulnerability

Blockiert Pull Requests basierend auf Sicherheitslücken, Code-Qualitätsbefunden oder beidem.Konfiguration:
  • Issue-Typ auswählen: All, Vulnerabilities oder Code Quality
  • Bestimmte CWE-Kategorien (Common Weakness Enumeration) auswählen
  • Festlegen von Dringlichkeits-/Schweregraden
Verhindern Sie damit unter anderem SQL-Injection, XSS, unsichere Kryptografie und andere Schwachstellen auf Codeebene.

Dependency Vulnerability

Blockiert Pull Requests aufgrund anfälliger Abhängigkeiten, die durch Software Composition Analysis (SCA) gefunden wurden.Konfiguration:
  • Festlegen von Dringlichkeits-/Schweregraden (Kritisch, Hoch, Mittel, Niedrig)
  • Alternativ einen einschließlich der Grenzwerte geltenden CVSS-Bereich von 0,0 bis 10,0 festlegen
Verhindern Sie damit, dass Pakete mit bekannten Schwachstellen in Ihre Software-Lieferkette gelangen.

License Compliance

Blockiert Pull Requests oder CI-Pipelines, wenn eine Abhängigkeit eine abgelehnte Lizenz verwendet.Konfiguration:
  • Eine oder mehrere Lizenzfamilien auswählen: Copyleft, Permissive oder Commercial
  • Bestimmte SPDX-Lizenz-IDs eingeben, z. B. AGPL-3.0
Nutzen Sie dies, um die Open-Source- und kommerzielle Lizenzrichtlinie Ihrer Organisation durchzusetzen.

​
So funktioniert es mit GitHub

Voraussetzung Sie müssen die Corgea GitHub App installiert und mit den entsprechenden Repository-Berechtigungen konfiguriert haben.
1

Pull Request einreichen

Ein Entwickler reicht einen Pull Request mit Codeänderungen ein
2

Automatisierte Analyse

Das System analysiert die Codeänderungen anhand der aktiven Blocking Rules
3

Regelüberprüfung

Bei Regelverstößen wird der Pull Request automatisch blockiert
4

Benachrichtigung des Entwicklers

Der Entwickler erhält eine detaillierte Benachrichtigung über Regelverstöße
5

Behebung

Vor dem Merge muss der Entwickler die Verstöße beheben und als Fixed markieren oder sie als False Positive beziehungsweise Accepted Risk kennzeichnen

​
So funktioniert es mit Azure DevOps

Voraussetzung Stellen Sie sicher, dass die Azure DevOps-Integration mit Corgea konfiguriert ist und Sie die erforderlichen Berechtigungen besitzen.
1

Pull Request einreichen

Ein Entwickler reicht in Azure DevOps einen Pull Request mit Codeänderungen ein.
2

Automatisierte Analyse

Das System prüft die Codeänderungen anhand der in Corgea aktiven Blocking Rules.
3

Regelüberprüfung

Bei Regelverstößen wird der Pull Request automatisch blockiert.
Der Entwickler kann den PR erst mergen, nachdem die Verstöße behoben wurden.
4

Benachrichtigung des Entwicklers

Der Entwickler erhält einen Link zu ausführlichen Informationen über die beanstandeten Issues auf der Scan-Seite von Corgea.
5

Behebung

Vor dem Merge muss der Entwickler die Verstöße beheben oder als False Positive beziehungsweise Accepted Risk markieren.

​
Bedienungsanleitung

​
Neue Blocking Rule erstellen

1

Erstellung initiieren

Klicken Sie auf “Add Blocking Rule”
2

Regeltyp wählen

Wählen Sie den Typ der Blocking Rule:
  • Code Vulnerability: Blockiert Pull Requests aufgrund von Sicherheitsproblemen im Code (SAST-Befunde)
  • Dependency Vulnerability: Blockiert Pull Requests aufgrund anfälliger Abhängigkeiten (SCA-Befunde)
  • License Compliance: Blockiert Abhängigkeiten anhand abgelehnter SPDX-Lizenzen oder Lizenzfamilien
Add Blocking Rule modal with Applies To, rule types, and Issue Type
3

Grundinformationen

Geben Sie Regelname und Beschreibung ein und wählen Sie anschließend Applies To:
  • Pull Requests setzt die Regel automatisch in Pull-Request-Checks durch.
  • CI setzt die Regel nur durch, wenn eine Pipeline sie mit corgea scan --block-on <slug> benennt. CI-Regeln blockieren keine Pull Requests.
Neue Regeln verwenden standardmäßig Pull Requests. Corgea erzeugt den Slug aus dem Regelnamen und zeigt ihn in der Regelliste an.
Add Blocking Rule modal with CI selected and License Compliance configured
4

Einstellungen konfigurieren

Für Code Vulnerability Rules: Wählen Sie unter Issue Type, ob die Regel für All Befunde, nur Vulnerabilities oder nur Code Quality gelten soll. All ist die Standardeinstellung und entspricht dem Verhalten vorhandener Regeln. Wählen Sie anschließend Dringlichkeitsstufen (Critical, High, Medium oder Low) und/oder Ziel-CWEs aus. Mindestens eine dieser Angaben ist erforderlich.Für Dependency Vulnerability Rules: Wählen Sie die Filterung nach Schweregrad oder CVSS-Score. Wählen Sie Dringlichkeitsstufen (Critical, High, Medium oder Low) oder geben Sie einen minimalen und maximalen CVSS-Score zwischen 0,0 und 10,0 ein. Die Grenzwerte sind jeweils eingeschlossen.Für License Compliance Rules: Wählen Sie mindestens eine abgelehnte Lizenzfamilie (Copyleft, Permissive oder Commercial) oder geben Sie eine oder mehrere SPDX-Lizenz-IDs ein. Eine Abhängigkeit wird blockiert, wenn eine gemeldete Lizenz einer ausgewählten Familie oder einer bestimmten ID entspricht.
5

Bereich festlegen

Wählen Sie zutreffende Projekte und/oder Projekttags (optional) aus. Eine Regel gilt, wenn ein Projekt direkt ausgewählt ist oder einen ausgewählten Tag hat. Wenn keine Projekte oder Tags ausgewählt sind, gilt die Regel für alle Projekte.
6

Speichern

Prüfen Sie die Angaben und klicken Sie auf “Create”

​
Vorhandene Regeln verwalten

Suchen Sie Regeln anhand ihres Namens oder ihrer Einstellungen, oder filtern Sie die Liste nach Projekt-Tag oder Applies To-Ziel. Die Regeltabelle zeigt den Slug jeder Regel in der Spalte ID und stellt Projektumfang, Regeltyp sowie das Ziel Pull Requests oder CI unter Triggers On dar. Wählen Sie einen Slug aus, um ihn für einen CI-Befehl zu kopieren. Regeln ohne Projekt- oder Tag-Scope gelten für alle Projekte; längere Scope-Listen werden hinter einem Tooltip +N more zusammengefasst.
Blocking rules list showing slug, Triggers On chips, and CI badge

​
Regeln in CI durchsetzen

Erstellen Sie eine aktive Regel mit Applies To auf CI, und übergeben Sie ihren Slug an den Scan-Befehl. Benennen Sie Regeln nach der auslösenden Bedingung — zum Beispiel criticals, nicht no-criticals —, damit --block-on wie eine direkte Aussage gelesen wird. --block-on erfordert Corgea CLI 1.10.0 oder neuer.
Um mehrere CI-Regeln durchzusetzen, geben Sie ihre Slugs als kommagetrennte Liste an. Der Befehl schlägt fehl, wenn ein Finding gegen eine der genannten Regeln verstößt. Ein unbekannter Slug, eine inaktive Regel oder eine Regel für Pull Requests wird als Konfigurationsfehler behandelt und nicht übersprungen. --block-on wird nur vom BLAST-Scanner unterstützt und kann nicht mit --fail oder --fail-on kombiniert werden.
  1. Regel in der Tabelle finden
  2. Klicken Sie auf “Edit”
  3. Passen Sie die Einstellungen nach Bedarf an
  4. Klicken Sie zum Speichern auf “Update”

​
Regeln bei Scans anzeigen

Sie können Blocking Rules, die für Ihre Scans gelten, an zwei Orten anzeigen:
  1. Auf der Detailseite des Scans sehen Sie einen Abschnitt “Blocking Rules”, der alle ausgewerteten Regeln zeigt:
  1. In den Details einzelner Issues sehen Sie, welche Blocking Rules ausgelöst wurden:
So erkennen Sie, welche Regeln sich auf Ihre Scans und einzelne Issues auswirken und weshalb bestimmte Änderungen blockiert werden.

​
Beispiele

Regeltyp: Code VulnerabilityErstellen Sie eine Regel, die auf CWE-326 (Inadequate Encryption Strength) und CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) mit der Dringlichkeit “Critical” abzielt, um die Verwendung schwacher Verschlüsselung zu verhindern.
Regeltyp: Code VulnerabilityWählen Sie Code Quality als Issue-Typ und erstellen Sie eine Regel für CWE-398 (Indicator of Poor Code Quality) und CWE-477 (Use of Obsolete Functions) mit der Dringlichkeit “Medium”, um Ihre Code-Standards durchzusetzen.
Regeltyp: Dependency VulnerabilityErstellen Sie eine Regel mit den Dringlichkeitsstufen “Critical” und “High”. Sie blockiert automatisch alle Pull Requests, die Abhängigkeiten mit kritischen oder schwerwiegenden Schwachstellen einführen, und schützt so Ihre Software-Lieferkette vor bekanntermaßen anfälligen Paketen.
Regeltyp: Dependency VulnerabilityErstellen Sie eine Regel, die nach CVSS-Score filtert, z. B. 7,0 bis 10,0, um Pull Requests zu blockieren, die verwundbare Abhängigkeiten innerhalb dieses Score-Bereichs einführen.
Regeltyp: License ComplianceWählen Sie die Familie Copyleft, um Abhängigkeiten zu blockieren, deren gemeldete Lizenzen zu dieser Familie gehören. Fügen Sie bestimmte SPDX-IDs hinzu, wenn Ihre Richtlinie eine engere Ablehnungsliste benötigt.

​
Best Practices

Implementierungstipps

  • Beginnen Sie mit den wesentlichen Regeln und erweitern Sie sie schrittweise
  • Beginnen Sie bei Dependency Vulnerability Rules nur mit dem Schweregrad Critical oder einem gezielten CVSS-Bereich und erweitern Sie die Regel, sobald sich Ihr Team darauf eingestellt hat
  • Konzentrieren Sie sich bei Code Vulnerability Rules zunächst auf die folgenreichsten CWEs (z. B. Injection- und Authentifizierungsfehler)
  • Regelmäßige Überprüfung und Aktualisierungen
  • Klare Dokumentation und Schulung des Teams
  • Feedback und Zusammenarbeit fördern
  • Strategische Nutzung von Dringlichkeitsstufen
  • Berücksichtigen Sie Projekttags, wenn dieselbe Regel eine Gruppe verwandter Projekte abdecken soll

​
Fehlerbehebung

Wenn ein Pull Request unerwartet blockiert ist, überprüfen Sie zuerst die aktiven Regeln und deren Konfigurationen.
  • Unerwartetes Blockierverhalten
  • Fehlerhafte Zieldefinition der Regel
  • Probleme mit dem Projekt-Scope
  • Überprüfen Sie die Regelkonfigurationen
  • CWE-Zielsetzung überprüfen
  • Projekteinstellungen bestätigen
  • Bei Bedarf den Support kontaktieren