Risiken und Best Practices für die Software-Lieferkette

Anstatt Apps ausschließlich mit eigenem Code zu entwickeln, kombinieren moderne Entwicklungsteams proprietären Code – das „gewisse Etwas“ ihres Unternehmens – mit zahlreichen Komponenten von Drittanbietern. Diese Ressourcen von Drittanbietern, von denen viele Open Source sind, sind für Entwickler unverzichtbar: Sie sparen Zeit und ermöglichen bessere Innovationen. Doch mit den grenzenlosen Möglichkeiten von Open-Source-Software geht eine neue Risikodimension einher: die Sicherheit der Software-Lieferkette.

Welche Sicherheitsrisiken gibt es in der Lieferkette?

Warum müssen Unternehmen heute ihre Software-Lieferkette so genau im Blick behalten? Die Softwareentwicklung ist ständig im Wandel. Entwickler in Ihrem Unternehmen verwenden täglich zahlreiche Komponenten in ihren Anwendungen, um das Rad nicht neu erfinden zu müssen. Jede dieser Komponenten hat Abhängigkeiten, und diese Abhängigkeiten haben wiederum Abhängigkeiten. Ihr Unternehmen ist gefährdet, wenn eine Komponente in dieser Kette bekannte kritische Schwachstellen enthält.

Der Sicherheitsverstoß bei SolarWinds Orion ist ein Beispiel dafür, wie Cyberrisiken in der Lieferkette nachhaltige Folgen haben können.

Hier sind einige häufige Bedrohungen für die Lieferkette:

• Verwundbare Open-Source-Pakete und Container. Ein durchschnittliches npm-Paket bringt beispielsweise 79 Pakete von Drittanbietern und 39 Maintainer in Ihre Software-Lieferkette ein. Mit dem Download dieser einzelnen Komponente schaffen Sie eine ganze Angriffsfläche.

• Typosquatting und Markenmissbrauch. Bei dieser Angriffsmethode veröffentlichen Angreifer schädliche Pakete in einer Registry und verwenden dabei Namen, die legitimen Paketen ähneln. Wer die Sicherheit seiner Open-Source-Pakete nicht überprüft, läuft Gefahr, versehentlich eine dieser schädlichen Ressourcen herunterzuladen.

• Datenverwaltung. Viele Unternehmen wissen schlicht nicht, was sich in ihrer Software-Lieferkette befindet. Ihre Software-Stücklisten (SBOMs) sind schnell veraltet, weil sie nicht aktualisiert werden, wenn Entwickler neue oder aktualisierte Open-Source-Pakete oder Container hinzufügen.

• Zugriffsrechte. Unternehmen gewähren Anbietern oder Komponenten von Drittanbietern zu weitreichende Zugriffsrechte. Wird dieser Dritte kompromittiert, kann er zum schwächsten Glied der Lieferkette werden.

• Menschliches Versagen oder Fahrlässigkeit. Fehler passieren, wenn Teams Best Practices für die Sicherheit der Software-Lieferkette nicht berücksichtigen. Ein Entwickler könnte ein schädliches Paket herunterladen oder einem Drittanbieter Zugriff auf vertrauliche Informationen gewähren. Menschliches Versagen kann den gesamten SDLC auf vielfältige Weise gefährden.

Weitere Informationen zur Sicherheit der Lieferkette finden Sie in unserem aktuellen Whitepaper zur Lieferkettensicherheit.

Warum eine SBOM allein nicht ausreicht

Viele Unternehmen kennen zwar die Risiken, die mit der Verwendung von Komponenten von Drittanbietern einhergehen, verfolgen bei der Sicherheit ihrer Lieferketten jedoch oft einen unvollständigen Ansatz, der zu Angriffen führen kann. Häufig wird angenommen, dass eine SBOM ausreicht, um eine Software-Lieferkette abzusichern. Das ist verständlich: SBOMs stehen heutzutage bei vielen Sicherheitsdiskussionen im Mittelpunkt und wurden auch in einer kürzlich erlassenen Executive Order hervorgehoben.

Doch eine SBOM ist eigentlich nur eine „Zutatenliste“. Und ähnlich wie bei verpackten Lebensmitteln können ihre Einträge verwirrend und unbekannt sein – etwa „Polysorbat 80“. Vielleicht erkennen Sie den Inhaltsstoff, aber ist er gut oder schlecht?

Um den Vergleich weiterzuführen: Ein Inhaltsstoff, der früher als unbedenklich galt, kann später zu etwas werden, das man meiden sollte (zum Beispiel roter Farbstoff Nr. 5). Bei SBOMs ist es genauso. Nur weil Ihre SBOM heute in Ordnung ist, heißt das nicht, dass sie es morgen auch noch ist. Ihr Unternehmen muss weitere kontinuierliche Best Practices für die Sicherheit der Lieferkette umsetzen, um Risiken wirksam vorzubeugen.

Best Practices für die Sicherheit der Lieferkette in Ihrem Unternehmen

Entwicklungsteams sollten fünf Best Practices für die Sicherheit der Lieferkette befolgen: Open-Source-Pakete und Container scannen, die richtigen Pakete verwenden und schädliche meiden, eine aktuelle SBOM pflegen, RBAC-Richtlinien umsetzen und die Schulung des Teams priorisieren.

Sehen wir uns diese Best Practices genauer an:

1. Scannen Sie Ihre Open-Source-Pakete und Container auf Schwachstellen und legen Sie anschließend Richtlinien fest

Alle Open-Source-Pakete und Container manuell zu erfassen und auf Schwachstellen zu prüfen, ist unrealistisch. Investieren Sie stattdessen in ein Tool, das Ihre Software-Lieferkette kontinuierlich auf Schwachstellen überprüft. Verhindern Sie proaktiv, dass verwundbare Komponenten in nachgelagerte Bereiche gelangen, indem Sie Richtlinien einrichten, die Entwickler früh im SDLC dazu anleiten, riskante Open-Source-Software durch bessere Alternativen zu ersetzen.

2. Stellen Sie sicher, dass Sie die richtigen Pakete verwenden

Da Typosquatting und Markenmissbrauch zu den häufigsten Bedrohungen für die Lieferkette zählen, ist es wichtig, jedes Paket genau zu überprüfen. Richten Sie so früh wie möglich im Softwareentwicklungszyklus Prüfpunkte für Open-Source-Pakete ein und verwenden Sie dazu ein SCA-Tool wie Snyk Open Source. Integrieren Sie Sicherheits-Scans in die Workflows Ihres Entwicklungsteams, beispielsweise in die CLI der CI/CD-Pipeline-Tools, damit Ihr Team die Empfehlungen dieser Prüfpunkte problemlos befolgen kann.

3. Erfassen Sie, was in Ihren Anwendungen enthalten ist (SBOM)

SBOMs sind für die Best Practices zur Sicherheit der Software-Lieferkette jedes Unternehmens unverzichtbar. Da sich der moderne SDLC so schnell verändert, sollten Sie den Einsatz von Tools zur SBOM-Automatisierung in Betracht ziehen.

Außerdem müssen Teams im Blick behalten, wer Zugriff auf ihre SBOMs hat. Angenommen, Ihre SBOM ist für ein breites Publikum verfügbar und Ihre Software enthält eine neu bekannt gewordene kritische Schwachstelle. Dann wird die SBOM selbst zu einer Bedrohung für die Sicherheit der Lieferkette!

4. Setzen Sie umfassende RBAC-Richtlinien um

Bei der rollenbasierten Zugriffskontrolle geht es um das Prinzip der geringsten Berechtigungen: Standardmäßig erhält jeder Nutzer nur so viele Zugriffsrechte, wie für die jeweilige Aufgabe erforderlich sind. Für die Einführung von RBAC-Richtlinien muss Ihr Team wissen, wer auf welche Ressourcen zugreifen kann und über welche Zugriffsebene die jeweiligen Personen verfügen. Policy as Code (PaC) ermöglicht Sicherheitsteams, diese RBAC-Richtlinien mithilfe einer deklarativen Hochsprache im Code zu definieren. So werden die Richtlinien zentral verwaltet und einheitlich im gesamten Unternehmen angewendet.

5. Priorisieren Sie die Schulung und Weiterbildung Ihres Teams

Um Problemen durch menschliches Versagen oder Fahrlässigkeit vorzubeugen, sollten Sie Ihre Mitarbeitenden über mögliche Bedrohungen für die Lieferkette aufklären und schulen. Gamification ist eine hervorragende Möglichkeit, Entwickler dazu zu motivieren, Best Practices für die Sicherheit der Lieferkette kennenzulernen. Ebenso wichtig ist es, Teammitglieder zu würdigen, wenn sie einen positiven Beitrag zur Sicherheit Ihres Unternehmens leisten. Snyk bietet kostenlose Sicherheitslektionen für Entwickler – hier finden Sie mehr.

Mit Snyk Ihre Software-Lieferkette absichern

Die Lösungen von Snyk für die Sicherheit der Lieferkette ermöglichen Entwicklungs- und Sicherheitsteams, gemeinsam ihre Software-Lieferkette abzusichern. Wir unterstützen Unternehmen dabei, ihre Open-Source-Bibliotheken, Entwicklertools, Container-Images und Cloud-Infrastruktur zu schützen. Unsere Security-Plattform für Entwickler lässt sich direkt in vorhandene Entwicklertools und Workflows integrieren. So können Teams Best Practices für die Sicherheit der Lieferkette schnell und einfach umsetzen.