Die Frage Monorepo oder Polyrepo wird meist als Organisations- und Tooling-Frage diskutiert. Aus Sicherheitssicht ist sie mindestens genauso relevant. Wer alle Projekte in einem Repository hält, trifft andere Risikoentscheidungen als jemand, der hundert kleine Repositories betreibt. Beide Modelle haben blinde Flecken, und die meisten Teams kennen ihre eigenen nicht.
Zugriffsrechte: alles oder nichts vs. Wildwuchs
Im Monorepo ist Zugriff eine binäre Entscheidung. Wer das Repository klonen darf, sieht in der Regel alles: jeden Service, jede Konfiguration, jede Historie. Feingranulare Leserechte auf Verzeichnisebene bieten GitHub und GitLab nur eingeschränkt. Ein kompromittierter Entwickler-Account oder ein geleakter Token öffnet damit die gesamte Codebasis auf einmal.
Im Polyrepo lässt sich Zugriff pro Repository steuern. Das klingt besser, kippt in der Praxis aber oft ins Gegenteil. Nach zwei Jahren weiß niemand mehr, wer warum auf welche der 80 Repositories Schreibrechte hat. Verwaiste Berechtigungen von Ex-Mitarbeitern und Dienstleistern sind in Polyrepo-Landschaften der Normalfall, nicht die Ausnahme.
Secrets und Blast Radius
Ein Secret, das im Monorepo landet, liegt für alle sichtbar in der gemeinsamen Historie. Der Schaden eines einzelnen Fehlers ist maximal. Dafür gibt es nur eine Historie, die man scannen muss, und ein zentraler Secret-Scanner deckt das gesamte Unternehmen ab.
Im Polyrepo ist der Blast Radius pro Vorfall kleiner, aber die Angriffsfläche größer. Jedes Repository braucht eigene Scanner-Konfiguration, eigene Push-Protection, eigene Pipeline-Secrets. In der Praxis sind zwei Drittel der Repositories sauber konfiguriert und der Rest läuft ohne jede Kontrolle. Angreifer suchen genau diese vergessenen Repositories.
CI/CD: eine gehärtete Pipeline oder viele halbfertige
Das Monorepo zwingt zu einer zentralen Pipeline. Das ist Aufwand, aber dieser Aufwand wird einmal geleistet und wirkt überall: gepinnte Actions, minimale Token-Rechte, Artefakt-Signierung, Freigabeprozesse. Eine Kontrolle, ein Ort, ein Review.
Im Polyrepo kopiert jedes Team seine Workflows selbst zusammen. Ohne zentrale Templates entstehen Dutzende Varianten derselben Pipeline, jede mit eigenen Abkürzungen. Wer dann eine Sicherheitsanforderung ausrollen will, etwa OIDC statt gespeicherter Cloud-Credentials, fasst 80 Repositories einzeln an. Viele Organisationen schieben genau das jahrelang vor sich her.
Abhängigkeiten und Überblick
Für Software Composition Analysis und SBOMs ist das Monorepo dankbar: ein Scan, ein Bericht, ein vollständiges Bild der Abhängigkeiten. Im Polyrepo entsteht das Gesamtbild nur, wenn jemand die Ergebnisse aller Repositories zusammenführt. Ohne diese Aggregation beantwortet niemand die Frage, ob eine kritische Bibliothek wie damals Log4j irgendwo im Unternehmen läuft. Genau diese Frage stellen Kunden und Prüfer aber zuerst.
Was in der Praxis zählt
Die Repository-Struktur ist selten frei wählbar, sie ist historisch gewachsen. Entscheidend ist nicht das Modell, sondern ob die Kontrollen zum Modell passen. Ein Monorepo braucht strenge interne Grenzen: Codeowners, Pfad-basierte Reviews, getrennte Pipeline-Rechte pro Bereich. Ein Polyrepo braucht Zentralisierung an den richtigen Stellen: Organisations-weite Templates, zentrale Scanner, regelmäßige Berechtigungs-Reviews und ein Inventar, das vergessene Repositories sichtbar macht.
Wer wechselt, sollte den Wechsel als Sicherheitsprojekt behandeln. Bei der Migration wandern Historien, Secrets und Berechtigungen mit. Das ist der Moment, in dem alte Leichen entweder bereinigt oder für weitere zehn Jahre einzementiert werden.
Wissen, wo Ihre Repository-Landschaft steht
Der GitSecOps QuickCheck prüft Ihre Repositories, Pipelines und Berechtigungen und liefert in 3 Werktagen einen priorisierten Maßnahmenkatalog. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone
Dein Blog zum Thema digitales Business 
Hinterlasse einen Kommentar