Ihre CI-Pipeline ist kein Tool. Sie ist das größte Einfallstor in Ihr Unternehmen.
Warum die CI/CD-Pipeline im Mittelstand oft das unsicherste System im Unternehmen ist und wie Sie sie systematisch härten.
Wenn wir nach Risiken fragen, nennen Unternehmen meist die üblichen Verdächtigen: öffentliche Webserver, E-Mail-Gateways, VPN-Zugänge, Endgeräte im Homeoffice. Die CI/CD-Pipeline steht selten auf dieser Liste. Sie wirkt wie ein interner Raum, zugangsgeschützt, von Fachleuten betreut, technisch und abgekoppelt vom Rest der IT. In Wirklichkeit ist sie in den meisten Mittelstandsunternehmen das größte Einfallstor, das wir sehen.
Das liegt an einer sehr unbequemen Eigenschaft moderner Pipelines: Sie haben vollen Zugriff auf alles, was Sie im Betrieb schützen wollen. Produktions-Credentials, Cloud-Zugänge, Signaturschlüssel, Deployment-Pfade, Datenbank-Migrationen. Wer die Pipeline kontrolliert, kontrolliert die Auslieferung. Wer die Auslieferung kontrolliert, kontrolliert Ihr Produkt.
Der blinde Fleck im Mittelstand
Die Schutzannahme lautet oft: „Unsere Pipeline läuft ja nur intern.“ Das stimmt im Sinne der Netzsegmentierung häufig. Es stimmt aber nicht im Sinne der Angriffsfläche. Eine Pipeline führt bei jedem Commit beliebigen Code aus. Dieser Code kommt aus einer Vielzahl von Quellen: Ihren eigenen Repositories, externen Paketen, Container-Images, OCI-Registries, Pre-Commit-Hooks. Jedes dieser Elemente ist ein Supply-Chain-Element. Jedes ist damit ein potenzieller Angriffsvektor.
Wir sehen regelmäßig Pipelines, die mit einem einzigen, langlebigen Secret arbeiten, das Zugriff auf die komplette Produktionsumgebung hat. Wir sehen Repositories, in denen jede Entwicklerin und jeder Entwickler faktisch Admin der Build-Infrastruktur ist. Wir sehen Pull Requests von externen Beitragenden, die Build-Logs in private Webhooks ausleiten könnten. Und wir sehen Systeme, in denen niemand mehr sagen kann, welche Tokens eigentlich rotiert werden müssten, weil sie in zu vielen Stellen hinterlegt sind.
Wie wir Pipelines systematisch härten
In unserem DevSecOps-as-a-Service-Betrieb gehen wir an diese Risiken mit einem immer gleichen, dokumentierten Vorgehen heran. Kein Hexenwerk, aber sehr konsequent.
Secret-Management mit kurzen Lebenszeiten
Langlebige Secrets sind unser erster Kandidat für die Abschaffung. Wir arbeiten mit dynamisch ausgestellten Zugangsdaten, typischerweise über OIDC-Föderation zu Ihrem Cloud-Konto oder über zentrale Secret-Manager mit kurzen TTLs. Ein Deployment-Job erhält exakt das Token, das er für genau diesen Lauf benötigt, und nichts darüber hinaus. Nach Abschluss ist das Token wertlos.
Getrennte Rechte, klare Rollen
Pipelines brauchen keine Root-Rechte, sondern präzise abgegrenzte Berechtigungen. Wir teilen Ihre Pipeline in Jobs mit unterschiedlichen Identitäten. Der Build-Schritt sieht keine Produktions-Credentials. Der Deploy-Schritt hat keinen Schreibzugriff auf Ihre Artefakt-Registry. Der Migrations-Schritt darf die Datenbank verändern, aber keine Images pushen. Ein kompromittierter Job sprengt damit nicht die ganze Kette.
Minimaler Zugriff auf Quellen und Ziele
Wer in Ihrem Repository schreiben darf, wer Workflows ändern darf, wer Environments freigibt, wer welche Runner benutzt: das sind Rollenfragen, die wir einmalig sauber modellieren und in Code gießen. Dazu gehören Branch-Protections, Required-Reviewer-Regeln, signierte Commits, signierte Artefakte und abgesicherte Runner.
Rotation als Prozess, nicht als Projekt
Secrets werden rotiert, weil das Risiko über die Zeit steigt, nicht weil ein Audit ansteht. In unseren Betriebsmodellen ist Rotation ein automatischer Prozess mit klarer Ownership, dokumentiertem Rotationsfenster und Alerting, wenn ein Secret älter wird als es sein dürfte.
Was das für Sie ändert
Das Ergebnis dieser Maßnahmen ist selten spektakulär und genau deshalb wertvoll. Ihre Pipeline bleibt schnell, aber sie ist kein Generalschlüssel mehr. Ein Angreifer, der einen Entwickleraccount übernimmt, erreicht damit noch lange nicht die Produktion. Ein kompromittiertes Paket in einem Build kann keine langlebigen Tokens abziehen, weil es keine gibt. Ein Audit lässt sich in Stunden statt Wochen vorbereiten, weil Rechte, Rollen und Rotationen dokumentiert und automatisiert sind.
Für Sie als Geschäftsführung oder IT-Leitung heißt das: Sie senken ein reales, unterschätztes Risiko und gewinnen gleichzeitig Tempo, weil Ihre Teams nicht mehr in unklaren Verantwortlichkeiten hängen bleiben.
Eine ehrliche Standortbestimmung
Wenn Sie sich unsicher sind, wie es in Ihrer Pipeline aktuell aussieht, lohnt sich ein kleiner, aber fokussierter Check. Wir haben dafür einen festen Fragenkatalog, der in ein bis zwei Gesprächen einen belastbaren Eindruck liefert: Wo liegen Ihre Secrets, wer darf Workflows ändern, wie werden externe Abhängigkeiten eingebunden, was passiert bei einem Incident?
30 Minuten, kein Pitch. Wir hören zu und sagen Ihnen ehrlich, wo wir Handlungsbedarf sehen und wo nicht.
Häufige Fragen
Was uns Kundinnen und Kunden zu diesem Thema am häufigsten fragen — offen beantwortet.
Ist das nur für regulierte Branchen relevant?+
Nein. Regulierung schafft Dokumentationspflichten, das Risiko selbst besteht unabhängig davon. Wenn Ihre Pipeline ausliefert, was Ihre Kunden nutzen, ist sie schützenswert — ob Sie im Maschinenbau, im Handel oder in der Beratung tätig sind.
Wie lange dauert eine typische Pipeline-Härtung?+
Eine erste, spürbare Risikoreduktion erreichen wir in der Regel in zwei bis vier Wochen. Die vollständige Umstellung auf OIDC, getrennte Rechte und automatische Rotation dauert je nach Größe Ihrer Landschaft zwei bis drei Monate. Wir priorisieren nach Risiko, nicht nach Vollständigkeit.
Was ist mit den Secrets, die schon seit Jahren laufen?+
Die nehmen wir uns strukturiert vor. Erst Inventarisierung, dann Ablösung durch kurzlebige Alternativen, schließlich Rotation und Überwachung. Wir schalten nichts einfach ab, sondern sorgen dafür, dass der Umstieg keine laufenden Prozesse blockiert.
Müssen wir dafür unsere Entwicklungsprozesse umstellen?+
Nein. Wir ändern nichts am Tages-Workflow Ihrer Entwickler. Die Härtung geschieht im Pipeline-Code und in der Rechte-Modellierung. Ihre Teams merken die Änderung daran, dass bestimmte gefährliche Abkürzungen nicht mehr funktionieren — und dass Reviews klarer werden.
Wir nutzen GitHub Actions/GitLab CI — ist das sicher genug?+
Die Plattform ist solide, entscheidend ist, wie Sie sie konfigurieren. Ob GitHub Actions, GitLab CI oder ein anderer Anbieter: Ohne kurze Token-Lebenszeiten, getrennte Rechte und Branch-Protections bleibt das Risiko hoch. Wir härten innerhalb Ihrer bestehenden Plattform, ein Umzug ist selten nötig.