Wenn Ihre Sicherheits-Pipeline alles blockiert: Ausnahmen handhaben, ohne Schlupflöcher zu schaffen

Sie haben einen Sicherheitsscan in Ihrer CI-Pipeline. Er findet eine Schwachstelle in einer Bibliothek, von der Ihr Team abhängt. Der Schweregrad ist mittel, aber es gibt noch keine gepatchte Version. Ihre Pipeline schlägt fehl. Ihr Team kann nicht deployen.

Jetzt haben Sie eine Wahl. Sie können den Scan komplett deaktivieren, die Schwelle senken, bis alles durchläuft, oder anfangen, Pipeline-Ergebnisse zu ignorieren. Keine dieser Optionen ist gut. Aber wenn Sie es zu einfach machen, einzelne Funde zu umgehen, verliert die Pipeline ihren Nutzen als Sicherheitsnetz.

Das ist das Ausnahmen-Problem. Jedes Team, das Sicherheits- oder Compliance-Regeln in einer Pipeline durchsetzt, stößt irgendwann darauf. Die Lösung ist nicht, das Gate zu entfernen. Die Lösung ist, einen klaren, rechenschaftspflichtigen Mechanismus für den Umgang mit Ausnahmen zu schaffen.

Warum es Ausnahmen gibt

Ausnahmen sind kein Zeichen für einen kaputten Prozess. Sie sind ein Zeichen dafür, dass die reale Welt nicht immer Ihren Regeln entspricht. Eine Bibliothek hat eine bekannte Schwachstelle, aber der Maintainer hat noch keinen Fix veröffentlicht. Eine Compliance-Regel verbietet eine bestimmte Konfiguration, aber Ihre Infrastruktur kann die Alternative derzeit nicht unterstützen. Ein Sicherheitsfund ist technisch gültig, aber das Risiko ist in Ihrem spezifischen Kontext akzeptabel.

Wenn Ihre Pipeline keine Möglichkeit hat, mit diesen Situationen umzugehen, wird Ihr Team einen Weg drumherum finden. Sie werden den Scan deaktivieren. Sie werden die Schwelle senken. Sie werden anfangen, rote Pipelines als normal zu betrachten. Die Pipeline wird zur Formalität, und die Sicherheitslücken bleiben bestehen.

Das Ziel ist, die Pipeline streng zu halten, während Teams einen legitimen Weg nach vorne haben, wenn sie auf einen echten Blocker stoßen.

Vier Regeln für den Umgang mit Ausnahmen

Ein guter Ausnahmen-Mechanismus hat vier Eigenschaften. Jede verhindert eine bestimmte Fehlerart, auf die Teams häufig stoßen.

Das folgende Flussdiagramm veranschaulicht den vollständigen Lebenszyklus einer Ausnahme, der durch die vier Regeln beschrieben wird:

flowchart TD A[Finding blockiert Pipeline] --> B[Ausnahme erfassen Wer, Was, Warum] B --> C[Zur Genehmigung einreichen] C --> D{Genehmigt?} D -- Nein --> E[Pipeline bleibt blockiert] D -- Ja --> F[Ablaufdatum setzen] F --> G[Ausnahme aktiv Pipeline läuft durch] G --> H{Abgelaufen?} H -- Nein --> G H -- Ja --> I[Pipeline schlägt fehl Ausnahme abgelaufen] I --> J[Prüfen & beheben] J --> K{Blocker behoben?} K -- Ja --> L[Ausnahme entfernen] K -- Nein --> B

1. Ausnahmen müssen dokumentiert werden

Die erste Regel ist die einfachste: Schreiben Sie es auf. Eine Ausnahme ist kein Kommentar in einem Pull Request oder eine Nachricht in einem Chat-Kanal. Sie muss an einem Ort leben, den alle sehen können. Das Sicherheitsteam, das Compliance-Team und das Team, das die Pipeline betreibt, benötigen alle Zugriff auf denselben Eintrag.

Wo Sie sie speichern, ist weniger wichtig als dass Sie sie speichern. Eine Konfigurationsdatei im Repository funktioniert. Ein Eintrag in Ihrem Issue-Tracker funktioniert. Wichtig ist, dass der Eintrag drei Dinge enthält: wer die Ausnahme eingereicht hat, was ausgeschlossen wird und warum.

2. Ausnahmen müssen genehmigt werden

Eine Person sollte nicht allein entscheiden, ein Sicherheits-Gate zu umgehen. Der Entwickler, der den Blocker findet, kann die Ausnahme einreichen, aber die Genehmigung sollte von jemandem kommen, der das Risiko versteht. Ein Sicherheitsingenieur genehmigt sicherheitsrelevante Ausnahmen. Ein Compliance-Beauftragter genehmigt Richtlinienverstöße. Die Genehmigung selbst kann über einen separaten Pull Request oder über einen Genehmigungsschritt in der Pipeline erfolgen.

Dieser Schritt verhindert den häufigsten Missbrauch von Ausnahmen: Ein Entwickler, der seinen eigenen Fund als akzeptabel markiert, ohne dass jemand anderes die Begründung prüft.

3. Ausnahmen müssen ablaufen

Das ist die Regel, die die meisten Teams vergessen. Eine Ausnahme wird erstellt, weil etwas vorübergehend blockiert ist. Sechs Monate später hat die Bibliothek vielleicht einen Patch. Die Infrastrukturbeschränkung könnte behoben sein. Aber die Ausnahme ist immer noch aktiv und lässt dieselbe Schwachstelle stillschweigend bei jedem Deployment durch.

Jede Ausnahme braucht eine zeitliche Begrenzung. Bei einer kritischen Schwachstelle könnte eine Woche angemessen sein. Bei einem Fund mit niedrigem Schweregrad ist ein Monat oder drei Monate vernünftig. Die Dauer hängt von der Art des Funds und dem Kontext ab, aber sie muss existieren.

4. Abgelaufene Ausnahmen müssen die Pipeline zum Scheitern bringen

Der Ablauf ist nutzlos, wenn ihn niemand durchsetzt. Wenn eine Ausnahme abläuft, sollte die Pipeline automatisch am entsprechenden Gate fehlschlagen. Das Team muss nicht daran denken, es zu überprüfen. Die Pipeline selbst wird zur Erinnerung. Wenn der Blocker immer noch da ist, reicht das Team eine neue Ausnahme mit einer aktualisierten Begründung ein. Wenn der Blocker behoben ist, wird die Ausnahme entfernt und die Pipeline läuft wieder durch.

Das erzeugt einen natürlichen Überprüfungszyklus. Jede Ausnahme wird mindestens einmal überprüft, bevor sie fortgesetzt werden kann.

Die Analogie zu technischen Schulden

Dieses Muster ist nicht neu. Es ist die gleiche Art und Weise, wie gute Teams mit technischen Schulden umgehen. Sie tun nicht so, als ob die Schulden nicht existieren. Sie erfassen sie, priorisieren sie und planen Zeit ein, um sie abzubezahlen. Sicherheitsausnahmen funktionieren genauso. Sie ignorieren die Schwachstelle nicht. Sie erkennen sie an, dokumentieren die Entscheidung und setzen eine Frist, um sie zu beheben.

Der Unterschied ist, dass technische Schulden oft unsichtbar sind, bis sie Probleme verursachen. Eine Sicherheitsausnahme ist von dem Moment an sichtbar, in dem sie erstellt wird. Die Pipeline protokolliert sie. Die Genehmigung zeichnet sie auf. Das Ablaufdatum macht es unmöglich, sie zu vergessen.

Eine praktische Checkliste

Wenn Sie einen Ausnahmen-Mechanismus für Ihre Pipeline einrichten, finden Sie hier eine kurze Checkliste für den Einstieg:

  • Wählen Sie einen Speicherort für Ausnahmen, der für Sicherheits-, Compliance- und Entwicklungsteams zugänglich ist
  • Definieren Sie, wer jede Art von Ausnahme genehmigen kann (Sicherheitsfunde, Compliance-Verstöße, Infrastrukturbeschränkungen)
  • Legen Sie Standard-Ablaufdauern für verschiedene Schweregrade fest
  • Lassen Sie die Pipeline automatisch Ablaufdaten prüfen und bei abgelaufenen Ausnahmen fehlschlagen
  • Testen Sie den Ablauf: Reichen Sie eine Ausnahme ein, genehmigen Sie sie, lassen Sie sie ablaufen und bestätigen Sie das Pipeline-Verhalten

Was als Nächstes kommt

Ein guter Ausnahmen-Mechanismus hält Ihre Pipeline streng, ohne sie starr zu machen. Teams können vorankommen, wenn sie auf einen echten Blocker stoßen, aber sie können das Gate nicht umgehen, ohne eine Spur zu hinterlassen. Die Pipeline bleibt als Leitplanke nützlich, nicht als Formalität.

Sobald dieser Mechanismus eingerichtet ist, besteht der nächste Schritt darin, alle Ihre Regeln als Code zu kodieren. Richtlinien, die in Dokumenten geschrieben oder in Meetings besprochen werden, sind schwer konsistent durchzusetzen. Regeln, die als Code geschrieben sind, können automatisch getestet, überprüft und ausgeführt werden. Das ist der Punkt, an dem Sicherheits- und Compliance-Gates wirklich zuverlässig werden.