Scan bei jedem Commit: Was zwischen Push und erledigter Behebung passiert
Drei Prüftiefen, ein Mensch dazwischen und eine Behebung, die nicht im Ticket endet: Wie ein Code-Scan bei jedem Commit vom Sofort-Scan über die Kontext-Prüfung bis zur Tiefenprüfung arbeitet, wie Falschmeldungen aussortiert werden und warum Rotation und Update die eigentliche Maßnahme sind.
Was bei jedem Commit wirklich passiert
Der Satz klingt nach einem Werkzeug, das bei jedem Push die komplette Anwendung durchleuchtet. So arbeitet kein Scanner, und so sollte auch keiner arbeiten, weil ein Vollscan pro Commit Minuten dauert und Entwickler abwürgt. Was tatsächlich passiert, ist eine Staffelung. Die Änderung selbst wird sofort geprüft. Ihre Wirkung auf den Rest des Codes wird im Zusammenhang bewertet. Und die Codebasis als Ganzes wird in eigenem Takt durchsucht, damit auch das gefunden wird, was nicht in diesem Commit entstanden ist.
Diese Staffelung ist der Unterschied zwischen einem Scanner, der Entwickler behindert, und einem, den sie nach einer Woche nicht mehr bemerken. Unsere Seite zur Code-Sicherheit nennt die drei Ebenen; hier folgt, was in jeder davon geschieht.
Tiefe eins: der Sofort-Scan
Der Push kommt an, und innerhalb von Sekunden werden die geänderten Zeilen auf drei Dinge geprüft: hartkodierte Passwörter, Schlüssel und Tokens; bekannte unsichere Funktionen und Muster; gefährliche Aufrufe wie ungeprüfte Systembefehle. Das Ergebnis liegt vor, bevor der Code weiterläuft. Wer ein Secret eincheckt, erfährt es, solange er den Editor noch offen hat, nicht beim nächsten Prüftermin.
Der Sofort-Scan ist bewusst eng. Er kennt Muster, keine Absichten. Was er meldet, ist noch kein Befund, sondern ein Kandidat.
Tiefe zwei: die Prüfung im Zusammenhang
Jetzt wird die Änderung nicht mehr isoliert betrachtet, sondern im Kontext der Codebasis. Führt der neue Aufruf tatsächlich zu einer Stelle, an der Eingaben ungeprüft ankommen? Ist die fehlende Zugriffskontrolle an einer Stelle, die von außen erreichbar ist, oder in einem internen Hilfsmodul? Hier entscheidet sich, ob ein Kandidat ein echtes Risiko ist. Die Bewertung folgt dem realen Risiko, nicht der Menge der Treffer.
In dieser Stufe passiert das, was Scanner allein nicht können: Ein Mensch sieht jeden Kandidaten, bevor er zum Fund wird, und sortiert aus, was im konkreten Fall nicht ausnutzbar ist. Das Ergebnis ist eine klare Priorität statt einer endlosen Trefferliste. Wer schon einmal 400 Warnungen bekommen hat, von denen 380 nichts bedeuteten, weiß, warum dieser Schritt der wichtigste ist.
Tiefe drei: die Tiefenprüfung
Die dritte Ebene arbeitet nicht pro Commit, sondern über die ganze Codebasis, weil vieles, was gefährlich ist, nicht im aktuellen Commit entstanden ist. Alle Abhängigkeiten werden gegen bekannte Schwachstellen abgeglichen. Der Verlauf des Repositories wird auf alte Secrets durchsucht, denn ein Schlüssel, der vor zwei Jahren eingecheckt und dann gelöscht wurde, liegt noch immer in der Historie. Und die Konfiguration wird auf unsichere Voreinstellungen geprüft.
Aus dieser Ebene stammen die Funde, die im ersten Befund nach 48 Stunden am häufigsten oben stehen: nicht der Fehler von gestern, sondern die Bibliothek von vor achtzehn Monaten.
Warum die Behebung die Maßnahme ist, nicht der Alarm
Ein Bericht voller Funde, den niemand abarbeitet, ist kein Schutz. Deshalb endet der Ablauf nicht mit einer Meldung. Für einen kritischen Fund heißt Behebung: Das Secret wird rotiert, nicht nur aus dem Code entfernt, denn ein einmal veröffentlichter Schlüssel bleibt gültig, bis er ungültig gemacht wird. Die verwundbare Bibliothek wird aktualisiert. Das gefährliche Muster wird entschärft. Und jede dieser Maßnahmen wird mit Fund und Datum dokumentiert.
Dass ein rotiertes Secret die einzige echte Behebung ist, haben wir im Beitrag über hartkodierte Secrets ausführlich beschrieben. Für Abhängigkeiten gilt dasselbe Prinzip: Solange die alte Version läuft, ist der Fund nicht erledigt, egal wie oft er gemeldet wurde.
Der Weg dorthin
Am Tag 0 werden die Repositories angebunden und der Bestand erstmalig gescannt. Nach 48 Stunden liegt der erste Befund vor, sortiert nach dem, was echt und kritisch ist. In der ersten Woche wird aufgeräumt. Danach greifen die drei Tiefen bei jedem Commit. Der Einstieg ist die kostenlose Code-Analyse, ohne Verpflichtung und auf Wunsch in der eigenen Umgebung.
Häufig gestellte Fragen
Bremst der Scan die Entwickler aus?
Der Sofort-Scan liefert sein Ergebnis in Sekunden und prüft nur die Änderung. Die aufwendigeren Prüfungen laufen im Zusammenhang und über die Codebasis, ohne den Push aufzuhalten. Genau deshalb sind die drei Ebenen getrennt.
Wer entscheidet, ob ein Fund echt ist?
Ein Mensch, in der zweiten Tiefe. Der Scanner liefert Kandidaten, die Bewertung im Kontext der Codebasis und die Einordnung nach echtem Risiko passieren, bevor ein Fund Dich erreicht. Falschmeldungen werden dort aussortiert.
Was, wenn ein kritischer Fund nachts kommt?
Kritische Funde bearbeiten wir sofort und melden Dir, was schon erledigt ist, in Deinen Kanälen. Die Reaktion bei kritischen Funden liegt unter 15 Minuten, wie auf unserer Seite zur Code-Sicherheit beschrieben.