Sichere Software
Vorteilhaft für den Profit
Fortsetzung des Artikels von Teil 2
Vorteile von SAST gegenüber DAST
ede Prüfmethodik hat ihre Stärken, aber viele Organisation rücken DAST und Penetrationstests übermäßig in den Mittelpunkt. SAST kann im Vergleich mit anderen Prüftechniken auf jeden Fall einige Pluspunkte für sich verbuchen.
-
Codeabdeckung
Der Umfang des geprüften Codes ist eine kritische Kennzahl für die Sicherheit von Software. Schließlich können sich Schwachstellen in jedem Teil der Codebasis befinden, und ungeprüfte Abschnitte können eine Applikation anfällig für Angriffe machen. SAST-Tools – und zwar speziell jene, die mit Musteranalyse-Regeln arbeiten – erzielen eine deutlich größere Codeabdeckung als DAST oder manuelle Prozesse. Denn sie haben Zugang zum Quellcode und den Eingabewerten der Applikation – darunter auch die verborgenen, nicht auf der Benutzeroberfläche exponierten Eingaben.
-
Grundursachen-Analyse
SAST-Tools kommen außerdem der effizienten Beseitigung von Sicherheitslücken zugute. Im Unterschied zu DAST identifiziert SAST ganz einfach die genaue Codezeile, in der der Fehler entsteht. Einbindungen in die von den Entwicklern benutzte IDE (Integrated Development Environment) können das Beheben der per SAST aufgedeckten Fehler ebenfalls beschleunigen.
-
Verbesserung der Fertigkeiten / Schulung
Gemäß des Reports »Secure DevOps: Fact or Fiction?« [5] vom SANS Institut ist der »Mangel an Personal und Fähigkeiten im Bereich der Anwendungssicherheit« das größte Hindernis bei der Implementierung sicherer DevOps.
Jobangebote+ passend zum Thema
Aus Bild 4 ist zudem die Schätzung des NIST ersichtlich, dass »das zahlenmäßige Verhältnis zwischen den existierenden Cybersecurity-Mitarbeitern und den Stellenangeboten in diesem Bereich etwa 2:3 beträgt«. Wird SAST von der IDE aus benutzt, erhalten Entwickler umgehende Rückmeldungen zu ihrem Code, was sie hinsichtlich der sicheren Programmierpraktiken unterstützt und schult.
-
Betriebliche Effizienz
Anders als DAST lässt sich die statische Analyse in einer sehr frühen Phase des Entwicklungszyklus einsetzen – zum Beispiel auch an einer einzigen Datei, die direkt aus der IDE des Entwicklers kommt.
Das frühzeitige Aufdecken von Fehlern im SDLC senkt die Kosten für deren Beseitigung enorm, denn so werden Fehler im Prinzip von vornherein vermieden, anstatt sie erst aufzufinden und dann zu beseitigen (Bild 5).
Fehler und Missverständnisse bei der Nutzung von SAST-Methoden
Obwohl SAST die umfassendste aller Prüfmethoden ist, kann sie die Sicherheitsteams doch mit Herausforderungen konfrontieren.
-
Verzögerter Einsatz von SAST-Methoden
Obwohl SAST-Tools in einer sehr frühen Phase des SDLC einsetzbar sind, warten manche Unternehmen mit der Analyse lieber bis in die Testphase. Natürlich ermöglicht das Analysieren einer vollständigeren Applikation interprozedurale Datenfluss-Analysen, aber das zeitliche Vorverlegen des SAST-Einsatzes und das Analysieren von Code direkt aus der IDE kann Schwachstellen, wie etwa Fehler bei der Validierung von Benutzereingaben, identifizieren. Sie bietet Entwicklern damit die Möglichkeit kleine Korrekturen vorzunehmen, bevor der Code für die Builds eingereicht wird.
-
Vermeidung des Einsatzes in agilen Umgebungen
SAST-Methoden haftet der Ruf an, dass sie zeitaufwändiger sind als DAST, was an dem umfassenden Ansatz für die Codeabdeckung und der Notwendigkeit liegt, ein Modell der Applikation zu erstellen. Dies kann Unternehmen zu der Annahme verleiten, SAST eigne sich nicht für zügige Entwicklungsmethoden. Klug vorgehende Entwicklungsteams aber nutzen SAST unmittelbar aus der IDE heraus, wodurch die Entwickler eine umgehende Rückmeldung erhalten. So lässt sich sicherstellen, dass Sicherheitslücken vermieden werden. Anschließend werden mit inkrementellen Analysen nur die Ergebnisse desjenigen Codes untersucht, der sich zwischen zwei Builds geändert hat.
-
»Verrauschte« (Noisy) Ergebnisse
Ältere SAST-Tools lieferten oft viele »informative« Ergebnisse, wie etwa weniger schwerwiegende Probleme im Zusammenhang mit einschlägigen Programmierstandards. Moderne Tools dagegen, wie sie beispielsweise Parasoft anbietet, ermöglichen den Anwendern eine Auswahl der anzuwendenden Regeln. Die Ergebnisse lassen sich zudem nach ihrem Schweregrad filtern: Regelverletzungen, die keine nähere Untersuchung rechtfertigen, bleiben dabei verborgen. Die Resultate lassen sich darüber hinaus auf der Basis weiterer Kontextinformationen filtern. Dabei kann es sich um Metadaten zum jeweiligen Projekt, das Alter des Codes sowie um die Angabe des für den Code verantwortlichen Entwicklers oder Teams handeln.
Auswahl und effektive Nutzung von SAST-Tools
Bei der Evaluierung eines jeden Tools besteht der erste Schritt darin, die eigene Umgebung zu verstehen. Zu berücksichtigen sind dabei die bereits vorhandenen Tools, die bestehenden Fähigkeiten und die Arbeitsabläufe.
Vor Ort oder in der Cloud
Der Großteil aller Software beinhaltet geistiges Eigentum, das für das jeweilige Unternehmen von großem Wert ist. Würde der Quellcode nach außen gelangen oder würden Sicherheitslücken in proprietärer Software öffentlich bekannt, könnte dadurch beträchtlicher Schaden entstehen. Darum suchen die meisten Unternehmen nach einer Lösung, die innerhalb der eigenen Umgebung installiert werden kann.
Agile, CI/CD oder Wasserfall
Die verwendete Entwicklungsmethodik kann Einfluss darauf haben, welche Lösungen eine Organisation einsetzt. In einem schnellen Entwicklungs- und Deployment-Modell kommt es auf straffe Analyse- und Rückkopplungszyklen an, und dementsprechend sollte nach Werkzeugen gesucht werden, die eine inkrementelle Analyse ermöglichen. So lassen sich schnelle Rückmeldungen über Schwachstellen in neu modifiziertem Code einholen, ohne dass dazu die gesamte Codebasis erneut untersucht werden muss.
Die Entwickler im Fokus
Erfolgreiche Deployments sind oftmals entwicklerorientiert und geben den Entwicklern die nötigen Tools und die Anleitung, um Sicherheit in die Software einzubauen. Besonders wichtig ist dies in Agile- und DevOps-Umgebungen, in denen es auf schnelle Rückmeldungen ankommt, um das Tempo hoch zu halten.
In der Regel resultiert dies in einem in die Entwickler-IDE(s) integrierten SAST-Tool, weil die IDE-Integration Sicherheitstests direkt aus der Arbeitsumgebung der Entwickler heraus ermöglicht – sei es auf der Datei- oder Projektebene oder einfach zum Evaluieren von neu geändertem Code.
Regelkonfiguration
Geht es um das Analysieren von Code auf Sicherheitsprobleme, kann ein Werkzeug allein niemals allen Unternehmen gerecht werden. Vielmehr kommt es darauf an, dass die Regeln bzw. die Regel-Checker genau auf die Probleme ausgerichtet sind, die für die jeweilige Applikation kritisch sind.
Unterliegt eine Anwendung beispielsweise dem Standard UL-2900, muss sichergestellt sein, dass die angewandten Regeln die Sicherheitslücken von CWE Top 25 und On the Cusp abdecken. Viele SAST-Tools behaupten, die die Top 25 zu unterstützen, aber dieser Support kann in Wirklichkeit auf bestimmte Anwendungsfälle beschränkt sein.
Unternehmen, die am Anfang von Sicherheitstests stehen, wollen die Regeln möglicherweise auf die häufigsten Sicherheitsprobleme wie Cross-Site-Scripting und SQL-Injektion eingrenzen. Neben den Standardregeln dürften Unternehmen, die mit individuellen Frameworks oder Programmierstandards arbeiten, nach Tools Ausschau halten, die kundenspezifische Regeln unterstützen.
Die meisten SAST-Werkzeuge klassifizieren die Sicherheitslücken nach ihrem Schweregrad und wenden dabei ein starres Schema an, das nicht für jede Anwendung passen muss. Bei einer Applikation ohne Internetanbindung ist die Angriffsoberfläche deutlich kleiner, und solche Schwachstellen, die zu Denial-of-Service-Attacken führen können, sind hier weit unkritischer als bei einer Anwendung mit Verbindung zum Internet. Es gilt also nach Tools zu suchen, die eine kontrollierte Regelkonfiguration zulassen.
Verringerung des Rauschens
Abgesehen von der Minimierung rein informativer Aspekte, können sich Unternehmen auch für eine niedrigere Sicherheitsstufe entscheiden und die Risiken aus bestimmten Sicherheitslücken einfach hinnehmen. In diesen Fällen wollen die Anwender ein bestimmtes Problem möglicherweise unterdrücken. Hier sollte darauf geachtet werden, dass ein SAST-Tool diese Fähigkeit bietet, dass die Unterdrückungen bei allen nachfolgenden Scans fortbestehen und dass sämtliche Ergebnisse für Compliance-Umgebungen wie UL-2900 dokumentiert werden.
Vermeiden ist besser als Aufdecken
Sicherheit von Anfang an in eine Anwendung einzubauen, ist deutlich effektiver und effizienter, als den Sicherheitsaspekt erst am Ende des Entwicklungsprozesses an einer fertigen Applikation nachzurüsten. Ebenso wenig wie eine Anwendung durch Testen mit Qualität versehen werden kann, ist dies beim Thema Sicherheit möglich.
Literatur
[1] 2018 Data Breach Investigations Report. Verizon, März 2018, https://enterprise.verizon.com/resources/reports/DBIR_2018_Report_execsummary.pdf.
[2] The State of Risk Based Security Management. Ponemon Institute, 25. Juni 2013.
[3] 2020 CWE Top 25 Most Dangerous Software Weaknesses. Common Weakness Enumeration (CWE), Website, https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
[4] OWASP Top Ten. Open Web Application Security Project (OWASP), Website, https://owasp.org/www-project-top-ten/.
[5] Bird, J. und Filkins, B.: 2018 Secure DevOps: Fact or Fiction? SANS Institute, Oktober 2018.
[6] New Data Show Demand for Cybersecurity Professionals Accelerating. National Institute of Standards and Technology (NIST), News, 7. November 2018, www.nist.gov/news-events/news/2018/11/new-data-show-demand-cybersecurity-professionals-accelerating.
Der Autor
Stefan Harms
ist seit 12 Jahren für Parasoft im Bereich der Kunden und Anwenderunterstützung in den USA und dem deutschsprachigem Raum tätig. In seiner Rolle als technischer Accountmanager ist er dafür verantwortlich, Bedarfe von Softwareentwicklungsprojekten den entsprechenden Testfunktionen der Parasoftanwendungen zuzuordnen. Besondere Erfahrungen und Kenntnisse hat er im Bereich der Konformität mit funktionalen Sicherheitsstandards, z.B. IEC 61508, ISO 26262 und IEC 62304.
stefan.harms@parasoft.com
- Vorteilhaft für den Profit
- Werkzeugkasten für Sicherheitsprüfungen
- Vorteile von SAST gegenüber DAST
Lesen Sie mehr zum Thema
