Der Satz fällt in fast jedem Erstgespräch: „Uns greift doch keiner an, wir sind viel zu klein.“ Das war nie ganz richtig, und bei Software-Lieferketten stimmt es heute gar nicht mehr. Wer Code baut und ausliefert, ist Teil einer Kette. Und Angreifer suchen nicht mehr das größte Ziel, sondern das schwächste Glied auf dem Weg dorthin.
Der Angreifer sucht den Weg, nicht die Größe
Ein direkter Angriff auf ein großes Unternehmen ist teuer. Der Umweg über einen kleinen Zulieferer ist billig. Wenn ein Mittelständler eine Bibliothek pflegt, ein Plugin baut oder als Dienstleister Code für einen größeren Kunden schreibt, wird sein Repository und seine Pipeline zum Einfallstor. Der eigentliche Schaden entsteht dann beim Kunden, aber der Zugang lief über das kleine Team, das sich für uninteressant hielt.
Genau das macht Lieferketten-Angriffe so attraktiv. Ein kompromittiertes Paket, das hundert Firmen einsetzen, ist hundert Einbrüche zum Preis von einem. Der Angreifer muss den Endkunden nicht kennen. Er muss nur ein Glied finden, das seine Build- und Veröffentlichungswege nicht absichert.
Automatisierung macht Größe zweitrangig
Die meisten Angriffe auf Lieferketten sind nicht zielgerichtet, sondern breit gestreut. Bots scannen öffentliche Repositories nach offenen Tokens, durchsuchen Paket-Registries nach Namen, die sich für Typosquatting eignen, und probieren bekannte Fehlkonfigurationen automatisiert durch. Für diese Werkzeuge ist ein Team mit fünf Entwicklern genauso sichtbar wie ein Konzern. Die Frage ist nicht, ob jemand vorbeischaut, sondern ob er etwas findet.
Ein durchgesickerter Deploy-Key in einem alten Commit, eine Third-Party-Action ohne festgepinnte Version, ein Paketname, den noch niemand reserviert hat: Das sind keine Lücken, die man von Hand aufspürt. Das findet ein Scanner in Minuten. Klein zu sein schützt davor nicht, es macht nur die Verteidigung nachlässiger.
Der Kunde fragt inzwischen nach
Selbst wer das Angriffsrisiko für gering hält, kommt an einem zweiten Punkt nicht vorbei: Größere Kunden verlangen mittlerweile Nachweise. Wer als Zulieferer Software liefert, bekommt Fragebögen zu Abhängigkeiten, Herkunft der Artefakte und Freigabeprozessen. Ein Team, das darauf keine Antwort hat, verliert den Auftrag an eines, das sie hat. Aus der Sicherheitsfrage wird eine Vertriebsfrage.
Das ist die eigentliche Verschiebung. Lieferketten-Sicherheit war lange ein Thema für Compliance-Abteilungen großer Konzerne. Heute wandert die Anforderung nach unten, an jeden, der in die Kette einliefert. Die Größe des eigenen Teams entscheidet nicht mehr, ob das Thema relevant ist.
Was kleine Teams konkret tun können
Die gute Nachricht: Die wirksamsten Schritte sind keine Großprojekte. Sie kosten wenig und schließen die Türen, die Scanner zuerst probieren.
- Secret Scanning und Push Protection aktivieren, damit Tokens gar nicht erst in die Historie gelangen.
- Abhängigkeiten mit einer Software-Stückliste erfassen, statt sie im Kopf zu behalten.
- Fremde Actions und Images auf feste Versionen pinnen, nicht auf bewegliche Tags.
- Deploy-Keys und Tokens ein Ablaufdatum geben und regelmäßig rotieren.
- Wissen, welche Artefakte woher kommen, bevor ein Kunde danach fragt.
Keiner dieser Punkte braucht ein eigenes Sicherheitsteam. Sie brauchen jemanden, der einmal hinschaut und die Verantwortung übernimmt. Genau daran scheitert es in kleinen Teams meist, nicht am Werkzeug.
Nicht sicher, wo Ihre Pipeline angreifbar ist? Der GitSecOps QuickCheck prüft Ihre Build- und Veröffentlichungswege auf die Lücken, die Angreifer zuerst suchen. Festpreis 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone.
Hinterlasse einen Kommentar