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.
Beschränken Sie bei Dependency Vulnerability Rules, die für die CI gelten, das Blockieren auf Abhängigkeiten, deren anfälliger Code aus Ihrer Anwendung tatsächlich erreichbar ist, damit unbenutzte und nicht erreichbare Pakete Ihre Pipeline nicht fehlschlagen lassen.
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
  • Optional eine Einschränkung nach Erreichbarkeit (nur CI-Regeln)
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.Pull-Request-Regeln kommentieren nur Findings, die eine Aktion erfordern. Corgea überspringt Kommentare für als nicht erreichbar bestätigte Findings, wegen eines False Positive oder einer nicht unterstützten Sprache zurückgehaltene Findings sowie Findings in vom Projekt ignorierten Pfaden. Diese Findings bleiben zur Prüfung in Corgea verfügbar, blockieren den Pull Request jedoch nicht.
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. Wenn die Regel für die CI gilt, können Sie zusätzlich einen oder mehrere Erreichbarkeits-Zustände auswählen, um sie weiter einzuschränken — siehe Filtern nach Erreichbarkeit.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.

​
Filtern nach Erreichbarkeit

In den meisten Projekten wird der Großteil der anfälligen Abhängigkeiten von Ihrem Code nie tatsächlich ausgeführt. Mit dem Erreichbarkeitsfilter blockiert eine Dependency Vulnerability Rule nur die relevanten Funde, sodass eine kritische CVE in einem Paket, das Sie nie aufrufen, Ihre Pipeline nicht fehlschlagen lässt.
Nur für CI-Regeln verfügbar Die Erreichbarkeit wird nur bei Scans analysiert, die Sie selbst mit corgea scan starten, nicht bei Scans, die beim Öffnen eines Pull Requests automatisch ausgelöst werden. Setzen Sie Applies To auf CI, um diesen Filter zu nutzen; bei Pull-Request-Regeln ist die Option ausgeblendet. Referenzieren Sie die Regel anschließend in Ihrer Pipeline mit corgea scan --block-on <slug>.
Voraussetzung Erreichbarkeit erfordert, dass AI-Native SCA für Ihre Organisation aktiviert ist. Ohne diese Option wird keine Abhängigkeit analysiert, sodass eine Regel mit diesem Filter nie etwas blockiert. Der Regeleditor warnt Sie, wenn die Option deaktiviert ist.
Add Blocking Rule modal with CI and Dependency Vulnerability selected and Reachable checked under Reachability
Wählen Sie einen oder mehrere der folgenden Zustände: Der Erreichbarkeitsfilter wird mit dem Schweregrad-, CVSS- oder Malicious-Filter kombiniert und ersetzt ihn nicht: Ein Fund muss beide Bedingungen erfüllen. Eine Regel mit Schweregrad Critical und Reachable blockiert nur kritische Schwachstellen, die zugleich erreichbar sind. Bleibt die Erreichbarkeit leer, behält die Regel ihr bisheriges Verhalten und blockiert unabhängig von der Erreichbarkeit.

​
Warten auf die Analyse

Die Erreichbarkeitsanalyse läuft nach Abschluss des eigentlichen Scans. corgea scan fragt daher weiter ab, bis sie beendet ist, statt sofort ein Ergebnis zu melden. Die Analyse ist abgeschlossen, sobald alle direkten Abhängigkeiten analysiert sind — üblicherweise nach wenigen Minuten und spätestens nach 30. Dieser Filter schlägt zugunsten des Builds fehl. Kann die Analyse nicht abgeschlossen werden — das 30-Minuten-Fenster läuft ab, die Analyse schlägt fehl oder AI-Native SCA ist deaktiviert —, meldet die Regel keinen Verstoß, statt Ihren Build fehlschlagen zu lassen. Eine Pipeline wird nur aufgrund einer von Corgea tatsächlich bestimmten Erreichbarkeit blockiert, niemals aufgrund einer fehlenden Analyse.
corgea scan schlägt bei Ablauf der eigenen Frist restriktiv fehl. Corgea CLI 1.13.0 und höher erlauben 35 Minuten und überdauern damit das 30-Minuten-Analysefenster deutlich. Bei einer älteren CLI beträgt die Frist 15 Minuten und kann ablaufen, während Corgea noch analysiert, was die Pipeline fehlschlagen lässt. Aktualisieren Sie die CLI oder erhöhen Sie die Frist mit CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS:

​
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: Dependency Vulnerability — Gilt für: CIWählen Sie die Dringlichkeitsstufen „Critical“ und „High“ und anschließend Reachable unter Erreichbarkeit. Die Regel lässt eine Pipeline nur dann fehlschlagen, wenn eine kritische oder hohe Schwachstelle aus Ihrem Anwendungscode erreichbar ist, sodass unbenutzte und nicht erreichbare Pakete Entwickler nicht aufhalten. Das ist eine gute erste Erreichbarkeitsregel, weil sie eine bestehende Schweregradregel einschränkt, anstatt den Umfang des Blockierens zu erweitern.
Regeltyp: Dependency Vulnerability — Gilt für: CIWählen Sie Unused Dependency unter Erreichbarkeit allein, ohne Schweregrad- oder CVSS-Filter. Die Regel lässt eine Pipeline fehlschlagen, die anfällige Pakete einführt, die im Code nirgends verwendet werden, und veranlasst Entwickler, die Abhängigkeit zu entfernen statt zu aktualisieren.
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
  • Ergänzen Sie bei CI-Regeln eine bestehende Schweregradregel um den Erreichbarkeitsfilter Reachable, um Rauschen zu reduzieren, ohne die Abdeckung der tatsächlich ausnutzbaren Schwachstellen zu schwächen
  • 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