Dein Blog zum Thema digitales Business

Jede Pipeline endet an derselben Stelle: einem Artefakt, das irgendwo abgelegt wird. Container-Images, npm-Pakete, JAR-Dateien, Helm-Charts. Der Ort, an dem sie liegen, heißt Artifact Registry. In vielen Teams ist genau dieser Ort der am schlechtesten kontrollierte Teil der gesamten Lieferkette. Wer in die Registry schreiben kann, entscheidet, was in Produktion läuft. Wer daraus liest, vertraut blind auf das, was er bekommt.

Warum die Registry ein lohnendes Ziel ist

Ein Angreifer muss nicht euren Quellcode manipulieren, wenn er das fertige Image austauschen kann. Die Registry sitzt hinter dem Build und vor dem Deploy. Ein kompromittiertes Image mit demselben Tag landet über die normale Pipeline in Produktion, ohne dass ein Commit oder ein Pull Request auffällt. Bei öffentlichen Registries kommt das Risiko von außen: getippte Paketnamen, verwaiste Namespaces, Images mit veralteten Basisschichten voller bekannter Lücken.

Zugriff: wer darf pushen, wer darf pullen

Der erste Hebel ist trivial und wird trotzdem selten sauber gezogen. Push-Rechte gehören nur an die Pipeline, nicht an einzelne Entwickler und schon gar nicht an geteilte Konten. Menschen brauchen in der Regel nur Lese-Zugriff. Wenn ein Deploy-Key oder ein Registry-Token push darf, sollte er kurzlebig sein und über OIDC statt als statisches Secret ausgestellt werden. Prüft regelmäßig, welche Identitäten überhaupt noch Schreibrechte haben. Die Liste ist fast immer länger als gedacht.

Signieren und verifizieren

Ein Image ohne Signatur ist nur ein Name mit einem Tag. Beides lässt sich fälschen. Mit Cosign oder einer vergleichbaren Lösung signiert die Pipeline jedes Artefakt beim Push. Entscheidend ist der zweite Schritt: Die Verifikation muss beim Deploy erzwungen werden. Ein Cluster, der nur signierte Images einer bekannten Identität zulässt, ignoriert ein untergeschobenes Image automatisch. Signieren ohne Verifizieren erzeugt nur ein gutes Gefühl, keine Kontrolle.

Scannen, bevor etwas produktiv geht

Registries wie Harbor, GitLab oder Nexus bringen einen Schwachstellen-Scanner mit oder lassen sich an einen anbinden. Sinnvoll ist ein Scan direkt beim Push und ein Gate in der Pipeline, das ab einem definierten Schweregrad blockiert. Wichtig ist die Priorisierung: Ein Scanner-Report mit dreihundert Einträgen ohne Bewertung führt dazu, dass niemand mehr hinschaut. Bewertet nach Erreichbarkeit und tatsächlichem Einsatz, nicht nach der reinen Zahl der CVEs.

Aufräumen gehört dazu

Eine Registry, die nie aufgeräumt wird, sammelt jahrealte Images mit längst gepatchten Lücken. Irgendwann zieht ein Rollback oder ein vergessener Job genau so ein altes Artefakt. Legt Aufbewahrungsregeln fest: aktuelle Releases behalten, alte Feature-Builds nach kurzer Frist löschen. Mutable Tags wie latest sind praktisch und riskant zugleich, weil sich der Inhalt unbemerkt ändert. Für alles, was reproduzierbar sein muss, gehört der Verweis auf den unveränderlichen Digest statt auf den Tag.

Intern oder öffentlich

Ein internes Nexus oder Harbor gibt euch die volle Kontrolle über Zugriff, Aufbewahrung und Scans, kostet aber Betrieb. Öffentliche Registries nehmen euch den Betrieb ab, verlagern das Vertrauen aber nach außen. Ein guter Mittelweg ist ein interner Proxy, der externe Images spiegelt, scannt und einfriert. So zieht die Pipeline nie direkt aus dem Internet, und ihr wisst jederzeit, welche Basisschichten bei euch im Umlauf sind.

Ihr wollt wissen, wie sicher eure Registry und der Weg dorthin wirklich sind? Der GitSecOps QuickCheck prüft eure Pipeline und Artefakt-Ablage auf die Schwachstellen aus diesem Beitrag und liefert in drei Werktagen einen konkreten Befund. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.