Die Sicherheit Ihrer Software beginnt nicht erst bei der eigenen Codezeile — sie beginnt bei jedem Framework, jeder Bibliothek und jedem Drittanbieter-Dienst, den Ihr Entwicklungsteam einbindet. Software-Lieferkette absichern ist heute keine optionale Disziplin mehr, sondern eine geschäftskritische Anforderung — auch für kleine und mittlere Unternehmen. Der SolarWinds-Angriff 2020 und der Vorfall mit der Log4Shell-Schwachstelle 2021 haben eindrücklich gezeigt, wie verheerend kompromittierte Software-Lieferketten sein können: Tausende Unternehmen weltweit waren betroffen, Schäden in Milliardenhöhe entstanden.
Dieser Guide richtet sich an Geschäftsführer, CTOs und IT-Entscheider in deutschen KMU, die ihre Entwicklungsprozesse und eingesetzte Software systematisch absichern wollen — ohne den Aufwand eines Großkonzerns.
Was ist die Software-Lieferkette und warum ist sie gefährdet?
Die Software-Lieferkette (englisch: Software Supply Chain) umfasst alle Komponenten, Prozesse und Akteure, die an der Erstellung und Auslieferung von Software beteiligt sind. Dazu gehören:
- Quellcode des eigenen Entwicklungsteams
- Open-Source-Bibliotheken und Frameworks (npm, PyPI, Maven, etc.)
- Drittanbieter-SDKs und kommerzielle Komponenten
- CI/CD-Pipelines (Continuous Integration / Continuous Deployment)
- Build-Server und Artefakt-Repositories
- Cloud-Dienste und Deployment-Infrastruktur
Supply-Chain-Angriffe zielen nicht auf Ihr Unternehmen direkt, sondern auf eine vertrauenswürdige Komponente in Ihrer Kette. Gelingt es Angreifern, eine populäre Bibliothek zu kompromittieren, erreichen sie mit einem einzigen Angriff Tausende von Zielen gleichzeitig. Laut dem Bericht des Bundesamts für Sicherheit in der Informationstechnik (BSI) nehmen solche Angriffe seit 2020 dramatisch zu — und KMU sind dabei keineswegs verschont.
Software-Lieferkette absichern: Die größten Risikoquellen
Bevor Sie konkrete Maßnahmen ergreifen, sollten Sie verstehen, wo die realen Bedrohungen lauern. Die folgende Übersicht zeigt die wichtigsten Angriffsvektoren:
Kompromittierte Open-Source-Pakete
Der durchschnittliche Entwickler nutzt in modernen Projekten Hunderte von Abhängigkeiten — oft transitiver Natur, also Bibliotheken von Bibliotheken. Angreifer schleusen Schadcode in populäre Pakete ein (sogenannte „Typosquatting"-Angriffe), kompromittieren Maintainer-Accounts oder übernehmen verwaiste Pakete. Ein prominentes Beispiel: Der XZ-Utils-Backdoor-Angriff 2024, der monatelang unentdeckt blieb.
Unsichere CI/CD-Pipelines
Ihre Build- und Deployment-Pipeline ist ein hochprivilegiertess System: Sie hat Zugriff auf Produktionsumgebungen, Secrets und Kundendaten. Schwachstellen hier — etwa ungesicherte Umgebungsvariablen, fehlende Signaturprüfung von Artefakten oder überprivilegierte Service-Accounts — sind ein direktes Einfallstor.
Nicht verifizierte Drittanbieter
Beauftragen Sie externe Entwickler oder Agenturen? Dann fließt deren Code direkt in Ihre Produkte. Ohne klare Sicherheitsanforderungen und Prüfprozesse können dabei Schwachstellen, Backdoors oder schlecht gewartete Abhängigkeiten in Ihre Systeme gelangen.
Fehlende Transparenz über Komponenten
Viele Unternehmen wissen schlicht nicht, welche Software-Komponenten in ihren Produkten stecken. Ohne diese Sichtbarkeit ist keine systematische Absicherung möglich.
SBOM: Das Fundament für Ihre Supply-Chain-Sicherheit
Ein Software Bill of Materials (SBOM) ist das zentrale Werkzeug, um Ihre Software-Lieferkette abzusichern. Analog zur Stückliste in der Fertigung listet ein SBOM alle Komponenten Ihrer Software vollständig auf — inklusive Versionsnummern, Lizenzen und bekannter Schwachstellen.
So erstellen Sie ein SBOM in der Praxis
1. Toolauswahl: Nutzen Sie etablierte Tools wie Syft (für Container-Images), CycloneDX oder SPDX-kompatible Generatoren, die in Ihre CI/CD-Pipeline integriert werden können.
2. Automatisierung: Das SBOM sollte bei jedem Build automatisch neu generiert werden, nicht manuell.
3. Format wählen: CycloneDX und SPDX sind die gängigsten Standards — beide werden von der EU-Regulierung (Cyber Resilience Act) anerkannt.
4. Schwachstellenabgleich: Verknüpfen Sie das SBOM mit Datenbanken wie der National Vulnerability Database (NVD) oder OSV (Open Source Vulnerabilities), um bekannte CVEs automatisch zu erkennen.
5. Regelmäßige Aktualisierung: Planen Sie wöchentliche oder bei jedem Release automatische SBOM-Aktualisierungen ein.
Ein SBOM ist nicht nur ein internes Sicherheitstool — er wird zunehmend zur Anforderung bei Unternehmenskunden und im Rahmen des europäischen Cyber Resilience Act (CRA), der ab 2027 für viele Softwareprodukte verpflichtend gilt.
Konkrete Maßnahmen: So sichern Sie Ihre Software-Lieferkette ab
Die gute Nachricht: Sie müssen nicht alles auf einmal umsetzen. Ein strukturierter Ansatz in Phasen ist für KMU realistisch und wirksam.
Phase 1: Sichtbarkeit herstellen (Woche 1–4)
- Abhängigkeits-Inventar erstellen: Nutzen Sie Tools wie `npm audit`, `pip-audit`, `Snyk` oder `Dependabot` (kostenlos in GitHub integriert), um alle direkten und transitiven Abhängigkeiten zu erfassen.
- SBOM generieren: Integrieren Sie einen SBOM-Generator in Ihre CI/CD-Pipeline.
- Kritische Komponenten identifizieren: Welche Bibliotheken haben Zugriff auf sensible Daten oder kritische Funktionen? Diese verdienen besondere Aufmerksamkeit.
- Lizenz-Compliance prüfen: Enthält Ihre Software Komponenten mit inkompatiblen Lizenzen (z. B. GPL in proprietären Produkten)? Auch das ist ein geschäftliches Risiko.
Phase 2: Aktive Absicherung (Woche 5–12)
Abhängigkeiten aktiv managen:
- Setzen Sie auf Pinning (exakte Versionsfixierung) statt auf vage Versionsbereiche — damit verhindern Sie, dass automatische Updates Schadcode einschleusen.
- Richten Sie automatisierte Alerts für neue CVEs in Ihren Abhängigkeiten ein.
- Reduzieren Sie aktiv die Anzahl der Abhängigkeiten — jede nicht genutzte Bibliothek ist ein unnötiges Risiko.
- Prüfen Sie Pakete vor der Erstintegration: Wann wurde zuletzt ein Release veröffentlicht? Wie aktiv ist die Community? Gibt es bekannte Sicherheitsprobleme?
CI/CD-Pipeline absichern:
- Verwenden Sie Least-Privilege-Prinzip für alle Service-Accounts in der Pipeline.
- Speichern Sie Secrets nie als Klartext in Konfigurationsdateien — nutzen Sie dedizierte Secret-Manager (HashiCorp Vault, AWS Secrets Manager, GitHub Actions Secrets).
- Implementieren Sie Artefakt-Signierung mit Tools wie Sigstore/Cosign: Damit stellen Sie sicher, dass nur von Ihnen signierte Builds deployed werden.
- Aktivieren Sie Branch-Protection-Regeln und erfordern Sie Code-Reviews vor Merges in Produktionsbranches.
Drittanbieter absichern:
- Definieren Sie in Verträgen mit externen Dienstleistern klare Sicherheitsanforderungen (Coding Guidelines, Dependency-Management, SBOM-Lieferpflicht).
- Führen Sie Code-Reviews für extern entwickelten Code durch, bevor er integriert wird.
- Begrenzen Sie den Zugriff externer Entwickler auf das absolut Notwendige.
Phase 3: Kontinuierliche Überwachung (ab Monat 3)
- Richten Sie automatisierte Dependency-Scans als Teil jedes Builds ein — ein fehlgeschlagener Scan sollte den Build blockieren.
- Abonnieren Sie Sicherheits-Advisory-Feeds für Ihre Kerntechnologien (GitHub Security Advisories, CVE-Mailinglisten).
- Führen Sie quartalsweise Supply-Chain-Reviews durch: Welche neuen Abhängigkeiten sind hinzugekommen? Welche sind veraltet?
- Dokumentieren Sie Ihren Prozess — für interne Governance und als Nachweis gegenüber Kunden oder Auditoren.
Tools und Technologien im Überblick
Für KMU empfehlen wir einen pragmatischen Tool-Stack, der ohne großen Konfigurationsaufwand sofort Mehrwert liefert:
| Einsatzbereich | Empfohlene Tools |
|---|---|
| Abhängigkeits-Scanning | Dependabot, Snyk, OWASP Dependency-Check |
| SBOM-Generierung | Syft, CycloneDX CLI, SPDX Tools |
| Secret-Management | HashiCorp Vault, GitHub Secrets, Azure Key Vault |
| Artefakt-Signierung | Sigstore/Cosign, Notation |
| Container-Sicherheit | Trivy, Grype, Docker Scout |
| Policy-Enforcement | Open Policy Agent (OPA), Kyverno |
Die meisten dieser Tools sind Open Source und kostenlos — der primäre Investitionsaufwand liegt in der Einrichtung und Integration, nicht in Lizenzkosten.
Regulatorische Anforderungen: Was KMU jetzt wissen müssen
Die Software-Lieferkette rückt zunehmend in den Fokus der europäischen Gesetzgebung:
- Cyber Resilience Act (CRA): Ab 2027 müssen Hersteller digitaler Produkte umfassende Sicherheitsanforderungen erfüllen — darunter die Bereitstellung von SBOMs und die aktive Verwaltung von Schwachstellen über den gesamten Produktlebenszyklus.
- NIS2-Richtlinie: Seit Oktober 2024 in deutsches Recht umgesetzt, erweitert die Pflichten zur Cybersicherheit und schließt explizit die Sicherheit der Lieferkette ein — auch für Unternehmen, die als Zulieferer kritischer Infrastrukturen fungieren.
- BSI IT-Grundschutz: Das Grundschutz-Kompendium enthält spezifische Bausteine zur Absicherung von Softwareentwicklungsprozessen und Lieferketten.
Handlungsempfehlung: Prüfen Sie jetzt, ob Ihr Unternehmen unter NIS2 fällt und welche Anforderungen für Sie relevant sind. Auch wenn Sie nicht direkt betroffen sind, werden viele Unternehmenskunden zunehmend Nachweise über Ihre Supply-Chain-Sicherheitspraktiken einfordern.
Häufige Fehler und wie Sie sie vermeiden
Viele KMU starten mit den richtigen Absichten, machen dann aber typische Fehler:
- Fehler 1: Nur direkte Abhängigkeiten prüfen — Die meisten Angriffe treffen transitive Abhängigkeiten (Abhängigkeiten von Abhängigkeiten). Prüfen Sie den vollständigen Dependency-Tree.
- Fehler 2: Scanning nur einmalig durchführen — Neue Schwachstellen werden täglich entdeckt. Nur kontinuierliches Monitoring ist wirksam.
- Fehler 3: Alerts ignorieren — Wenn Sicherheits-Alerts systematisch dismissed werden, weil „zu viele" kommen, liegt ein Priorisierungsproblem vor. Definieren Sie klare SLAs: Kritische CVEs innerhalb von 24 Stunden, hohe innerhalb einer Woche.
- Fehler 4: Secrets in Git-Repositories — Ein klassiker, der immer noch vorkommt. Nutzen Sie Tools wie `git-secrets` oder `truffleHog`, um Repositories auf versehentlich eingecheckte Credentials zu prüfen.
- Fehler 5: Keine Dokumentation — Ohne dokumentierte Prozesse ist Supply-Chain-Sicherheit nicht auditierbar und nicht skalierbar.
Weitere wertvolle Hintergrundinformationen zu sicheren Entwicklungspraktiken finden Sie auch in unserem Pilecode Blog, wo wir regelmäßig praxisnahe Guides zu IT-Sicherheitsthemen veröffentlichen.
Fazit: Software-Lieferkette absichern ist kein Einmalprojekt
Software-Lieferkette absichern erfordert einen kontinuierlichen, systematischen Ansatz — keine einmalige Aufräumaktion. Die gute Nachricht: Mit dem richtigen Tool-Stack und klar definierten Prozessen können KMU eine erhebliche Sicherheitsverbesserung erzielen, ohne ein großes Budget einzusetzen.
Der Einstieg ist einfacher als gedacht: Beginnen Sie mit einem Abhängigkeits-Scan Ihres wichtigsten Projekts — Sie werden überrascht sein, was Sie finden. Dann bauen Sie Schritt für Schritt die weiteren Maßnahmen auf.
Die Alternative — Nichtstun — ist angesichts der wachsenden Bedrohungslage und der zunehmenden regulatorischen Anforderungen schlicht keine Option mehr. Ein einziger kompromittierter Build kann Ihren Ruf, Ihre Kundendaten und Ihr Unternehmen gefährden.
Haben Sie Fragen zu Ihrer konkreten Situation oder möchten Sie Ihre Software-Lieferkette mit professioneller Unterstützung analysieren und absichern? Sprechen Sie mit unseren Experten bei Pilecode — wir helfen Ihnen, einen pragmatischen und wirksamen Sicherheitsplan zu entwickeln.
Jetzt kostenloses Erstgespräch vereinbaren →
Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.