SAST und SCA-Tests: Wo liegen die Unterschiede? Kann man sie kombinieren?

Ganz gleich, wie penibel Sie die neuesten Empfehlungen zur Programmiersicherheit auch befolgen – im Produktionscode findet sich immer mindestens eine Sicherheitslücke. Schließlich arbeiten auch in der Entwicklung nur Menschen. Und die machen angesichts der unzähligen und immer neuen Schwachstellen und des wachsenden Release-Drucks Fehler.

Vor diesem Hintergrund sollen hier Static Application Security Testing (SAST) und Software Composition Analysis (SCA) mit Blick auf die dahinterstehenden Konzepte, ihre Vorteile und ihre Unterschiede vorgestellt werden. Des Weiteren werden Einsatz- und Kombinationsszenarien für SAST und SCA zur Schaffung absolut sicherer Anwendungen beschrieben.

Warum SAST?

SAST bietet zahlreiche Vorteile. Der größte davon ist die Möglichkeit, Sicherheitslücken zu erkennen und ihren genauen Ursprung einschließlich Dateiname und Zeilennummer zu bestimmen. Zudem wird bei SAST der Schweregrad der erkannten Schwachstellen und eine kurze Beschreibung angegeben. Und diese Genauigkeit ist ein echter Vorteil, da die Problemsuche zu den zeitaufwendigsten Arbeitsschritten in der Entwicklung zählt.

Warum SCA?

Aktuelle Anwendungen basieren immer öfter auf Open-Source-Code. Schätzungen zufolge bestehen sie sogar zu 80 bis 90 % aus Open-Source-Code. Und dessen allgemeine Verfügbarkeit führt dazu, dass Anwendungen heute schneller denn je entwickelt werden können.

Doch Anwendungen nutzen nicht nur eigenen Code. Vielmehr besteht eine der größten Herausforderungen bei der Sicherung der Codebasis aktuell darin, dass die Anwendungen aus mehreren Bausteinen bestehen, die allesamt gesichert werden wollen, um das Risiko effektiv einzuhegen.

SAST und SCA

Nach dieser kurzen Einführung in SAST und SCA sollen hier die Besonderheiten beider Ansätze vorgestellt werden, damit Sie besser einschätzen können, welcher sich für Ihr Unternehmen am besten eignet.

SAST: Alleinstellungsmerkmale

Wie bereits gesagt wurde, ist die statische Herangehensweise einer der größten Vorteile von SAST. Denn so müssen statt der kompletten Anwendung nur einzelne Codezeilen ausgeführt werden. Zudem kann SAST bereits frühzeitig in der Entwicklung angewendet werden. Und das sind die Besonderheiten von SAST:

• Anwendungen werden von „innen nach außen“ analysiert.

• Die Ausführung ist in sämtlichen Phasen des SDLC möglich.

• Meist ist ein für das Tool verständliches Build-Model erforderlich.

• Analysen basieren auf einem Regelsatz.

• Es gibt mehrere Analysearten für verschiedene Ergebniskategorien.

Fünf SAST-Analyseverfahren

SCA: Alleinstellungsmerkmale

Wie bereits erwähnt wurde, beruhen SCA-Verfahren und -Tools auf quelloffener Software. Und das sind ihre Besonderheiten:

• Erkennung von Open-Source-Komponenten: Es erfolgt eine Analyse der Anwendungen und ihrer Open-Source-Abhängigkeiten. Dabei kann es sich um unmittelbare oder aber transitive Abhängigkeiten handeln. Studien von Snyk zufolge werden 80 % aller Schwachstellen durch transitive Abhängigkeiten verursacht. Diese Funktion ist also für die Risikominderung besonders wichtig. 

• Lizenzmanagement: Die verwendeten Open-Source-Lizenzen werden erkannt. Das hilft dabei, Rechtsrisiken zu begrenzen, die sich aus deren Nutzung ergeben. Mithilfe von SCA-Tools lassen sich zudem bereits früh im Entwicklungsprozess Richtlinien aufstellen, um derartige Rechtsrisiken zu begrenzen.

• Sicherheitslücken: Bei SCA erfolgt ein Abgleich mit Schwachstellen-Datenbanken, um Sicherheitslücken in Open-Source-Abhängigkeiten zu erkennen. Einige SCA-Tools geben zudem Empfehlungen, die deren Beseitigung vereinfachen. So werden bei Snyk beispielsweise umfassende kontextbezogene Vorbeugemaßnahmen und Sicherheitspatches empfohlen, mit denen sich etwaige Sicherheitslücken schnell schließen lassen.

• Steuerung und Kontrolle: Sicherheits- und Lizenzrichtlinien werden in den einzelnen Phasen der Softwareentwicklung automatisch angewendet. SCA-Tools erlauben meist die Einbindung von Open-Source-Sicherheitstests in CI/CD-Prozesse, damit Schwachstellen nicht einfach weitergereicht werden.

Berichterstattung und Analyse: Mit den Software-BOMs (Bills of Material, Materiallisten) erhalten Sie genaue Aufstellungen zu sämtlichen Abhängigkeiten im Code und ihrer Verwendung. Die Berichte erlauben eine genaue Einschätzung des Sicherheitsrisikos und können an andere Akteure weitergegeben werden, um die Abstimmung zu optimieren.

SCA in der Anwendungssicherheit

SCA ist an sich nichts Neues. Die wachsende Bedeutung von Open Source in den letzten Jahren hat aber dafür gesorgt, dass sich das Verfahren zu einem wichtigen Eckpfeiler der Anwendungssicherheit entwickelt hat. Dementsprechend haben auch SCA-Tools an Bedeutung gewonnen – doch die sind keineswegs alle gleich. Aufgrund aktueller Gepflogenheiten in der Softwareentwicklung wie DevSecOps muss die SCA besonders entwicklerfreundlich sein. Die Entwickler verlangen benutzerfreundliche Tools und die Sicherheitsabteilungen müssen in der Lage sein, ihren Teams Orientierung zu geben. Abgesehen davon können auch Compliance-Funktionen sowie KI/ML-Funktionen wichtige Vorteile sein.

SAST und SCA: Anwendungssicherheit in Kombination

Der direkte Vergleich beider Verfahren zeigt, dass beide ihre Berechtigung haben und eingebunden werden sollten. Während SAST vor allem den Code in den Blick nimmt, lassen sich mit SCA insbesondere die verwendete Open-Source-Software und vorhandene Abhängigkeiten analysieren. Durch eine Kombination beider Ansätze können Unternehmen somit Sicherheitsmängel bereits frühzeitig im Entwicklungsprozess erkennen.

Außerdem lassen sich auf diese Weise noch mehr Schwachstellen und Angriffspunkte identifizieren und die Vorteile dynamischer Sicherheitstests sowohl von SAST als auch von SCA ausnutzen. Und nicht zuletzt lässt sich so nicht nur der selbst produzierte, sondern auch der verwendete Open-Source-Code abdecken.