Security Scanning in der Pipeline

Security Scanning in der Pipeline

0:00 Willkommen zum zweiten Tag. Gestern ging es um die Frage, was überhaupt in unsere Lieferkette hineinkommt. Heute geht es um die Pipeline selbst — und wir beginnen mit dem Thema, das die meisten Teams als erstes angehen: automatische Prüfungen. Ich möchte gleich zu Beginn eine Warnung aussprechen, die dieses ganze Modul trägt. Ein Scanner ist schnell eingerichtet.

0:21 Ein Scanner, dessen Befunde niemand abarbeitet, ist aber keine Sicherheitsmaßnahme, sondern eine Maschine zur Erzeugung von Ausreden. Die Arbeit liegt nicht im Einbauen — sie liegt danach.

Security Scanning in der Pipeline

0:33 Der zweite Tag dreht sich um die Härtung der Pipeline, um Stücklisten und um die Integrität von Artefakten. Wir starten mit den Prüfverfahren, und zwar in drei Schritten: Welche Verfahren gibt es und was sieht jedes davon — und was eben nicht. An welcher Stelle im Ablauf gehören sie hin, damit ihr Ergebnis noch etwas ändert.

0:51 Und schließlich die Frage, die über Erfolg und Misserfolg entscheidet: Was passiert eigentlich mit den Befunden?

Verfahren und ihre Reichweite

0:58 Fangen wir mit einer Landkarte der Verfahren an. Die Abkürzungen sind schnell aufgezählt, aber selten macht sich jemand klar, dass jedes Verfahren an einer anderen Stelle hinsieht — und dass die Summe aller Verfahren immer noch Lücken lässt. Genau diese Lücken sollten Sie kennen, bevor Sie das erste Werkzeug einrichten. OWASP SAMM ordnet Sicherheitstests der Funktion Verification zu und teilt sie in zwei Stränge — und diese Zweiteilung finde ich außerordentlich hilfreich.

1:25 Auf der einen Seite die skalierbare Grundlage: automatisierte Prüfungen, die überall und immer laufen. Auf der anderen das tiefe Verständnis: manuelle, risikobasierte Tests. Die Begründung für diese Aufteilung ist pragmatisch. Die Automatisierung räumt das leicht Erreichbare ab und macht damit Fachleute für die schwierigen Angriffswege frei.

1:45 Es geht also nicht darum, ob automatisch oder manuell — sondern darum, dass das eine das andere erst ermöglicht. Lesen Sie diese Tabelle einmal von rechts nach links. Die statische Analyse sieht Muster im eigenen Quellcode — und nichts von der Laufzeit oder der Konfiguration. Die Abhängigkeitsprüfung sieht bekannte Lücken in fremden Bibliotheken — und nichts Unbekanntes und nichts Eigenes.

2:09 Das Secret Scanning sieht Zugangsdaten im Repository und in der Historie — aber keine Geheimnisse, die anderswo liegen. Und der Container-Scan sieht Pakete im Image, nicht die Logik darin. Die Fußzeile ergänzt die dynamische Prüfung: Sie braucht eine laufende Anwendung und steht deshalb selten im Pull Request. Die Gegenüberstellung macht deutlich, warum beide Stränge nötig sind. Links das Automatisierbare: läuft bei jeder Änderung, findet bekannte Muster, skaliert über alle Projekte.

2:38 Rechts das Manuelle: läuft für Risikoteile, findet Geschäftslogikfehler, skaliert nicht. Genau deshalb steht in der letzten Zeile „wiegt schwerer". Ein Fehler in der Geschäftslogik — etwa dass jemand eine Warnstufe für einen fremden Deichabschnitt setzen kann — wird von keinem Werkzeug gefunden. Es gibt kein Muster dafür, weil der Code völlig korrekt aussieht. Nur ein Mensch, der die Fachlichkeit kennt, sieht das.

3:04 Wenn Sie morgen anfangen: Fangen Sie mit dem Secret Scanning an. Es liefert die eindeutigsten Befunde — ein Zugangsschlüssel ist ein Zugangsschlüssel, da gibt es wenig zu diskutieren — und die klarste Handlungsanweisung, die wir gestern besprochen haben. Zweitens die Abhängigkeitsprüfung, weil sie den mengenmäßig größten Teil Ihres ausgelieferten Codes abdeckt.

3:24 Die statische Analyse würde ich bewusst später ansetzen: Sie braucht die meiste Nacharbeit, bis ihre Regeln zu Ihrem Projekt passen. Und der Container-Scan zeigt die Betriebssystempakete — den Bereich, für den sich sonst niemand zuständig fühlt. Der erste Punkt ist der Enthusiasmusfehler: fünf Werkzeuge gleichzeitig, keine Auswertung. Nach vier Wochen schaltet man sie leise wieder ab.

3:47 Der zweite ist ein Zuschnittproblem — zwei Werkzeuge decken dasselbe ab, während eine ganze Kategorie fehlt; die Tabelle von vorhin hilft, das zu erkennen. Der dritte ist ein handfester Fehler, der öfter vorkommt, als man denkt: Der Container-Scan läuft auf dem Basis-Image statt auf dem gebauten Image, und damit sieht er Ihre Anwendung gar nicht.

4:07 Und der vierte ist die stille Annahme, die Automatisierung sei vollständig — dann entfällt die manuelle Prüfung ganz.

Scans im Ablauf verankern

4:15 Jetzt zur Frage des Zeitpunkts. Sie klingt technisch, ist aber vor allem eine Frage der Wirksamkeit: Ein Befund ist so viel wert wie die Chance, ihn noch zu ändern. Derselbe Befund kostet im Pull Request eine Korrektur und nach dem Release einen Prozess mit Meldung, Kundenkommunikation und Hotfix. SAMM beschreibt für den automatisierten Strang drei Reifestufen, und die dritte ist unser Ziel: die Einbettung der Sicherheitstests in den Build- und Deployment-Prozess.

4:42 Nicht als gelegentlicher Lauf, nicht als wöchentlicher Report, sondern als Teil des Ablaufs. Der Grund steht in der Definition: Es geht um den Zeitpunkt. Und hier gibt es eine Spannung, die jedes Team aushandeln muss — früh ist wirksam, aber früh ist auch langsam. Wenn der Pull Request zwanzig Minuten auf Prüfungen wartet, sucht sich das Team Wege daran vorbei.

5:04 Vier Stationen, und die Zuordnung ist eine Abwägung zwischen Rückmeldedauer und Wirksamkeit. In den Pull Request gehören die schnellen Prüfungen mit eindeutigen Befunden — Secrets und Abhängigkeiten. In den Build gehört alles, was das gebaute Artefakt betrifft, also der Container-Scan. Ins Release gehören die Prüfungen, die das fertige Paket betreffen.

5:24 Und im Betrieb läuft die fortlaufende Beobachtung, denn eine Schwachstelle kann auch drei Monate nach dem Release bekannt werden — dazu kommen wir in Modul elf ausführlich. Dieser Ablauf ist der wichtigste praktische Rat dieses Moduls, und er entscheidet darüber, ob Ihre Einführung überlebt. Die Fußzeile sagt, warum: Ohne Baseline steht die Pipeline am ersten Tag rot — und wird am zweiten Tag abgeschaltet.

5:49 Also: Alle Werkzeuge einmal ohne Abbruch laufen lassen und den Bestand erfassen. Diesen Bestand einfrieren und datieren. Ab da brechen nur neue Befunde den Build ab — das ist der entscheidende Kniff, denn er hält die Qualität ab sofort konstant. Und dann den eingefrorenen Bestand portionsweise mit Frist abarbeiten. Ein unscheinbares Thema mit großer Wirkung. Wenn fünf Werkzeuge fünf verschiedene Ausgabeformate produzieren, entstehen fünf Protokolle, die niemand öffnet.

6:18 Ein einheitliches Ergebnisformat erlaubt es, die Befunde zusammenzuführen — und das ist mehr als Bequemlichkeit. Erst in der gemeinsamen Liste sehen Sie Doppelbefunde, also Stellen, die zwei Werkzeuge melden. Und Sie sehen Lücken, also Bereiche, über die keines etwas sagt. Der letzte Punkt ist der organisatorische: Was zentral sichtbar ist, lässt sich zuordnen und nachverfolgen. Was im Lauf verschwindet, nicht.

6:44 Der erste Punkt ist die klassische Kapitulation vor der Laufzeit: Der Scan läuft nach dem Merge, weil er im Pull Request zu lange dauert. Damit ist er nicht falsch, aber deutlich weniger wert. Der zweite ist die Gegenrichtung — alles läuft bei jeder Änderung, die Rückmeldung dauert eine halbe Stunde, und das Team arbeitet daran vorbei.

7:03 Der dritte ist ein Ablagethema mit Folgen: Ergebnisse landen im Protokoll des Laufs und werden nach dreißig Tagen gelöscht; für einen Nachweis in Modul sechzehn fehlen sie dann. Und der vierte ist ein echter Fehler: Der Release-Scan prüft ein anderes Artefakt als das ausgelieferte.

Findings bewerten und steuern

7:19 Kommen wir zum Teil, an dem die meisten Programme scheitern. Nicht am Einbau der Werkzeuge — der ist in einem Tag erledigt. Sondern an der Frage, was mit den Befunden geschieht, und vor allem: wer entscheidet, dass ein Befund den Ablauf anhält. Ein Quality Gate legt fest, welcher Befund den Ablauf anhält. Damit es tragfähig ist, braucht es eine Antwort auf drei Fälle — und der dritte wird fast immer vergessen.

7:45 Fall eins: ein echter Befund, der behoben wird. Fall zwei: ein Fehlalarm. Und Fall drei: ein Risiko, das man bewusst akzeptiert, weil die Behebung gerade nicht möglich oder nicht verhältnismäßig ist. Fehlt dieser dritte Fall, gibt es keinen legalen Weg am Gate vorbei — und dann wird beim ersten Termindruck das Gate selbst abgeschaltet.

8:06 Nicht der Befund gewinnt, sondern die Regel verliert. Drei Zeilen, und die rechte Spalte ist die eigentliche Arbeit. Beim echten Befund wird die Änderung samt Prüfung dokumentiert — das passiert ohnehin. Beim Fehlalarm ist wichtig, dass die Begründung am Werkzeug landet und die Regel angepasst wird, nicht der Einzelfall unterdrückt.

8:26 Und bei der Ausnahme braucht es drei Angaben: Frist, Grund, Verantwortliche. Die Fußzeile ist mir die wichtigste Zeile dieses Moduls: Eine Ausnahme ohne Frist ist keine Ausnahme, sondern eine stillschweigende Änderung der Regel. Das gilt übrigens für jede Ausnahme in diesem Seminar — wir kommen in Modul sechzehn darauf zurück.

8:46 Der erste Satz ist eine schlichte Beobachtung aus vielen Projekten: Ein Befund ohne benannte Verantwortliche bleibt liegen, ganz gleich wie hoch der Wert ist. Die Punktzahl motiviert niemanden — ein Name schon. Der zweite Punkt greift vor auf Modul elf: Die Priorität ergibt sich aus Erreichbarkeit und Auswirkung, nicht aus der Werkzeugmeldung.

9:05 Der dritte macht die Lage verhandelbar: Kennzahlen über Rückstand und Abarbeitungsdauer erlauben ein Gespräch mit der Leitung, das nicht auf Gefühlen beruht. Und der vierte ist Pflege — wer Ausnahmen erlaubt, braucht eine Stelle, die sie regelmäßig durchsieht. Der erste Punkt ist die häufigste Fehlkonfiguration: Jeder Befund oberhalb eines Schwellenwerts bricht den Build, auch der nachweislich unerreichbare.

9:29 Das erzeugt Frust und untergräbt die Glaubwürdigkeit des Gates. Der zweite ist eine Unsitte mit Langzeitfolgen — Fehlalarme werden einzeln unterdrückt, statt die Regel zu korrigieren; nach einem Jahr weiß niemand mehr, warum an dreißig Stellen Unterdrückungen stehen. Der dritte ist ein Sichtbarkeitsproblem: Ausnahmen werden im Werkzeug gesetzt und tauchen in keiner Übersicht auf.

9:51 Und der vierte ist folgenlose Messung — der Rückstand wird gemessen, aber nie mit einer Frist verbunden.

Übung

9:57 In der Übung bauen Sie vier Prüfungen in die Pipeline der Deichwacht ein. Der interessantere Teil kommt danach: Sie müssen für jede begründen, warum sie an genau dieser Stelle sitzt — und für das Gate einen Weg vorsehen, der ein akzeptiertes Risiko nicht zum Regelbruch macht. Vier Scans an begründeten Punkten, eine datierte Baseline, und je Scan die Entscheidung: abbrechen oder berichten.

10:19 Der Hinweis auf der Folie ist die eigentliche Prüfung dieser Aufgabe — das Gate muss den Fall des akzeptierten Risikos mit Frist und Verantwortlicher abbilden. Wenn Ihr Gate nur zwei Zustände kennt, grün und rot, wird es die erste heiße Phase nicht überleben. Denken Sie an die Baseline: Sie ist kein Zugeständnis an die Bequemlichkeit, sondern die Bedingung dafür, dass ab heute keine neuen Befunde hinzukommen.

10:43 Die Reihenfolge der Schritte entspricht der Empfehlung von vorhin. Secret Scanning zuerst — und zwar auf die gesamte Historie, nicht nur auf neue Commits; was einmal drin war, ist weiterhin lesbar. Dann Abhängigkeitsprüfung und statische Analyse in den Pull Request. Der Container-Scan auf das gebaute Image, nicht auf das Basis-Image. Dann die datierte Baseline.

11:05 Und schließlich die Festlegung je Scan. Die Fußzeile enthält einen Rat, der weit über dieses Modul hinausreicht: Diese Festlegung gehört ins Repository, nicht in eine Werkzeugoberfläche — sonst ändert sie sich unbemerkt. Der erste Punkt ist das häufigste Schicksal einer Baseline: angelegt, nie abgearbeitet, vor sich hin alternd.

11:26 Setzen Sie deshalb schon beim Anlegen fest, in welchen Portionen sie schrumpft. Der zweite ist das Übermaß — alle vier Scans brechen ab, und die erste dringende Änderung geht an der Pipeline vorbei. Ab dann gibt es einen zweiten, ungeprüften Weg, und den bekommt man schwer wieder zu. Der dritte ist der Reihenfolgefehler beim Container-Scan.

11:46 Und der vierte ist die Zuständigkeitslücke zwischen zwei Teams — sie kostet mehr Befunde als jede Fehlkonfiguration.