Wie AppSec-Testing mit Development-Prozessen mithält Software mit intelligenten Pipelines absichern

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

SYNOPSYS GmbH

Nicht alle Prozesse können mit agiler Software-Entwicklung mithalten. Vor allem das Application Security Testing ist oft zeitintensiv, lässt sich nicht vollständig automatisieren oder liefert in Summe so viele Ergebnisse, dass eine Priorisierung schwerfällt. Hier schaffen intelligente Pipelines Abhilfe.

Eines der größten Cybersecurity-Risiken sind Schwachstellen in der Anwendungsschicht. Die beste Firewall nützt nichts, wenn die Web-Anwendung selbst angreifbar ist. Viele Unternehmen haben deshalb in ihre AppSec-Programme investiert

Laut ESG-Bericht verwenden inzwischen 71 Prozent der befragten Unternehmen Application-Security- oder kurz AppSec-Tools für mehr als die Hälfte ihrer Softwareprojekte. Bemerkenswert ist, dass über zwei Drittel der Unternehmen bereits elf oder mehr automatisierte Application Security Testing (AST) Tools einsetzen, wie z.B. SAST, DAST, IAST, Fuzz Testing und Container Scanner.

Das liegt nicht zuletzt daran, dass die Tool-Hersteller ihre Produkte inzwischen „DevOps-ready“ gemacht haben und passende Integrationen in CI/CD-Pipelines unterstützen. Das verleitet dazu, AppSec-Scanner einfach in den Pipelines mitlaufen zu lassen – jedoch stellen sich dann häufig folgende Probleme ein:

• 1. Zu viele Ergebnisse: Entwickler werden nahezu mit Ergebnissen überhäuft. Dabei stellt nur ein kleiner Anteil ein so hohes Risiko dar, dass es sofort behoben werden muss. Die Richtlinien zur Priorisierung sind aber häufig in separaten Dokumenten formuliert und allzu oft nicht eindeutig.

• 2. Development-Pipelines werden „ausgebremst“: Build-Pipelines laufen nicht selten im Sekunden- bis Minuten-Takt. Scans mit AppSec-Tools benötigen oft mehrere Minuten bis hin zu Stunden.

• 3. Manuelle AppSec-Aktivitäten bleiben außen vor: Nicht alle AppSec-Aktivitäten lassen sich automatisieren, z.B. Architektur-Risikoanalysen, Bedrohungsmodelle und Pen-Tests. Dennoch sind diese ein wesentlicher Bestandteil der AppSec-Strategie.

Zur Bewältigung dieser Herausforderung bieten sich Intelligente Pipelines an, d.h. eine intelligente, zweckoptimierte Automatisierung und Orchestrierung der verschiedenen AppSec-Tools und -Aktivitäten. Verbunden mit der Konsolidierung der Scan-Ergebnisse ist hier eine neue Kategorie von Lösungen entstanden, die Gartner bereits 2019 als „Application Security Orchestration and Correlation“, kurz ASOC, betitelt hat.

Wie Pipelines intelligent werden

Die „Intelligenz“ liegt darin, zu entscheiden welche Tools zu welchem Zeitpunkt laufen müssen und was basierend auf den Ergebnissen zu tun ist. Statt also bei jedem Commit den gesamten Code mit sämtlichen AppSec-Tools zu scannen, wird dynamisch entschieden, welcher Scanner laufen muss und in welchem Umfang. Bei dieser Entscheidung können verschiedene Parameter in Betracht gezogen werden, z.B. der Umfang der tatsächlichen Code-Änderung, das Risikoprofil der Anwendung oder das Entwicklungsstadium der Software.

Wurde beispielsweise ein Font in einer CSS-Datei eines Web-Frontends geändert, ist sicherlich kein vollständiger DAST-Durchlauf nötig. Man kann also die geänderten Dateitypen in Betracht ziehen, die getroffene Softwarekomponente oder auch den Umfang der Code-Änderungen (Anzahl der geänderten Dateien). All diese Informationen liefert bereits die Versionsverwaltung, z.B. Git.

Ebenso sollte das Risikoprofil der Anwendung berücksichtigt werden. Web-Anwendungen, die vom Internet aus zugreifbar sind und sensible Daten verarbeiten, stellen ein größeres Sicherheitsrisiko dar als ein internes Tool zur Erzeugung von Dokumentationen. Derartige Risikoprofile gehen in der Regel aus einer vorausgegangenen Architektur-Risikoanalyse und dem Bedrohungsmodell hervor. Wie solche manuellen Aktivitäten in eine intelligente Pipeline eingebaut werden, betrachten wir etwas später in diesem Artikel.

Weiterhin sollte der Umfang der AppSec-Tests dem Entwicklungsstadium der Anwendung angemessen sein. Einzelne Commits eines Feature-Branches sollten hauptsächlich per statischer Codeanalyse auf im Code enthaltene Passwörter und API-Tokens, und das Einhalten von Codierungsrichtlinien, wie z.B. SEI CERT, geprüft werden, um eine schnelle Entwicklung zu unterstützen.

Später dann, beim Merge Request in den Hauptzweig, sollten umfangreichere Scans dazukommen, beispielweise tiefergehende Datenflussanalysen, die dann Cross-Site-Scripting oder SQL-Injections aufdecken. Hier kann eine längere Laufzeit in Kauf genommen werden, da solche Merge Requests ohnehin meist nach dem Vier-Augen-Prinzip genehmigt werden müssen.

Entkoppeln der Security-Pipeline

Eine feste Verzahnung von AppSec- und Entwicklungs-Pipeline kann schnell zu führen, dass die Entwicklung ausgebremst oder anderweitig beeinträchtigt wird. Es ist daher sinnvoll, eine separate AppSec-Pipeline zu erstellen, die dann über einfache APIs von der Entwicklungs-Pipeline aus ansprechbar ist. Somit kann man flexibel eine synchrone oder asynchrone Anbindung wählen.

Bei einer synchronen Anbindung wartet die Entwicklungs-Pipeline auf die Resultate der AppSec-Pipeline, während bei einer asynchronen Anbindung die jeweiligen Security-Jobs nur angestoßen werden und dann zeitlich unabhängig von der Entwicklungs-Pipeline beispielsweise entsprechende Tickets in Jira erstellen.

Ein weiterer Vorteil einer separaten AppSec-Pipeline ist, dass einfache manuelle Aktivitäten („Out-of-Band“) eingebunden werden können. Basierend auf einer gecodeten Sicherheitsrichtlinie können manuelle Aktivitäten wie Penetrationstests oder die Aktualisierung von Bedrohungsmodellen angestoßen werden, indem z.B. ein entsprechendes Ticket in Jira oder GitHub erstellt wird. Diese Aktivitäten können somit mit bestimmten Ereignissen im Software-Entwicklungszyklus verknüpft werden, anstatt auf einem starren Zeitraster zu laufen.

Ein Update des Bedrohungsmodells kann so durch Änderungen des API-Codes getriggert werden, anstatt alle sechs Monate. Somit kann der vollständige Security-Workflow automatisiert werden, ohne dass manuelle Aktivitäten „außen vor“ bleiben. Das verhindert einen falschen Fokus bei automatisierbaren Tests und erleichtert darüber hinaus die Überwachung des AppSec-Prozesses.

Sicherheitsrichtlinien coden

Das Kernstück der Intelligenten Pipelines sind individuelle Richtlinien („Policies“). Diese legen zum einen fest, wann welche AppSec-Aktivität ausgeführt wird, also im einfachsten Fall ein automatisierter Test durchgeführt wird. Zum anderen beschreiben die Richtlinien, wie mit den kombinierten Ergebnissen zu verfahren ist – z.B. ob der Code in den Master-Branch integriert werden oder die Web-Applikation live gehen darf.

Die Beschreibung der Richtlinien erfolgt in einer Konfigurationsdatei („Policy-as-Code“). Genau wie bei anderen „as-Code“-Methoden wird dadurch Eindeutigkeit, Reproduzierbarkeit und Automatisierung ermöglicht beziehungsweise verbessert. Einfache Richtlinien können nach dem „If This Then That“-Prinzip erstellt werden.

Beispielsweise lässt sich auf diesem Weg ein SCA-Scan (Software Composition Analysis) dann auslösen, wenn sich entweder die Projektdatei ändert (package.json, go.mod, pom.xml, usw.) oder neue Dateien oder Verzeichnisse dazugekommen sind – nicht aber, wenn lediglich existierende Quellcode-Dateien geändert wurden.

Nach dem gleichen Prinzip lassen sich auch entsprechende Aktionen aus dem Ergebnis einer oder mehrere Scans ableiten. Im einfachsten Fall ist es möglich, die Pipeline als „pass“ oder „fail“ zu markieren, aber genauso kann eine Benachrichtigung per Slack ausgelöst oder dynamisch weitere Scans angestoßen werden.

Hierbei können nicht nur die Ergebnisse des aktuellen Scans berücksichtigt, sondern auch andere Tracking-Systeme abgefragt werden – etwa um festzustellen, ob eine bestimmte Schwachstelle bereits bei vorangegangenen Scans entdeckt wurde und wie lange diese bereits offen ist. So lassen sich typische Richtlinien wie „Alle bekannten Schwachstellen mit einem CVSS-Score größer 7 müssen innerhalb von 30 Tagen behoben werden“ implementieren.

Bessere Zusammenarbeit

Ein großer Vorteil von „Policy-as-Code“ ist, dass sie die Zusammenarbeit von Entwicklungs-, AppSec- und DevOps-Teams (DevSecOps) fördern. Das Security-Team kann die Richtlinien entwerfen sowie formulieren und das DevOps-Team kann sie gemäß „Policy-as-Code“ implementieren (ohne diese im Detail verstehen zu müssen).

Die Entwickler können sich derweil auf die Art von Problemen konzentrieren, die die größten Risiken bergen – anstatt hunderte von Resultaten verschiedener Tools mit den Security-Richtlinien zu vergleichen. Damit lassen sich die unterschiedlichen Anforderungen der einzelnen Stakeholder besser unter einen Hut bekommen, um dem gemeinsamen Ziel – sichere Software – etwas näher zu kommen.

Alles auf einen Blick

Neben der Orchestrierung der verschiedenen AppSec-Aktivitäten ist eine wichtige Aufgabe von ASOC-Lösungen die Aufbereitung der Ergebnisse verschiedener Tools. Dazu gehört vor allem eine einheitliche Darstellung der Schwachstellen, aber auch – falls möglich – die Eliminierung von doppelten Ergebnissen und die Korrelation von ähnlichen. Hierbei ist es wichtig, dass möglichst viele verschiedene AppSec-Tools von kommerziellen Herstellern, aber auch Open-Source-Lösungen unterstützt werden.

Während sich innerhalb der einzelnen AppSec-Disziplinen hier langsam (de-facto) Standards etablieren (wie das SARIF-Format für SAST-Ergebnisse oder etwa SWID, SPDX oder CycloneDX für SCA), ist der Markt der verfügbaren Aggregator-Tools aktuell recht überschaubar. Bei größeren Unternehmen finden sich oft selbstgebaute Lösungen, die aber auf die jeweils eingesetzten Tools zugeschnitten sind. Bei einem Wechsel eines AppSec-Tools entsteht dann zusätzlicher Integrationsaufwand.

Die Zukunft: Plattformen und APIs statt Tools und UIs?

Bei der steigenden Anzahl von eingesetzten AppSec-Tools und -Scannern ist zu erwarten, dass die Bedeutung von Lösungen für die Orchestrierung und das Ergebnismanagement für den AppSec-Bereich steigen wird. Die Hersteller von AppSec-Scannern bieten bereits heute Schnittstellen zur Steuerung und zum Ergebnisabruf an, um eine Integration in CI/CD-Pipelines zu unterstützen.

Viele Scanner unterstützen im Übrigen bereits mehrere Scan-Modi – von der schnellen Überprüfung des geänderten Codes bis hin zur vollständigen Datenflussanalyse der gesamten Codebasis. Damit sind Trade-Offs zwischen Laufzeit und Genauigkeit möglich, wie sie dann in Intelligenten Pipelines implementiert werden können.

Darüber ist zu erwarten, dass die „Intelligenz“ sich von „Wenn-Dann“-Logik in Richtung Machine Learning entwickeln wird. Das heißt, das System lernt die individuellen Risiken und kann dementsprechend AppSec-Aktivitäten gezielt vorschlagen.

Fazit

Ob mit oder ohne Orchestrierungs-Tools – wer seine Software sicherer machen will, muss zwangsläufig Überlegungen dazu anstellen, welche AppSec-Aktivitäten zu welchem Zeitpunkt Sinn machen. Oder anders ausgedrückt: der richtige Scan zur richtigen Zeit.

Weiterhin sollte festgelegt werden, wie mit den Resultaten zu verfahren ist, bevor man einen Scan anordnet oder gar automatisiert. Dazu muss man verstehen, welches die größten Risiken sind, gegen die man die Software absichern muss. Intelligente Pipelines helfen bei der Umsetzung und vor allem der Automatisierung der AppSec-Strategie. Eine entsprechende Strategie ist Voraussetzung.

Aber auch (oder gerade) ohne klare Strategie macht es Sinn, sich mit der Architektur eine Intelligenten Pipeline zu beschäftigen, da dies zum einen eine Zusammenarbeit von Entwicklungs-, AppSec- und DevOps-Teams fördert und zum anderen die richtigen Fragen aufwirft, die zu einer erfolgreichen AppSec-Strategie führen.

* Gunnar Braun ist Security Engineer bei Synopsys und unterstützt große Unternehmen bei der Erstellung von sicherer Software. Zuvor war er in verschiedenen Engineering- und Managementfunkionen im Bereich Embedded Systems, Simulation und Compilation bei CoWare tätig, einem Technologie-StartUp, das 2010 von Synopsys übernommen wurde. Er besitzt einen Diplomabschluss der RWTH Aachen.

(ID:47888172)