Leitfaden zur Software Composition Analysis: 5 zentrale Herausforderungen für SCA

Software Composition Analysis verstehen: Wie funktioniert SCA?

Der Code, der heute viele – ja, die meisten – Anwendungen antreibt, enthält Open-Source-Komponenten. Open-Source-Code kann jedoch kritische Schwachstellen enthalten, wie der kürzlich entdeckte Log4Shell-Exploit.

Software Composition Analysis ist der beste Weg, um Schwachstellen in Open-Source-Paketen zu finden und zu erfahren, wie sie sich beheben lassen. So können Sie Ihren Code und den Zustand Ihrer Anwendungen schützen. Nutzen Sie diesen Leitfaden, um Best Practices für den Einsatz von SCA-Tools kennenzulernen.

SCA ist nicht neu, doch die in den letzten Jahren zunehmende Nutzung von Open Source hat sie zu einer wichtigen Säule von Application-Security-Programmen gemacht. Infolgedessen ist die Zahl der SCA-Tools stark gestiegen. Doch SCA-Lösungen sind nicht alle gleich. Moderne Softwareentwicklungsmethoden, darunter das Konzept von DevSecOps, erfordern einen entwicklerorientierten SCA-Ansatz: Entwicklungsteams benötigen entwicklerfreundliche Tools, während Sicherheitsteams Entwickler dabei unterstützen müssen, Sicherheit im gesamten SDLC zu berücksichtigen.

5 Herausforderungen bei der Software Composition Analysis (SCA)

Wie oben definiert, ist SCA ein Sammelbegriff für Application-Security-Methoden und Tools, die Anwendungen (wie SAST) – in der Regel während der Entwicklung – scannen, um die darin verwendeten Open-Source-Komponenten zu erfassen und anschließend die dadurch entstehenden Sicherheitslücken und Probleme mit Softwarelizenzen zu identifizieren. Um die Risiken dieser Open-Source-Komponenten erfolgreich zu verwalten und zu minimieren, stehen Unternehmen, die SCA-Methoden und Tools einsetzen, vor einer Reihe von Herausforderungen, die mit der Nutzung von Open Source bei der Entwicklung moderner Anwendungen zusammenhängen.

Erfahren Sie mehr über SAST im Vergleich zu SCA und wie Sie beides nutzen können, um sichere Software bereitzustellen.

1. Eingeschränkte Transparenz

Die Art und Weise, wie Open-Source-Code in die Codebasis einer Anwendung eingebunden wird, stellt eine große Herausforderung für die Transparenz dar. Entwickler können direkt verschiedene Open-Source-Pakete in ihren Code aufnehmen. Diese Pakete sind jedoch wiederum von weiteren Open-Source-Paketen abhängig, die den Entwicklern nicht unbedingt bekannt sind. Diese indirekten oder transitiven Abhängigkeiten können sich über mehrere Ebenen erstrecken. Dadurch ist es äußerst schwierig, einen vollständigen Überblick darüber zu erhalten, welcher Open-Source-Code tatsächlich in einer Anwendung verwendet wird.

Erschwerend kommt hinzu, dass die überwiegende Mehrheit der Sicherheitslücken in diesen transitiven Abhängigkeiten gefunden wird. Der Snyk-Bericht zum Stand der Open-Source-Sicherheit zeigte, dass ganze 86 % der node.js-Schwachstellen in transitiven Abhängigkeiten entdeckt werden. Ähnliche Zahlen wurden für Java und Ruby ermittelt. Das bedeutet, dass die meisten Sicherheitslücken in Anwendungen in Open-Source-Code zu finden sind, von dessen Verwendung Entwickler zunächst gar nichts wissen.

Cloud-native Anwendungen nutzen Open Source auf eine weitere Weise, die für Unternehmen eine Herausforderung für die Transparenz darstellen kann: als eine oder mehrere Ebenen, aus denen ein Container besteht. Container-Images können verschiedene Open-Source-Komponenten enthalten, die ebenfalls identifiziert und auf Schwachstellen geprüft werden müssen. Die Abstraktionsebene, die Container Entwicklern bieten und die aus Entwicklungssicht ein Vorteil ist, stellt aus Sicherheitssicht zugleich eine Schwäche dar.

2. Abhängigkeitslogik verstehen

Um die von einer Anwendung verwendeten Abhängigkeiten und die dadurch entstehenden Schwachstellen präzise zu identifizieren, ist ein tiefes Verständnis davon erforderlich, wie die einzelnen Ökosysteme mit Abhängigkeiten umgehen. Die Paketauflösung während der Installation, Lockfiles und Entwicklungsabhängigkeiten sind Beispiele für Faktoren, die beeinflussen, wie Schwachstellen in Open-Source-Paketen identifiziert werden, und die anschließenden Behebungsschritte bestimmen. Eine SCA-Lösung muss diese Feinheiten verstehen, um zu viele Fehlalarme zu vermeiden.

3. Von Schwachstellen überflutet

Die schiere Anzahl der identifizierten Schwachstellen erschwert es, den Überblick über die Schwachstellen und die Risiken für das Unternehmen zu behalten. Die Snyk Intel-Schwachstellendatenbank verzeichnete über 10.000 neue Schwachstellen – ein Zeichen für den kontinuierlichen Anstieg ihrer Zahl.

Was bedeutet das für Unternehmen? Letztendlich schlagen sich diese steigenden Zahlen meist in den Schwachstellen-Backlogs nieder, also in Listen identifizierter und zu bearbeitender Schwachstellen, die oft Tausende von Einträgen umfassen. Angesichts der begrenzten Ressourcen von Entwicklungs- und Sicherheitsteams ist es ohne die passenden Security-Kenntnisse oder Tools mit integriertem Expertenwissen äußerst schwierig, Maßnahmen zu priorisieren. Schweregrade auf Basis des CVSS sind eine gängige Methode, um Risiken zu bewerten und Maßnahmen zu priorisieren. Doch diese Methode weist einige grundlegende Schwächen auf, die ihren Einsatz erschweren.

4. Eine Schwachstellendatenbank finden

Informationen zu bekannten Schwachstellen sind über verschiedene Datenquellen verteilt. Die National Vulnerability Database (NVD) wird häufig genutzt, um Updates zu Schwachstellen zu erhalten. Doch auch andere Quellen bieten umfangreiche Security-Informationen zu Schwachstellen, etwa Issue-Tracker, Online-Foren und Security-Newsletter. Außerdem nimmt die NVD Schwachstellen möglicherweise nicht zeitnah genug auf. So wurden beispielsweise 92 % der JavaScript-Schwachstellen in der NVD zuvor bei Snyk erfasst. Diese Verzögerung kann angesichts der Notwendigkeit, Zeitfenster mit offengelegten Schwachstellen möglichst kurz zu halten, entscheidend sein. Rechtzeitig von einer Schwachstelle zu erfahren, kann den entscheidenden Unterschied machen.

5. Es muss schnell gehen

Während Entwickler mit Lichtgeschwindigkeit arbeiten, fällt es Sicherheitsteams schwer, Schritt zu halten. Um Code schneller und häufiger bereitzustellen, setzen Entwickler zunehmend auf Open Source. Sicherheitsteams, denen es an Personal und Ressourcen mangelt, haben traditionell versucht, Sicherheitsprüfungen in verschiedenen Phasen des Softwareentwicklungszyklus einzuführen. Das hat die Entwicklung jedoch tatsächlich verlangsamt. In anderen Fällen – möglicherweise mit noch schwerwiegenderen Folgen für das Application-Security-Programm eines Unternehmens – werden diese Prüfungen umgangen oder ignoriert.

So entstanden die Konzepte DevSecOps und Shift Left: Die Verantwortung für Sicherheit wird in die Entwicklungsteams verlagert, um Entwicklungsabläufe möglichst wenig zu beeinträchtigen und gleichzeitig Sicherheit zu gewährleisten. Eine neue Generation von SCA-Lösungen wurde mit diesem Grundsatz entwickelt und ermöglicht es, Open-Source-Sicherheitstests frühzeitig in den Entwicklungsprozess zu integrieren. Ein entwicklerorientierter Ansatz wie der von Snyk ergänzt Shift Left, indem er die Akzeptanz bei Entwicklern fördert.

Warum ist Software Composition Analysis (SCA) wichtig?

Gartner schätzt, dass mehr als 70 % der Anwendungen Schwachstellen aufweisen, die auf die Verwendung von Open Source zurückzuführen sind. Wie der Fall Equifax zeigt, kann die Ausnutzung solcher Schwachstellen für ein Unternehmen katastrophale Folgen haben.

Moderne Anwendungen bestehen immer häufiger aus Open-Source-Code. Schätzungen zufolge macht Open-Source-Code bis zu 90 Prozent des Codes in Anwendungen aus. Natürlich bestehen Anwendungen nicht ausschließlich aus Open Source. Tatsächlich gehört es zu den Herausforderungen für Unternehmen, ihre Codebasis zu schützen, dass Anwendungen aus verschiedenen Bausteinen zusammengesetzt sind, die alle abgesichert werden müssen, um Risiken effektiv zu verwalten und zu minimieren.

Warum ein Software-Composition-Analysis-Tool einsetzen?

Open-Source-Komponenten werden in nahezu allen Branchen zu wichtigen Bausteinen von Software. SCA-Tools helfen Ihnen dabei, die in Ihren Anwendungen verwendeten Open-Source-Komponenten im Blick zu behalten – entscheidend sowohl für die Produktivität als auch für die Sicherheit.

So wählen Sie ein Software-Composition-Analysis-Tool aus

SCA-Tools sind nicht alle gleich und unterscheiden sich in vielerlei Hinsicht. Bei der großen Auswahl an Anbietern kann man leicht den Überblick verlieren. Auf Grundlage der oben beschriebenen Herausforderungen haben wir eine Übersicht mit den wichtigsten 10 Punkten zusammengestellt, die Sie bei der Auswahl eines SCA-Tools berücksichtigen sollten.

Wo kommen SCA-Tools im Softwareentwicklungszyklus zum Einsatz?

SCA-Tools werden in mehreren Phasen des Softwareentwicklungszyklus (SDLC) integriert, um Risiken im Zusammenhang mit Open-Source-Abhängigkeiten zu identifizieren und zu minimieren. Während der Entwicklung helfen sie Entwicklern, Schwachstellen frühzeitig zu erkennen, indem sie Code-Repositories und Abhängigkeitsmanifeste scannen. In den Build- und Testphasen stellen SCA-Tools sicher, dass vor der Bereitstellung nur sichere und konforme Open-Source-Komponenten verwendet werden. Nach der Bereitstellung liefern sie außerdem kontinuierliche Sicherheitserkenntnisse und Warnmeldungen zu neu entdeckten Schwachstellen.

Worin unterscheiden sich SCA und andere Test-Tools wie DAST, SAST und IAST?

SCA konzentriert sich auf die Identifizierung von Schwachstellen in Open-Source-Komponenten und deren Abhängigkeiten. Andere Security-Test-Tools prüfen dagegen verschiedene Aspekte der Application Security. Static Application Security Testing (SAST) analysiert proprietären Quellcode vor der Ausführung auf Schwachstellen, während Dynamic Application Security Testing (DAST) laufende Anwendungen mithilfe simulierter Angriffe auf Sicherheitslücken untersucht. Interactive Application Security Testing (IAST) erkennt Schwachstellen in Echtzeit während der Ausführung einer Anwendung. SCA befasst sich gezielt mit Risiken im Zusammenhang mit Open-Source-Software und sorgt für Compliance und Sicherheit entlang der Software-Supply-Chain.

Warum brauchen wir Software Composition Analysis?

Software erobert die Welt – und Open Source die Software. Die Bedeutung von Open Source für die digitale Transformation lässt sich kaum überschätzen. Gemeinsam mit Cloud und DevOps ist Open Source einer der wichtigsten Faktoren, die Unternehmen dabei unterstützen, ihre Services zu digitalisieren und ihre Technologie einzusetzen, um sich im heutigen, stark umkämpften Markt besser zu behaupten.

Wie hilft Open Source? Anwendungen von Grund auf neu zu entwickeln, kostet Zeit und Ressourcen. Open-Source-Pakete mit derselben Funktionalität helfen, diese Kosten zu senken. Open Source ist von Natur aus äußerst flexibel und lässt sich bei Bedarf einfach anpassen. Dank der Community ist Open-Source-Code oft sicherer, da er gründlicher geprüft wird. Außerdem ist Open Source kostenlos und hilft Unternehmen, einen Vendor-Lock-in zu vermeiden.

All diese Vorteile steigern die Effizienz und erklären, warum Unternehmen, die ihre Time-to-Market verkürzen möchten, Open Source so häufig einsetzen. In einer weiteren Studie von Tidelift nannten 68 % der Befragten Kosteneinsparungen und kürzere Entwicklungszeiten als wichtigste Gründe dafür, dass ihr Unternehmen den Einsatz von Open Source in der Anwendungsentwicklung fördert. 48 % verwiesen auf die höhere Effizienz bei Entwicklung und Wartung von Anwendungen. Open Source wurde bereits vor COVID-19 immer häufiger eingesetzt, doch die Pandemie beschleunigte diese Entwicklung. Gartner schätzt inzwischen, dass 90 % der Unternehmen heute Open Source in ihren Anwendungen nutzen.

Moderne Software-Supply-Chains

Open Source ist nur ein Teil des Puzzles, aus dem moderne cloud-native Anwendungen bestehen. Anwendungen werden heute eher zusammengesetzt als entwickelt. Neben Open-Source-Paketen bestehen sie unter anderem aus proprietärem Code, Containern und Infrastructure as Code. Diese Komponenten sind Teil der neuen Software-Supply-Chain und können allesamt potenzielle Einstiegspunkte für Angreifer sein.

Eine ausgenutzte Schwachstelle in einem Teil der Supply-Chain kann dazu verwendet werden, die gesamte Anwendung zu infizieren. Dadurch vergrößert sich die Angriffsfläche und der Schutzbedarf steigt. So entdeckte GitHub im Fall der Octopus-Scanner-Malware eine Schadsoftware, die das Open-Source-NetBeans-IDE von Apache aufspüren und mit einer Backdoor versehen sollte. Der Angriff erfolgte über die Supply-Chain: Der Build-Prozess wurde missbraucht, sodass sich die daraus entstehenden Artefakte verbreiten konnten. Betroffene Projekte konnten geklont, geforkt und von zahlreichen verschiedenen Systemen verwendet werden. Das machte diesen Angriff bemerkenswert, aber leider nicht einzigartig. Der jüngste Angriff auf SolarWinds, diesmal auf proprietäre Software, zeigt zusätzlich, wie groß das Risiko ist, das die moderne Software-Supply-Chain für Unternehmen darstellt.

Open bedeutet nicht sicher

Open-Source-Projekte gelten als sicherer in der Anwendung. Schließlich werden Probleme schneller erkannt und behoben, wenn eine ganze Community an der Pflege und Entwicklung eines Projekts beteiligt ist. Das gilt natürlich für Fehler, aber auch für Sicherheitslücken. Allerdings bedeutet das nicht, dass Open Source risikofrei ist. Tatsächlich lässt sich argumentieren, dass genau derselbe Grund, aus dem Open-Source-Code oft als sicherer gilt, zugleich eine Schwachstelle darstellt.

Open-Source-Projekte sind per Definition öffentlich und für alle sichtbar – auch für Angreifer. Jede darin entdeckte und behobene Schwachstelle wird damit indirekt offengelegt und kann von Angreifern gefunden werden. Je beliebter ein Open-Source-Projekt ist, desto attraktiver ist das Paket für Angreifer, denn ein Angriff kann größere Auswirkungen haben. Als Beispiel für den oben erwähnten Equifax-Datendiebstahl: Das beim Angriff verwendete Open-Source-Paket, die Java-Bibliothek Apache Struts, kommt in sehr vielen Anwendungen zum Einsatz. Deshalb war der Angriff für seine große Reichweite bekannt.

Unternehmen, die Open Source nutzen, tun dies natürlich „auf eigenes Risiko“: Es gibt keinen Anbieter, der sie über Schwachstellen informiert, und keinen unterzeichneten Vertrag, der sie von ihrer Verantwortung entbindet. Für die Sicherheit dieser Komponenten sind allein die Nutzer verantwortlich.

Die Zukunft der Software Composition Analysis (SCA)

Angesichts der zunehmenden Nutzung von Open Source und der Aufmerksamkeit, die jüngste Sicherheitsverletzungen und Cyberangriffe auf sich gezogen haben, dürfte das Interesse an SCA weiter wachsen. Der Beitrag von Open Source zur digitalen Transformation wird immer deutlicher, und es gibt kaum Gründe anzunehmen, dass sich diese Trends in absehbarer Zeit ändern.

Unternehmen setzen Open Source ein, um sich in ihren jeweiligen Märkten besser zu behaupten. Gleichzeitig wächst das Bewusstsein dafür, dass sie diese Nutzung kontrollieren müssen, indem sie die damit verbundenen Risiken verwalten und mindern. Nur Software-Composition-Analysis-Tools, die die oben genannten zentralen Anforderungen erfüllen, können Unternehmen dabei helfen, dieses Ziel erfolgreich zu erreichen.

Umfassende Lösungen für Software Composition Analysis mit Snyk Open Source

Snyk wurde im Forrester-Wave™-Bericht zu Software Composition Analysis (SCA) für Q4 2024 als Leader und Kundenfavorit ausgezeichnet und erzielte Spitzenbewertungen in wichtigen Bereichen wie Vision, Innovation und Kundenservice. Forrester hob Snyks Engagement für den Erfolg seiner Kunden und die Strategie hervor, Sicherheit in den Entwicklungsprozess zu integrieren. Außerdem verwies Forrester auf fortschrittliche Funktionen für Risikoanalysen, Behebung und Auswertungen.

Snyk Open Source hilft Unternehmen wie Salesforce, Google und Facebook, die Anwendungssicherheit zu verbessern. Entwicklungsteams können damit Sicherheitslücken und Lizenzprobleme in ihren Open-Source-Abhängigkeiten und Containern automatisch finden, priorisieren und frühzeitig im gesamten SDLC beheben. Anders als andere Sicherheitslösungen auf dem Markt lässt sich Snyk Open Source entwicklerfreundlich und nahtlos in Entwicklungs-Workflows integrieren. Automatisierte Behebungen und umsetzbare Sicherheitseinblicke helfen Unternehmen, Risiken effizient zu erkennen und zu mindern.