Statische Analyse zur Sicherheitstest-Toolbox hinzufügen

Autor / Redakteur: Arthur Hicken / Sebastian Gerstl

Security von Beginn an in Software einzubauen ist viel effektiver, als sie erst am Schluss in den Code zu zwängen. Hier gilt dasselbe Prinzip wie für die Qualität, die sich auch nicht in eine Anwendung hinein testen lässt. Am effizientesten funktioniert die Früherkennung von Sicherheitslücken mit SAST (Static Analysis Security Testing).

Firmen zum Thema

Statische Analyse im Entwickler-Werkzeugkasten: Mit SAST-Tools können Unternehmen Softwaresicherheit bereits in den frühen Phasen der Entwicklung berücksichtigen und den Softwareingenieuren die Tools und Anleitungen an die Hand geben, die sie zur Erstellung sicherer Software benötigen.
Statische Analyse im Entwickler-Werkzeugkasten: Mit SAST-Tools können Unternehmen Softwaresicherheit bereits in den frühen Phasen der Entwicklung berücksichtigen und den Softwareingenieuren die Tools und Anleitungen an die Hand geben, die sie zur Erstellung sicherer Software benötigen.
(Bild: © leowolfert-stock.adobe.com)

Durch die Digitalisierung und Vernetzung in allen Märkten sind Unternehmen gefordert, bei der Softwareentwicklung besonders auf die Security zu achten. Zum Identifizieren von Schwachstellen in Software und Systemen gibt es verschiedene Techniken, die eine sogenannte Sicherheits-Toolbox bilden. Diese setzt auf eine Kombination verschiedener Testwerkzeuge. Dazu zählen etwa:

  • SAST (Static Analysis Security Testing; Sicherheitstests mit statischer Analyse);
  • DAST (Dynamic Analysis Security Testing; Sicherheitstests mit dynamischer Analyse);
  • SCA (Source Code Analysis; Analyse der Quellenzusammensetzung);
  • Schwachstellen-Scanner; und
  • Penetrationstests.
Bildergalerie

Die Motivation, die Sicherheit durch automatisierte Tools zu verbessern, besteht darin, das Identifizieren und Beheben von Schwachstellen so früh wie möglich im Softwareentwicklungs-Lebenszyklus vorzuverlegen. Korrekturen und Beseitigung werden komplizierter, je näher das Release der Anwendung rückt. Bild 1 zeigt, wie Kosten für das Beheben von Schwachstellen mit dem Fortschreiten des Software Development Lifecycles (SDLC) dramatisch ansteigen.

Sicherheitstests mit statischer Analyse (SAST)

SAST-Tools funktionieren auch ohne ablaufende Anwendung, und können daher in einem frühen Stadium des Entwicklungszyklus eingesetzt werden, in dem die Kosten für die Behebung niedrig sind. Auf seiner grundlegendsten Ebene arbeitet SAST, indem der Quellcode analysiert und anhand einer Reihe von Regeln überprüft wird. Üblicherweise mit der Identifizierung von Schwachstellen verbunden, warnen SAST-Tools Entwickler frühzeitig vor schlechten Programmiermustern, die zu Exploits, Verstößen gegen sichere Codierungsrichtlinien oder mangelnder Konformität mit Entwicklungsstandards führen, was in instabiler oder unzuverlässiger Funktionalität endet.

Zur Identifizierung von Sicherheitsproblemen finden zwei primäre Arten von Analysen Anwendung: die Fluss-Analyse (Flow Analysis) und die Analyse von Mustern (Pattern Analysis).

Bei der Fluss-Analyse-Methode analysieren die Werkzeuge den Quellcode, um den zugrunde liegenden Kontrollfluss und den Datenfluss des Codes zu verstehen (vgl. Bild 2). Das Ergebnis ist eine Zwischendarstellung oder ein Modell der Anwendung. Indem die Tools Regeln - oder Checker - gegen dieses Modell ausführen, identifizieren sie Programmierfehler, die Sicherheitslücken erzeugen. Beispielsweise kann eine Regel in einer C- oder C++-Anwendung String-Kopien identifizieren und dann das Modell durchlaufen, um festzustellen, ob der Quellpuffer jemals größer als der Zielpuffer sein kann. Ist dies der Fall, könnte eine Pufferüberlaufschwachstelle entstehen.

Die zweite gängige Methode ist die Analyse von Mustern: Bestimmte sicherheitskritische Konstrukte im Code zu vermeiden, ist die Grundlage für moderne Software-Engineering-Standards wie AUTOSAR C++14, MISRA C 2012 und Joint Strike Fighter (JSF). Diese Standards vereiteln die Möglichkeit, unzuverlässigen Code falsch zu interpretieren, falsch zu verstehen oder falsch zu implementieren. Mit der Musteranalyse können Entwickler eine sicherere Teilmenge der Entwicklungssprache im Kontext der Sicherheit einsetzen und so die Verwendung von Codekonstrukten verbieten, die das Auftreten von Schwachstellen überhaupt erst ermöglichen. Manche Regeln können Fehler durch Syntaxprüfung identifizieren, ähnlich einer Rechtschreibprüfung in einem Textverarbeitungsprogramm. Manche moderne Tools können subtile Muster erkennen, die mit einer schlechten Codekonstruktion verbunden sind.

Vorteile des Einsatzes von Static Analysis Security Testing

Jede Testmethodik hat ihre Stärken. Viele Unternehmen konzentrieren sich zu sehr auf DAST und Penetrationstests. Aber der Einsatz von SAST bietet mehrere Vorteile gegenüber anderen Testtechniken

  • Code Coverage: Die Menge an Code, die getestet wird, ist eine kritische Größe für die Software-Sicherheit. In jedem Abschnitt der Codebasis sind Schwachstellen möglich, und ungetestete Abschnitte ermöglichen unter Umständen Angriffe auf die Anwendung. SAST-Tools, insbesondere solche, die Regeln zur Musteranalyse einsetzen, können eine viel höhere Codeabdeckung bieten als dynamische Techniken oder manuelle Prozesse. Sie haben Zugriff auf den Anwendungsquellcode und die Anwendungseingaben, einschließlich versteckter Eingaben, die in der Benutzeroberfläche nicht sichtbar sind.
  • Fehler-Ursachen-Analyse: SAST-Werkzeuge fördern das effiziente Beheben von Schwachstellen. Bei Sicherheitstests mit statischer Analyse lässt sich leicht die genaue Codezeile identifizieren, die den Fehler einführt. Die Integration in die IDE kann die Behebung von Fehlern beschleunigen, die SAST-Tools auffinden.
  • Fachkenntnisse verbessern: Wenn sie SAST-Tools aus der IDE verwenden, erhalten Entwickler sofortiges Feedback zu ihrem Code. Diese Daten bestärken und schulen sie in sicheren Kodierungspraktiken.
  • Operative Effizienz: Entwickler verwenden SAST zu Beginn des Entwicklungslebenszyklus, auch für einzelne Dateien direkt aus ihrer IDE heraus. Das frühzeitige Auffinden von Fehlern im SDLC senkt die Kosten für die Fehlerbehebung erheblich. Indem Fehler von vornherein vermieden werden, müssen die Entwickler diese später nicht mehr suchen und beheben.

Das Beste aus SAST herausholen

Bei SAST handelt es sich um eine umfassende Testmethodik, deren erfolgreiche Einführung einige anfängliche Anstrengung und Motivation erfordert.

Es empfiehlt sich stets, SAST so früh wie möglich einsetzen. Obwohl Teams die SAST-Tools schon früh im SDLC einsetzen können, gibt es Unternehmen, die die Analyse bis zur Testphase hinauszögern. Auch wenn die Analyse einer vollständigeren Anwendung eine prozedurübergreifende Datenflussanalyse ermöglicht, kann die zeitliche Vorverlegung mit SAST und die Code-Analyse direkt von der IDE aus Schwachstellen wie Fehler bei der Eingabevalidierung identifizieren. Sie ermöglicht zudem, dass Entwickler einfache Korrekturen ausführen, bevor sie Code für Builds einreichen. Dadurch lassen sich spätzyklische Änderungen für die Sicherheit vermeiden.

SAST lässt sich besonders gut mit Agile und CI/CD-Pipelines verwenden. Oft wird die SAST-Analyse missverstanden. Viele Teams halten sie für zeitaufwendig, weil sie den gesamten Quellcode des Projekts eingehend analysiert. Dies kann dazu führen, dass Unternehmen glauben, die SAST sei mit den Methoden der schnellen Entwicklung unvereinbar, was unbegründet ist. Denn in der integrierten Entwicklungsumgebung sind nahezu sofortige Ergebnisse von Sicherheitstests der statischen Analyse verfügbar, die sofortiges Feedback ermöglichen und die Vermeidung von Schwachstellen gewährleisten. Moderne SAST-Tools führen inkrementelle Analysen durch, um die Ergebnisse nur von dem Code anzuzeigen, der zwischen zwei verschiedenen Builds geändert wurde.

Es erlaubt einen Umgang mit gestörten (Noisy) Ergebnissen. Traditionelle Sicherheitstesttools für die statische Analyse enthalten oft viele informelle Ergebnisse und geringfügigere Probleme im Zusammenhang mit korrekten Programmierstandards. Bei modernen Tools, etwa von Parasoft, können Benutzer auswählen, welche Regeln/Checker benutzt werden sollen, und die Ergebnisse nach dem Schweregrad des Fehlers filtern, wobei diejenigen, die keine Untersuchung rechtfertigen, ausgeblendet werden.

Viele Sicherheitsstandards von OWASP, CWE, CERT u.ä. verfügen über Risikomodelle, die bei der Identifizierung der wichtigsten Schwachstellen helfen. Das eingesetzte SAST-Tool sollte diese Informationen nutzen, damit man sich auf das Wesentliche konzentrieren kann. Benutzer können die Ergebnisse eher auf der Grundlage anderer kontextbezogener Informationen wie Metadaten zum Projekt, Alter des Codes und für den Code verantwortlichen Entwickler oder Team filtern. Werkzeuge wie von Parasoft ermöglichen die Verarbeitung dieser Informationen mit künstlicher Intelligenz (KI) und maschinellem Lernen (ML), um die kritischsten Probleme weiter zu bestimmen.

Bei erfolgreichen SAST-Einführungen liegt der Fokus auf dem Entwickler.Sie bieten die Tools und Anleitungen, die Entwickler benötigen, um Sicherheit in die Software einzubauen. Dies ist wichtig in agilen und DevOps/DevSecOps-Umgebungen, in denen schnelles Feedback für die Aufrechterhaltung der Geschwindigkeit entscheidend ist. IDE-Integrationen ermöglichen Sicherheitstests direkt von der Arbeitsumgebung des Entwicklers aus - auf Dateiebene, auf Projektebene oder einfach zur Auswertung des geänderten Codes.

Diesen Beitrag lesen Sie auch in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 23/2020 (Download PDF)

Bei der Analyse von Software nach Sicherheitsfragen ist eine Einheitsgröße nicht für alle Unternehmen geeignet. Vielmehr ist es wichtig, dass die Regeln/Checker die jeweiligen Probleme abdecken, die für diese spezielle Anwendung kritisch sind. Unternehmen, die am Anfang der Sicherheitstests stehen, möchten die Regeln möglicherweise auf die häufigsten Sicherheitsprobleme wie Cross-Site-Scripting und SQL-Injection beschränken. Andere Unternehmen sind mit speziellen Sicherheitsanforderungen konfrontiert, die auf Vorschriften wie PCI DSS basieren. Man sollte also Lösungen suchen, die eine kontrollierte Regel-/ Checker-Konfiguration ermöglichen, die den eigenen Anforderungen entspricht anstelle von einer allgemeingültigen Konfiguration.

* Arthur Hicken ist Chief Software Evangelist bei Parasoft

(ID:46981306)

Über den Autor

 Arthur Hicken

Arthur Hicken

Parasoft® Deutschland GmbH