Wann eine Pipeline fehlschlagen sollte und wann eine Warnung reicht

Sie haben gerade einen Sicherheitsscanner in Ihre CI-Pipeline eingebaut. Der erste Scan läuft und findet 47 Probleme. Drei sind als kritisch markiert, zwölf als hoch, der Rest ist mittel und niedrig. Jetzt müssen Sie entscheiden: Lassen Sie die Pipeline bei jedem Fund fehlschlagen, oder lassen Sie alles durch und sammeln nur Berichte?

Wenn Sie bei allem fehlschlagen, wird Ihre Pipeline öfter rot als grün sein. Entwickler werden den Scanner ignorieren oder, schlimmer noch, Wege finden, ihn zu umgehen. Wenn Sie die Pipeline nie fehlschlagen lassen, wird der Scanner zum Rauschen. Niemand liest die Berichte, und dieselben Schwachstellen bleiben monatelang in Ihrer Codebasis.

Keines der Extreme funktioniert. Die Antwort ist ein Schweregrad-Schwellenwert.

Der Schweregrad sagt, was wichtig ist

Jeder Sicherheitsscanner gruppiert Funde nach Schweregrad. Die Bezeichnungen variieren leicht zwischen den Tools, aber das Muster ist konsistent: kritisch, hoch, mittel, niedrig und manchmal Info oder unbekannt. Diese Bezeichnungen sind keine Dekoration. Sie schätzen ab, wie schlimm es werden könnte, wenn jemand diese Schwachstelle ausnutzt.

Ein kritischer Fund in einer Bibliothek, die die Benutzerauthentifizierung handhabt, ist etwas anderes als ein niedriger Fund in einem Code, der einmal während der Einrichtung läuft und danach nie wieder. Beide gleich zu behandeln, ist ein Fehler.

Die einfache Regel: Lassen Sie die Pipeline bei kritischen und hohen Funden fehlschlagen. Lassen Sie mittlere und niedrige Funde mit einer Warnung durchgehen.

Der Entscheidungsbaum unten fasst die Regel zusammen:

flowchart TD A[Scanner Finding] --> B{Critical or High?} B -->|Yes| C[Fail Pipeline] B -->|No| D{Medium or Low?} D -->|Yes| E[Warn, Pass Pipeline] D -->|No| F[Ignore / Info]

Warum das in der Praxis funktioniert

Wenn Sie bei kritischen und hohen Funden fehlschlagen, blockieren Sie die gefährlichsten Probleme, bevor sie in die Produktion gelangen. Das sind die Schwachstellen, nach denen Angreifer aktiv suchen. Sie sind diejenigen, die zu Datenlecks, Service-Übernahmen und Compliance-Verstößen führen.

Wenn Sie bei mittleren und niedrigen Funden warnen, halten Sie die Pipeline am Laufen. Entwickler können ihre Arbeit fortsetzen. Das Team wird nicht durch Probleme blockiert, die in der Praxis vielleicht nie relevant werden. Aber die Warnungen werden aufgezeichnet, und jemand muss sie später überprüfen.

Diese Balance hält die Pipeline nützlich, ohne sie zu einem Engpass zu machen.

Ausnahmen gibt es, aber sie brauchen Regeln

Die einfache Regel ist ein guter Ausgangspunkt, aber reale Projekte haben Randfälle.

Manchmal gibt es für einen hohen Fund noch keinen Patch. Der Hersteller hat noch keinen Fix veröffentlicht, und Sie können die Abhängigkeit nicht entfernen, weil sie zentral für Ihre Anwendung ist. In diesem Fall hilft es niemandem, die Pipeline jedes Mal fehlschlagen zu lassen. Sie brauchen eine Möglichkeit, diesen Fund vorübergehend zu akzeptieren, während Sie den Hersteller nach einem Fix verfolgen.

Manchmal befindet sich ein mittlerer Fund in einer sensiblen Komponente wie Verschlüsselung oder Authentifizierung. Auch wenn der Scanner ihn als mittel einstuft, ist das Risiko aufgrund des Kontexts höher. Möglicherweise möchten Sie die Pipeline für diesen spezifischen Fund fehlschlagen lassen, obwohl er nicht kritisch oder hoch ist.

Hier wird ein risikobasiertes Quality Gate nützlich, anstatt eines einfachen zählbasierten Gates.

Bauen Sie ein Quality Gate, keine Null-Funde-Regel

Ein häufiger Fehler ist die Regel „Pipeline schlägt fehl, wenn es irgendwelche Funde gibt“. Das klingt streng und sicher, aber in der Praxis schafft es Probleme. Scanner produzieren False Positives. Sie markieren Dinge, die in Ihrer spezifischen Umgebung tatsächlich nicht ausnutzbar sind. Wenn Sie bei allem fehlschlagen, lernen Entwickler, den Scanner zu ignorieren oder für alles Ausnahmen zu beantragen. Das Gate verliert seine Bedeutung.

Ein besseres Quality Gate bewertet, ob Funde einen Risikoschwellenwert verletzen. Beispiele:

  • Pipeline schlägt fehl, wenn es kritische oder hohe Funde ohne genehmigte Ausnahme gibt.
  • Pipeline schlägt fehl, wenn es einen mittleren Fund im Authentifizierungsmodul gibt.
  • Pipeline schlägt fehl, wenn derselbe Fund länger als 30 Tage ohne Maßnahme offen ist.

Diese Regeln sind realistischer als „Null Funde“. Sie erkennen an, dass einige Schwachstellen verwaltet werden können, während andere sofort blockiert werden müssen.

So konfigurieren Sie Ihren Schwellenwert

Beginnen Sie mit dem, was Ihr Scanner bereits bietet. Die meisten Scanner erlauben es, den Exit-Code basierend auf dem Schweregrad zu konfigurieren. Setzen Sie kritisch und hoch so, dass der Build fehlschlägt. Setzen Sie mittel und niedrig so, dass der Build durchläuft, aber eine Warnung protokolliert wird.

Fügen Sie dann Benachrichtigungen hinzu. Wenn mittlere und niedrige Funde auftauchen, senden Sie eine Nachricht an den Chat-Kanal des Teams oder erstellen Sie ein Ticket in Ihrem Issue-Tracker. Das Team sollte diese Funde regelmäßig überprüfen, vielleicht jeden Sprint oder vor jedem größeren Release. So gehen die Funde nicht verloren, blockieren aber auch nicht die tägliche Arbeit.

Nachdem der grundlegende Schwellenwert läuft, beobachten Sie sein Verhalten. Wenn die Pipeline zu oft fehlschlägt, prüfen Sie, ob die Funde echt oder False Positives sind. Wenn die Pipeline fast nie fehlschlägt, prüfen Sie, ob Ihr Scanner richtig konfiguriert ist und die richtigen Dinge scannt.

Was ein Gate tatsächlich bewirkt

Ein Sicherheits-Gate in Ihrer Pipeline ist keine Garantie dafür, dass Ihre Anwendung perfekt sicher ist. Kein automatisierter Scanner kann jede Schwachstelle finden. Keine Pipeline-Regel kann jeden Fehler verhindern.

Was ein Gate bewirkt, ist, die gefährlichsten Probleme automatisch davon abzuhalten, in die Produktion zu gelangen. Es fängt die Dinge, die Sie nachts wachhalten würden, wenn sie deployed würden. Für alles andere verlassen Sie sich auf manuelle Überprüfung, geplante Behebung und gute Engineering-Praktiken.

Das ist realistischer und nachhaltiger, als zu versuchen, Null Funde zu erreichen. Teams, die auf Null Funde abzielen, brennen oft aus oder fangen an, das System zu umgehen. Teams, die darauf abzielen, die schlimmsten Probleme zu blockieren und den Rest zu verwalten, bleiben tendenziell langfristig effektiv.

Praktische Checkliste

  • Setzen Sie kritische und hohe Funde so, dass die Pipeline fehlschlägt.
  • Setzen Sie mittlere und niedrige Funde so, dass sie mit einer Warnung durchgehen.
  • Konfigurieren Sie Benachrichtigungen für mittlere und niedrige Funde, damit das Team sie später überprüfen kann.
  • Erstellen Sie einen Prozess zur Genehmigung von Ausnahmen, wenn ein Fund nicht sofort behoben werden kann.
  • Lassen Sie Ausnahmeanträge von einer kleinen Gruppe prüfen, nicht von einer einzelnen Person.
  • Setzen Sie Ablaufdaten für Ausnahmen, damit sie nicht für immer offen bleiben.
  • Überprüfen Sie Ihren Schwellenwert alle paar Monate, um ihn basierend auf der tatsächlichen Erfahrung anzupassen.

Das Fazit

Ihr Pipeline-Gate muss nicht alles abfangen. Es muss die Dinge abfangen, die am wichtigsten sind. Beginnen Sie mit kritisch und hoch als harte Blocker. Lassen Sie mittel und niedrig als Warnungen durchgehen, die das Team nach einem Zeitplan überprüft. Bauen Sie einen einfachen Ausnahmeprozess für Fälle, in denen ein Fix nicht sofort möglich ist. Diese Kombination hält Ihre Pipeline am Laufen und macht Ihre Produktionsumgebung sicherer, als wenn Sie versuchen, alles zu blockieren.