Wann sollte ein Sicherheitsbefund den Build brechen, und wie gehst du mit False Positives um?
Kurzantwort
Brich den Build nur bei hochgradig zuverlässigen, schwerwiegenden, neu eingeführten Befunden; warne (blockiere nicht) bei allem anderen, damit Entwickler dem Gate weiter vertrauen. Manage False Positives mit getunten Regeln, Baselining bereits bestehender Probleme und dokumentierten, befristeten, geprüften Unterdrückungen statt Scanner zu deaktivieren. Ein Gate, das ständig fälschlich Alarm schlägt, wird ignoriert oder umgangen — Signalqualität ist also das Ganze.
Ein Sicherheits-Gate ist nur dann wertvoll, wenn Entwickler es respektieren. Der schwierige Teil von DevSecOps ist nicht, Scanner laufen zu lassen — es ist die Entscheidung, was ein Release tatsächlich stoppen sollte.
Was den Build brechen sollte
Reserviere ein hartes Fail für Befunde, die gleichzeitig:
- Schwerwiegend sind — ausnutzbar, mit echtem Impact.
- Hochzuverlässig sind — niedrige False-Positive-Rate für diese Regel.
- Neu eingeführt sind — durch diese Änderung hinzugekommen, nicht geerbt.
Alles andere sollte warnen statt zu blockieren: im PR sichtbar gemacht, nachverfolgt, aber die Pipeline nicht stoppend. So bleibt das "Stop"-Signal des Gates selten und bedeutungsvoll.
Das False-Positive-Problem
Das ist der Kern. Ein Scanner, der Builds bei Rauschen blockiert, erzieht Entwickler dazu, ihm zu misstrauen — sie winken Unterdrückungen durch, fordern seine Abschaltung oder umgehen ihn. Signalqualität entscheidet, ob Sicherheitswerkzeuge den Kontakt mit einem echten Team überleben. Du managst Rauschen, indem du:
- Regeln tunst auf Codebasis und Sprache.
- Baselining bereits bestehender Probleme machst, wenn du Scanning in ein Legacy-Repo einführst, sodass Tag eins keine Wand aus Rot für Code ist, den niemand angefasst hat — und dann neue verhinderst und das Backlog gezielt abarbeitest.
- Auditierbare Unterdrückungen nutzt — wenn ein Befund wirklich ein False Positive oder ein akzeptiertes Risiko ist, erfasse eine dokumentierte, geprüfte, befristete Ausnahme (mit Autor und Begründung), statt die Prüfung zu deaktivieren. Stilles
// nosecüberall ist der Versagensmodus.
Die Feedback-Schleife
Befunde sollten dort landen, wo Entwickler ohnehin arbeiten — im Pull Request — mit klarer Behebungsanleitung. Schnelles, präzises, kontextbezogenes Feedback ist es, was Shift-Left wirklich nachhaltig macht.
Worauf Interviewer achten
Sie wollen die Schwelle aus Schweregrad plus Zuverlässigkeit plus Neuheit, eine ehrliche Auseinandersetzung mit False-Positive-Ermüdung und Unterdrückungen, die auditierbar bleiben, statt zum stillen Ausschalter zu werden.
Wahrscheinliche Anschlussfragen
- Warum ist Baselining wichtig, wenn man Scanning zu einer Legacy-Codebasis hinzufügt?
- Was passiert mit der Wirksamkeit eines Gates, wenn es zu viele False Positives hat?
- Wie machst du eine Unterdrückung auditierbar statt zu einer stillen Umgehung?