Skip to main content

Drei Trends, die heute die Sicherheit der Software-Lieferkette prägen

Artikel von
blog feature open source security

22. August 2024

0 Min. Lesezeit

Die Softwareentwicklung ähnelt nach wie vor einer Fertigungsstraße: Entwickler beziehen Ressourcen aus dem gesamten Web, um Anwendungen zu erstellen. Ressourcen von Drittanbietern spielen zwar schon seit vielen Jahren eine zentrale Rolle bei der Softwareentwicklung, doch wie Entwicklungsteams diese externen Komponenten nutzen, hat sich verändert. Entwickler integrieren eine größere Vielfalt an Ressourcen von Drittanbietern in ihre Projekte. Dank KI-Coding-Assistenten gelingt ihnen das deutlich schneller – direkt in ihrem proprietären Code.

Während sich all diese Veränderungen in der Softwareentwicklung vollziehen, erkennen sowohl Aufsichtsbehörden als auch Unternehmen die Risiken vieler dieser Praktiken in der Software-Lieferkette und setzen sich weiterhin für Vorschriften zu Software von Drittanbietern ein.

Was bedeuten diese Entwicklungen für Softwareentwicklungsorganisationen? Unternehmen, die Anwendungen entwickeln, müssen sich heute mehr denn je auf proaktive Sicherheitsmaßnahmen konzentrieren. Dazu gehören testbare Software Bill of Materials (SBOMs), eine weiter nach links verlagerte Codesicherheit, um KI-generiertem Code Rechnung zu tragen, umsetzbare Tools, mit denen Entwickler sichere Komponenten von Drittanbietern auswählen können, sowie die Nutzung des Geschäftskontexts, um Risiken in der Lieferkette richtig zu priorisieren.

Um zu verstehen, wie solche proaktiven Maßnahmen aussehen, betrachten wir drei wichtige Trends in der Lieferkette und ihre Auswirkungen auf die Softwareentwicklung:

Zunehmende Vorschriften zu SBOMs

SBOMs sind ein wiederkehrendes Thema in vielen aktuellen Compliance-Anforderungen und Lieferantenverträgen. Öffentliche und private Organisationen verschärfen ihre SBOM-Standards, da die Sorge über unsichere und schädliche Komponenten und Abhängigkeiten wächst. Viele dieser Vorschriften betonen, wie wichtig es ist, SBOMs regelmäßig zu aktualisieren, wenn neue Ressourcen von Drittanbietern in Ihr Software-Ökosystem aufgenommen werden.

Was diese Vorschriften für heutige Teams bedeuten

Aktuelle SBOMs werden schon bald über den Erfolg Ihres Unternehmens entscheiden. Da immer mehr Verträge mit Behörden und Unternehmen sie voraussetzen, müssen Sie für Ihr Unternehmen eine erneut testbare SBOM erstellen können, damit Sie neue Bedrohungen oder Veränderungen in Ihrem Ökosystem im Laufe der Zeit berücksichtigen können. SBOMs sind auch im Hinblick auf den Softwareeinsatz wichtig, da sie für Transparenz bei den von Ihnen genutzten Diensten sorgen.

KI-generierter Code

KI-Coding-Assistenten gehören heute für Softwareentwicklungsteams schnell zum Alltag. Die Einführung von KI-generiertem proprietärem Code hat jedoch einige Auswirkungen auf die Sicherheit der Software-Lieferkette. Sicherheitsteams müssen grundlegende Maßnahmen für Codesicherheit – etwa statische Anwendungssicherheitstests – verstärken und ihre bestehenden Praktiken und Tools an das Tempo anpassen, mit dem KI-generierter Code in Repositories gelangt.

Was die zunehmende Nutzung von KI-Coding-Assistenten für Teams bedeutet

KI-Coding-Assistenten erhöhen die Erwartungen an Tempo und Effizienz in Entwicklungsteams. Entwickler vertrauen KI-generiertem Code in der Regel stärker als von Menschen geschriebenem Code und möchten noch schneller vorankommen als bisher. Dadurch bleibt wenig Raum für Sicherheitsmaßnahmen, die Zeit und Energie kosten. Sicherheitsteams, die bisher mit veralteten Praktiken für Codesicherheit auskamen – etwa proprietären Code erst spät im SDLC zu testen oder Entwickler zum Testen und Absichern ihres Codes zwischen Tools wechseln zu lassen –, können sich das nicht mehr leisten. Sie müssen weiter nach links verlagern und Sicherheitstools direkt in Entwicklungsabläufe integrieren.

Eine sich wandelnde Bedrohungslandschaft

Neben diesen Faktoren hat sich die Bedrohungslandschaft in den vergangenen Jahren deutlich verändert. Insbesondere KI-bezogene Bedrohungen bergen neue Risiken für Unternehmen. Das OWASP Machine Learning Security Top Ten project führt Angriffe auf KI-Lieferketten sogar als erhebliche Bedrohung für LLMs auf. Indem Angreifer ganze Machine-Learning-Projekte kompromittieren, können sie ihre Wirkung vervielfachen und auf mehr Ressourcen zugreifen als bei der Kompromittierung einer statischen Bibliothek.

Was die sich wandelnde Bedrohungslandschaft für Teams bedeutet

Teams müssen von Anfang an Wege finden, die sichersten Ressourcen von Drittanbietern auszuwählen. Anschließend sollten sie bestehende Bibliotheken regelmäßig überprüfen, um sicherzustellen, dass keine davon kompromittiert wurde. Außerdem müssen Sicherheitslücken in Komponenten von Drittanbietern nach ihrer Geschäftskritikalität priorisiert werden. So kann sich Ihr Team zuerst auf die Behebung von Sicherheitslücken konzentrieren, die geschäftskritische Ressourcen betreffen, und anschließend die übrigen angehen.

Der Schlüssel, um mit diesen Trends in der Lieferkettensicherheit Schritt zu halten, ist Proaktivität. Es geht darum, mögliche Risiken – für Ihr Unternehmen oder für den Sicherheitsprozess selbst – vorherzusehen und ihnen so früh wie möglich entgegenzuwirken. Diese Fragen erleichtern den Einstieg in einen proaktiven Ansatz:

  • Welche Geschäftsbereiche, Anwendungen oder Bibliotheken wären für einen Angreifer am kritischsten, wenn er in eine Anwendung eindringen würde? Welche wären weniger wichtig? Solche Fragen zum Kontext helfen Ihnen zu verstehen, welche geschäftskritischen Bereiche zuerst geschützt werden sollten und welche Bereiche mit geringem Risiko weiter unten auf Ihrer Liste stehen können. Um sich ein so detailliertes Bild der Risiken zu verschaffen, müssen Sie tiefer einsteigen, als nur Sicherheitslücken nach CVSS oder Erreichbarkeit zu priorisieren.

  • Wie oft müssen Ihre Entwicklungsteams zwischen verschiedenen Kontexten wechseln, wenn sie proprietären Code oder Komponenten von Drittanbietern absichern? Müssen sie ihre Entwicklungsumgebung verlassen, um Sicherheitslücken zu beheben? Wenn ja, verlangen Sie ihnen wahrscheinlich zu viel ab – besonders, wenn sie dank KI-Coding-Assistenten schneller arbeiten.

  • Welche automatisierten Schutzmaßnahmen verhindern, dass unsichere Komponenten von Drittanbietern oder Lizenzprobleme überhaupt erst in Ihre Repositories gelangen? Es empfiehlt sich, für Ihre Entwickler Listen sicherer Ressourcen von Drittanbietern zusammenzustellen – zum Beispiel eine Datenbank mit Empfehlungen für Basis-Images oder eine Möglichkeit, hochwertige Pakete für bestimmte Anforderungen auszuwählen. Außerdem sollten Sie Ihre Richtlinien in den Software-Build- und Bereitstellungsprozess sowie in die zugehörigen Pipelines integrieren.

Weitere Einblicke in die heutigen Herausforderungen der Lieferkettensicherheit und praktische Tipps finden Sie in unserem E-Book „Securing today’s software supply chains“.