Repository und Entwicklungsprozess absichern

Repository und Entwicklungsprozess absichern

0:00 Jetzt wird zum ersten Mal etwas gebaut. Wir beginnen dort, wo die Lieferkette anfängt: beim Repository. Es ist die einzige Station der ganzen Kette, an der ein Mensch schreibt — alles danach ist Automatik. Und genau deshalb lohnt sich der Aufwand hier besonders: Was Sie an dieser Stelle verhindern, muss keine spätere Station mehr auffangen.

0:20 Die gute Nachricht dabei ist, dass die wirksamsten Maßnahmen dieses Moduls keine Werkzeuge brauchen. Es sind Schutzregeln und Berechtigungen, und beides ist in einer Stunde eingerichtet.

Repository und Entwicklungsprozess absichern

0:32 Drei Themen liegen vor uns. Zuerst die Konten und ihre Rechte — inklusive der Konten, die niemandem gehören. Dann die Schutzregeln für Zweige, Tags und Reviews, also die technische Form des Vier-Augen-Prinzips. Und schließlich der Umgang mit Beiträgen von außen und mit dem Fall, den fast jedes Team einmal erlebt: ein Zugangsdatum ist im Repository gelandet.

0:53 Für alle drei gilt: Wir bauen sie gegen die Bedrohungen aus Modul zwei, nicht gegen eine allgemeine Checkliste.

Konten, Rollen und Berechtigungen

1:01 Fangen wir mit den Rechten an. Das Thema klingt nach Verwaltung, ist aber der Hebel mit der größten Wirkung — denn fast jeder Angriff auf die Quelle beginnt damit, dass jemand Rechte hat, die er nicht bräuchte. Zwei Quellen sagen hier dasselbe, was selten vorkommt und deshalb Beachtung verdient. Das NIST-Rahmenwerk verlangt, alle Formen von Code vor unbefugtem Zugriff und Manipulation zu schützen und Entwicklungsumgebungen zu trennen und zu härten.

1:26 Die OWASP Top Ten werden noch konkreter und zählen auf, wo Mehrfaktor-Authentifizierung und enge Rechtevergabe gelten sollen: Repository, Entwicklungsrechner, Build-Server, Artefakte und Infrastruktur-als-Code. Diese Aufzählung ist ungewöhnlich breit — und genau das ist ihr Punkt. Die üblichen Programme decken den ersten Ort ab und hören dort auf.

1:47 Fünf Schichten, und ich wette, dass in Ihrer Organisation die erste sauber geregelt ist. Beim zweiten wird es schon dünner: Entwicklungsrechner sind meist verwaltet, aber gehärtet sind sie selten — und das Rahmenwerk verlangt ausdrücklich Härtung. Bei der Build-Plattform kommt eine Feinheit hinzu, die uns in Modul sieben beschäftigt: Rechte gelten dort je Workflow, nicht je Team.

2:09 Beim vierten Punkt lohnt die Frage, wer eigentlich in die Artefaktablage schreiben darf. Und der fünfte ist der meistvergessene: Infrastruktur-als-Code ist Code und verdient denselben Schutz. Hier liegt ein Muster, das man einmal gesehen haben muss. Ein Automatisierungskonto bekommt eine Ausnahme vom Freigabezwang, weil es sonst nicht funktioniert.

2:29 Damit ist das Vier-Augen-Prinzip nicht geschwächt, sondern für jeden, der dieses Konto erreicht, vollständig aufgehoben. Die OWASP-Empfehlung dazu heißt Trennung der Zuständigkeiten und ist schön deutlich: Niemand darf allein Code bis in die Produktion befördern. Der dritte Punkt klingt banal und ist praktisch wichtig — persönliche Zugänge und Automatisierung zu trennen macht Protokolle erst auswertbar.

2:52 Und der vierte beschreibt den Normalzustand: Rechte werden vergeben und nie zurückgenommen. Eine Übung, die selten Spaß macht und immer etwas findet. Sie gehen die Konten mit Schreibrecht durch und notieren zu jedem, wofür es gebraucht wird. Fangen Sie bei den Automatisierungskonten an — sie haben in aller Regel die weitesten Rechte und die kürzeste Begründung, weil sie einmal eingerichtet und nie überprüft wurden.

3:17 Das Erfolgskriterium ist bewusst hart formuliert: Mindestens ein Recht muss am Ende begründet entzogen sein. Eine Bestandsaufnahme, die nichts ändert, ist eine Beschäftigung. Und erfahrungsgemäß findet sich dieses eine Recht in jedem Projekt. Der erste Punkt ist die Lücke, die fast alle haben: Mehrfaktor-Authentifizierung ist für Menschen verpflichtend, und daneben liegen unbefristet gültige Tokens.

3:40 Der zweite beschreibt, wie Rechte wachsen — ein Konto übernimmt mehrere Aufgaben, weil eine Aufteilung Arbeit gewesen wäre. Der dritte ist arithmetisch bemerkenswert: Rechte werden wöchentlich vergeben und jährlich geprüft. Damit ist die Prüfung strukturell immer hinterher. Und der vierte schließt an Modul eins an — Entwicklungsrechner gelten als Arbeitsmittel, nicht als Teil der Lieferkette.

4:03 Dabei steht dort der Editor mit seinen Erweiterungen, der Ihren Quellcode liest.

Branch-, Tag- und Review-Schutz

4:08 Jetzt zu den Schutzregeln. Sie sind nichts anderes als die technische Form des Vier-Augen-Prinzips — mit dem entscheidenden Vorteil, dass sie auch dann gelten, wenn es gerade eilig ist. Genau das ist ihr Zweck: Eine Vereinbarung, an die sich alle halten, solange nichts brennt, ist keine Kontrolle. Wir schauen uns an, welche Regeln es gibt, welche davon standardmäßig schon greifen und an welcher Stelle die meisten Repositories eine Lücke haben.

4:34 Rulesets fassen die Schutzregeln eines Repositories zusammen, und die Liste ist länger, als die meisten vermuten: Erstellung, Aktualisierung und Löschung einschränken, Force-Pushes blockieren, lineare Historie verlangen, signierte Commits fordern, Pull Requests erzwingen, Statusprüfungen verlangen. Zwei davon sind standardmäßig aktiv — Löschungen einschränken und Force-Pushes blockieren.

4:56 Das ist eine gute Nachricht, denn genau diese beiden adressieren die Bedrohung, die wir in Modul zwei besprochen haben: den Force-Push, der einen Commit im Verlauf unsichtbar macht. Diese vier Optionen entscheiden darüber, ob der Pull-Request-Zwang echt ist oder nur formal. Die ersten beiden kennt jeder: eine Mindestzahl an Genehmigungen, und Genehmigungen verfallen, wenn sich der Diff ändert. Interessanter sind die letzten beiden.

5:21 Die Zustimmung der Code-Eigentümer koppelt die Freigabe an die betroffenen Dateien — dazu gleich mehr. Und die vierte schließt eine Lücke, die man erst sieht, wenn sie ausgenutzt wurde: Wer zuletzt gepusht hat, darf nicht allein genehmigen. Ohne diese Option lässt sich nach der Freigabe noch nachschieben und dann selbst zustimmen.

5:40 Der Gedanke hinter dieser Datei ist einfach und wirkungsvoll: Nicht jede Änderung braucht dieselbe Aufmerksamkeit. Oben steht die Regel für alles Gewöhnliche — das Entwicklungsteam liest gegen. Darunter stehen die vier Dateien, an denen unsere Lieferkette hängt: die Build-Datei, das Dockerfile, die Workflow-Dateien und die Deployment-Policy.

6:00 Wer eine davon ändert, ändert nicht das Verhalten der Anwendung, sondern die Regeln, unter denen sie entsteht und startet. Deshalb ein zweites Augenpaar aus dem Plattform- oder Security-Team. Wichtig ist die Fußzeile: Die Datei allein bewirkt nichts — sie braucht die Option, die die Zustimmung der Eigentümer verlangt. Ein Review beantwortet die Frage: Ist diese Änderung in Ordnung? Eine Signatur beantwortet: Stammt sie wirklich von dieser Person?

6:27 Das sind zwei verschiedene Fragen, und deshalb ersetzt keine die andere. Die Regel für signierte Commits erzwingt, dass Beiträge signiert und verifiziert sind — mit einer Nebenwirkung, die überrascht: Ein unsignierter Commit blockiert auch den Squash-Merge, selbst wenn das Ergebnis signiert wäre. Der dritte Punkt ist der, den ich Ihnen besonders ans Herz lege: Tags brauchen eigenen Schutz.

6:49 Und der vierte ist eine Falle — Bypass-Berechtigungen wirken im gesamten Fork-Netzwerk, nicht nur bei Ihnen. Der erste Punkt ist der häufigste Fund überhaupt: Hauptzweig geschützt, Tags ungeschützt. Damit bleibt der Release-Stand beweglich, und alles, was wir später über Signaturen und Provenance lernen, hängt an einem Zeiger, den jemand umhängen kann.

7:10 Der zweite Punkt: Bypass-Rechte werden für den Notfall vergeben und danach nie entzogen — schauen Sie ruhig gleich nach, wer sie in Ihrem Repository hat. Der dritte betrifft die verfallenden Genehmigungen, die oft abgeschaltet sind, weil sie nerven. Und der vierte ist tückisch: Statusprüfungen laufen auf einem anderen Stand als dem, der am Ende gemergt wird.

Beiträge von außen und versehentliche Geheimnisse

7:32 Im dritten Kapitel geht es um zwei Fälle, die nichts miteinander zu tun zu haben scheinen und doch dieselbe Wurzel haben: Etwas überquert die Vertrauensgrenze in die falsche Richtung. Einmal kommt fremder Code herein, einmal geht ein Geheimnis hinaus. Der Punkt ist heikel, deshalb langsam. Privilegierte Abläufe — also solche, die mit Schreibrechten und Zugang zu Geheimnissen laufen — teilen sich den Cache des Hauptzweigs.

7:56 Wenn ein solcher Ablauf den Code eines fremden Pull Requests auscheckt und ausführt, läuft fremder Code in einem Kontext, in dem er das Repository übernehmen kann. Deshalb die klare Regel: In einem privilegierten Ablauf wird ungeprüfter Pull-Request-Code niemals ausgecheckt. Das ist eine der wenigen Stellen in diesem Seminar, an denen ich von einer Regel ohne Ausnahme sprechen würde.

8:18 Die Auflösung des Problems liegt in dieser Gegenüberstellung: zwei getrennte Wege statt eines Kompromisses. Der linke Weg prüft — er checkt fremden Code aus, läuft aber ohne Geheimnisse und ohne Schreibrechte und liefert am Ende einen Prüfbericht. Der rechte Weg baut — er hat Geheimnisse und Rechte, checkt aber nur eigenen, bereits freigegebenen Code aus. Zwischen beiden steht ein Mensch, der freigibt.

8:41 Diese Trennung ist der eigentliche Trick, und sie kostet nur eine zusätzliche Workflow-Datei. Diesen Ablauf sollten Sie vorher aufgeschrieben haben, denn im Ernstfall ist der erste Reflex der falsche. Der Reflex lautet: Datei ändern, committen, erleichtert sein. Richtig ist Schritt eins: Das Geheimnis sofort für ungültig erklären und ersetzen. Denn — und das ist die Fußzeile — aus der Historie verschwindet es nicht.

9:07 Es bleibt lesbar und bleibt gültig, bis es rotiert wurde. Danach kommen die unangenehmen Schritte: alle Stellen nachziehen, an denen es hinterlegt war. Protokolle und Läufe löschen. Und nachvollziehen, seit wann es lesbar war und wer Zugriff hatte. Der erste Punkt ist genau der eben beschriebene Reflex, und er ist die häufigste Fehlreaktion überhaupt.

9:29 Der zweite kommt aus den Empfehlungen zum Umgang mit Geheimnissen: Strukturierte Werte wie ein ganzes Konfigurationsdokument gehören nicht als ein einziges Geheimnis hinterlegt, sondern je sensiblem Wert einzeln — sonst greift die Maskierung nur teilweise. Der dritte ist verwandt: Umgewandelte Werte, etwa base64-kodiert, müssen ebenfalls als Geheimnis registriert werden, sonst stehen sie ungeschwärzt im Protokoll.

9:53 Und der vierte schließt an Modul zwei an: Artefakte aus fremden Läufen sind fremder Code.

Übung

9:59 In der Übung härten Sie das Repository der Deichwacht — und spielen einmal durch, was passiert, wenn trotzdem etwas schiefgeht. Beides gehört zusammen: Regeln setzen und den Fall proben, in dem sie nicht gereicht haben. Zwei Teile, und der Hinweis auf der Folie ist mir der wichtigste des ganzen Moduls: Notieren Sie zu jeder gesetzten Regel, welche Bedrohung aus Modul zwei sie adressiert.

10:22 Regeln ohne Bedrohung streichen Sie wieder. Das klingt streng, schützt aber vor dem Zustand, in dem ein Repository fünfzehn Regeln trägt, die niemand mehr begründen kann — und die deshalb bei der nächsten Reibung pauschal gelockert werden. Der zweite Teil, der Leak-Ablauf, braucht keine Technik. Er braucht eine nummerierte Liste mit Namen dahinter.

10:42 Die fünf Schritte sind in etwa einer Stunde erledigt und decken die wirksamsten Maßnahmen ab. Schutzregeln für den Hauptzweig mit Freigabe und Statusprüfungen. Eigene Regeln für die Release-Tags — der Schritt, der am häufigsten fehlt. Die CODEOWNERS-Datei für die vier Lieferketten-Dateien. Dann die Durchsicht der Bypass-Berechtigungen.

11:01 Und schließlich der aufgeschriebene Leak-Ablauf mit benannten Personen. Die Fußzeile nennt die Probe aufs Exempel: Ein Pull Request auf die Workflow-Datei muss ohne Zustimmung des Plattformteams stehen bleiben. Probieren Sie das wirklich aus. Der erste Punkt ist genau das, was ich gerade gesagt habe — Regeln werden gesetzt, aber niemand versucht ein einziges Mal, sie zu umgehen.

11:24 Dabei dauert der Test zwei Minuten und ist der einzige Beleg, dass die Konfiguration wirkt. Der zweite ist ein Klassiker: CODEOWNERS verweist auf ein Team, dessen Mitglieder gar keine Benachrichtigung bekommen — die Regel greift, nur merkt es niemand. Der dritte betrifft den Leak-Ablauf, der beim Rotieren endet und die Ursachenfrage offenlässt.

11:44 Und der vierte ist die Tag-Lücke, diesmal mit Begründung: Releases erzeugt ja ohnehin nur die Pipeline. Bis jemand von Hand nachhilft.