Sicherheit bei der Software-Entwicklung
Welcher Standard ist der Beste?
Fortsetzung des Artikels von Teil 1
Auswahl und Umsetzen eines Standards
Die vielen Sicherheits- und Datenschutzrichtlinien erschweren die Entscheidung, welches die Richtige für ein zu entwickelndes Produkt ist. Sofern es für einen bestimmten Markt keine etablierten Richtlinien gibt, beginnt ein Entwickler am besten mit einer einfach anwendbaren Richtlinie. Sie sollte problemlos mit der statischen Analyse einsetzbar sein und großen Einfluss auf die Anwendungssicherheit haben. Oftmals versuchen Softwareteams einen Codierstandard zu strikt durchzusetzen und sehen sich dann von den Ergebnissen und dem Arbeitsaufwand überfordert. Entscheidend ist ein pragmatischer Ansatz.
Abdeckung mit statischer Analyse
Der Schlüssel zum Erfolg ist die Automatisierung, denn die Richtlinien sind auf einen großen Code-Umfang anwendbar und die Abhängigkeit von Peer Reviews verringert sich. Je mehr ein Tool leistet, umso weniger Zeit ist aufzuwenden und umso stimmiger, objektiver und reproduzierbarer (wichtig für Audits) sind die Resultate. Außerdem sollte das statische Analyse-Tool möglichst viele Richtlinien des gewählten Codierstandards abdecken.
Feinabstimmen der Konfiguration
Auf die Anforderungen des jeweiligen Projekts sind die ausgewählten Checker und die Konfiguration des statischen Analyse-Tools abzustimmen. Ein Entwickler sollte die Tools zudem korrekt in den täglichen Arbeitsablauf einbinden, damit sie einfach zugänglich und problemlos nutzbar sind. Die Ergebnisse müssen dort zu finden sein, wo sie die Entwickler benötigen – also in der IDE (Integrated Development Environment, Integrierte Entwicklungsumgebung) und nicht in ihrer E-Mail oder ihrem Browser. Außerdem muss die Analyse sowohl in der IDE als auch im Rahmen der Build- und Continuous Integration/Continuous Delivery (CI/CD)-Pipelines erfolgen können.
Einsatz präventiver Checker
Einige Herausforderungen, wie etwa SQL-Injektionen, lassen sich bereits vorab mit bestimmten Konfigurationen abwenden. Es ist hilfreich, dazu sogenannte „Zweck-Checker“ zu aktivieren, die beim Vermeiden ganzer Klassen folgenreicher Sicherheitsprobleme helfen. Ein Entwickler sollte sich die Mühe machen, Sicherheitsprobleme dieser Art sofort beim Aufdecken zu vermeiden – vorbeugen ist noch besser als frühzeitiges Erkennen.
So klein anfangen wie nötig
Bei großen Code-Basen kann die statische Analyse eine große Zahl von Warnmeldungen generieren, was das Entwicklungsteam überfordern und gelegentlich sogar vor dem Nutzen der Tools zurückschrecken lässt. Ein Sortieren und Ausfiltern der gravierendsten Schwachstellen ist ebenso sinnvoll wie ein Eingrenzen des Umfangs der Analyse. Ein Anwender kann beispielsweise die statische Analyse auf neu hinzugekommenen Code beschränken oder existierende Warnungen ausfiltern, um neue Warnmeldungen während dem Entwickeln sofort bei ihrem Erscheinen abzuarbeiten. Klein anzufangen und den Umfang der Analyse Schritt für Schritt zu vergrößern ist besser als möglicherweise überfordert zu sein und zu scheitern.
Jobangebote+ passend zum Thema
Eigenschaften von statischen Analyse-Tools
Statische Analyse-Tools sind nicht alle gleich, und sie sind mehr als nur der reine Analysetreiber. Es kommt nicht nur auf die Qualität und Tiefe der Analyse an, sondern ebenso auf das Speichern, das Auswerten der Ergebnisse und die Integration mit anderen Entwicklungs-Tools wie etwa IDEs und CI/CD-Pipeline-Tools (Bild 4).
Unterstützung für den Betrieb in der IDE
Die statische Analyse funktioniert am besten, wenn sie Regelverletzungen, Bugs und Sicherheitsschwachstellen sofort beim Schreiben des Codes abfängt. Ebenso müssen die Entwickler Zugang zu den Ergebnissen der Analyse des kompletten Builds haben.
Unterstützung für den Betrieb auf Build-Servern und CI-Systemen
Genauso wichtig ist die statische Analyse auf der Projektebene, da die Analyse hier den Quellcode komplett oder zumindest zum Großteil erfasst. Komplexe Analysen wie die Datenflussanalyse funktionieren in dem Modus am besten. Überdies sollte die Analyse in eine bestehende Continuous-Integration- und Deployment-Toolchain sowie den zugehörigen Workflow integriert sein. Die Tools müssen darüber hinaus die einzelnen Analysen für jede Datei und jeden Build verfolgen. Zusammen mit dem Betrieb in der IDE erlaubt das, das Implementieren einer Vorgehensweise nach dem Prinzip »Vertrauen ist gut, Kontrolle ist besser«. Sie ist am effektivsten und beeinflusst den eigenen Arbeitsablauf nicht so negativ, wie es einige strikt abgegrenzte CI-Security-Implementierungen versuchen.
Zentralisierte Konfigurationskontrolle
Eine zentrale Kontrolle der Test- und Analysekonfiguration ist nicht nur entscheidend für den Einsatz der Standards bei allen Entwicklern im Team. Es stellt ebenso die beste Möglichkeit dar, Einstellungen feinabzustimmen und einheitlich im gesamten Team vorzunehmen. Ein zentralisiertes System setzt stets denselben Standard durch, damit alle Teammitglieder sicher mit dem richtigen Standard arbeiten.
Zentralisieren von Reporting, Audit und Analytik
Zu den kritischen Aspekten gehören die Reporting- und Analytikfunktionen der statischen Analyse-Tools. Projekte erzeugen große Datenmengen, die mit jedem Build weiter wachsen. Entscheidend für die erfolgreiche Nutzung und Rentabilität eines statischen AnalyseTools ist der Umgang mit den Daten. Genau auf jeden Codierstandard und jede Sicherheitsrichtlinie abgestimmte Dashboards, Reports und Konformität sind von kritischer Bedeutung. Analysen, die sich auf Risikomodelle stützen und beim Priorisieren helfen, verkleinern ganz erheblich den Berg an Regelverstößen, die ein Tool ohne weitere Vorverarbeitung liefert (Bild 5).
Lückenlose Checker-Palette
Eine umfassende Auswahl an Checkern ist entscheidend, um unterschiedliche Anwendungsfälle für die statische Analyse zu unterstützen. Benötigt werden solche, die Fehler und Schwachstellen detektieren, präventive Checker und auch solche für Code, der beim ersten Hinsehen nicht korrekt aussieht und ein näheres Betrachten erfordert. Ebenso wichtig ist die Unterstützung komplexer, fortschrittlicher Checker mithilfe der Datenflussanalyse, sie hilft beim Aufdecken schwierig zu findender Fehler. Erforderlich sind darüber hinaus jene, die Probleme von vornherein vermeiden, indem beispielsweise das Validieren von Eingangsdaten erzwungen wird, anstatt zu versuchen, alle möglichen Arten zum Verfälschen von Daten aufzudecken. Ein Entwickler benötigt nicht zuletzt eine umfassende Palette an präventiven Checkern, beispielsweise für die als Industriestandard etablierten Sicherheitsrichtlinien wie CERT, MISRA, OWASP und CWE.
Standards führen zum Erfolg
Ein solides Software-Entwicklungskonzept soll qualitativ hochwertigen Code entwickeln, der den etablierten Best Practices entspricht. Für bestimmte Produkte oder Märkte wird die Frage, welche Best Practices zu befolgen sind, mit bereits bestehenden Industriestandards beantwortet. Fehlt es jedoch an solchen Standards, ist die Entscheidung für das richtige Konzept schwer.
Damit Entwickler sicheren und privaten Code »by design« entwickeln können, erhalten sie bei modernen Tool-Anbietern wie Parasoft Vorgaben, die das Anwenden bestehender Standards und Richtlinien erläutern. Enthalten ist die komplette Unterstützung für wichtige Standards mit Hilfe verschiedener Methoden und Checker-Typen, die sowohl Frühwarnung als auch Vermeidung ermöglichen. Eine breite Unterstützung für die Security-Standards AUTOSAR C++14, CWE Top 25 und »On the Cusp« bieten die Testanwendungen von Parasoft für C/C++, Java und .NET.
Ein Optimieren des Auditverfahrens ermöglicht das detaillierte Konformitäts-Reporting über web-basierte, spezifische Dashboards mit Checkern für verschiedene Standards (unter anderem OWASP, CWE, AUTOSAR C, CERT C, MISRA C). Sie liefern einerseits einen schnellen Gesamtüberblick über den Projektstatus, genauso wie zu Regelverletzungen und mehr. Zudem erlaubt das spezielle, auf CWE ausgerichtete Modell von Parasoft Anwendern, die Ergebnisse der statischen
Analyse mit jenen von CWE zu verknüpfen, ohne dass mühsame Zuordnungen oder zusätzliche Arbeiten erforderlich sind. So lässt sich schneller nachvollziehen, wie die Konformität erzielt wurde, außerdem sind die Auditreports als PDF-Dateien verfügbar.
Der Autor
Mark Lambert besitzt einen Bachelor- und Masterabschluss in Informatik der Manchester University und fungiert als Redner auf zahlreichen Veranstaltungen wie JavaOne oder Software Test&Performance. Er ist seit 2004 bei Parasoft und für die Auswahl der Global-2000-Kunden zuständig. Zunächst war Lambert für das Implementieren spezifischer Technologien zuständig. Heute unterstützt er Initiativen zum Verbessern des Software-Development-Lifecycle-Prozesses.
- Welcher Standard ist der Beste?
- Auswahl und Umsetzen eines Standards
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Embedded-Systeme schützen
Sicherheit beginnt im Kopf
Software
Was ist neu bei Ubuntu 20.04 LTS?
Cyber-Sicherheit und IoT
Wie passt das zusammen?
Software Engineering
Debug Engine von PLS unterstützt SAFERTOS
Neue Geschäftsstrategie
AIoT treibt Edge-Computing voran
Software Engineering
Kostenlose Tracealyzer-Version verfügbar
Software-Prüfläufe beschleunigen
Auf die Reihung kommt es an
Debugging von RTOS-Software-Systemen
Schluss mit dem Rätselraten
Modul für Azure Sphere entwickelt
3 Fragen an Felix Adamczyk
