Illustration: Absmeier, Birgl

Anwendungssicherheit etabliert sich immer mehr. Das ist gut so, denn das heißt, Sicherheitstests werden zu einem festen Bestandteil des Softwareentwicklungslebenszyklus (SDLC).

Inzwischen sind automatisierte Sicherheitstests deutlich schneller und ausgefeilter. Alles mit dem Ziel, Entwickler nicht auszubremsen oder mit einer Flut von trivialen Ergebnissen oder Fehlalarmen zu belasten. Aber so gut und notwendig AppSec-Testtools auch sind, es reicht bei weitem nicht aus, sie einfach zu kaufen und einzusetzen. Man muss bei der Kaufentscheidung die richtige Auswahl treffen und sie anschließend richtig konfigurieren. Nur dann tragen sie dazu bei, Sicherheit in den SDLC einzubauen, ohne ihn zu behindern. Neben der Sicherheitsstrategie braucht es einen dedizierten Plan, der auch umgesetzt wird. Und Entwickler, die über ausreichende Kompetenzen verfügen, Vertrauen in ihre Software zu integrieren – ein Konzept, das als ganzheitliche AppSec bekannt ist.

Zu diesem Thema haben wir mit Boris Cipot, Senior Sales Engineer bei Synopsys, gesprochen.

Beginnen wir bei den Grundlagen. Was verstehen Sie unter ganzheitlicher AppSec und warum ist sie so wichtig? 

Lassen Sie uns dazu am besten einen Schritt zurücktreten und einen Blick auf die Geschichte der AppSec werfen. In den späten 90er und frühen 2000er Jahren bestand das Testen von Anwendungssicherheit im SDLC darin, Code zu schreiben und die App in die Produktion zu überführen – mit minimalen (wenn überhaupt) Tests während der Produktion. Das Aufkommen von statischen Tests für die Anwendungssicherheit (SAST) änderte die Situation allmählich. Mit dieser neuen Strategie fing man an, den Quellcode zu testen und Sicherheitsaspekte »shift left« in den Entwicklungsprozess zu verlagern, d. h. an einen Zeitpunkt, bevor die Anwendung in Produktion geht. Dieses Konzept, den Code sofort zu überprüfen, führte zu der Erkenntnis, dass sich mit »shift left« im SDLC viel Zeit und Geld sparen lässt. Schließlich musste man nichts mehr ändern, wenn der Code schon in Produktion gegangen war – ein ebenso teurer wie zeitintensiver Prozess.

Heutzutage ist die Anwendungsentwicklung allerdings nicht mehr ganz so einfach. Wir verlassen uns beispielsweise in hohem Maße auf Open-Source-Komponenten. Laut dem 2022 Open Source Security and Risk Analysis (OSSRA)-Bericht lag 78 % der 2.409 geprüften Codebasen Open Source zugrunde.

Hinzu kommt, dass wir heute viele dieser Anwendungen in öffentlichen, privaten oder hybriden Cloud-Umgebungen bereitstellen. Etwas, das es Ende der 90er oder Anfang der 2000er Jahre noch nicht gab. Darüber hinaus gelangen Schwachstellen in praktisch jeder Phase in den SDLC.

Nicht nur, wenn Entwickler Code schreiben, sondern auch, wenn Open-Source-Komponenten eingeführt und Konfigurationsdateien geschrieben werden. Oder wenn Teams an der Containerisierung von Anwendungen arbeiten, um sie in der Cloud bereitzustellen und so weiter. Der springende Punkt ist, dass Schwachstellen auf unterschiedliche Weise und an verschiedenen Stellen eingeführt werden. Und genau das erfordert einen ganzheitlichen Ansatz bei den Sicherheitstests.

»Shift everywhere« ist aktuell fast schon ein Modewort. Können Sie etwas genauer erläutern, was eigentlich damit gemeint ist?

Neben SAST, das sich in den letzten etwa 15 Jahren zu einer tragenden Säule entwickelt hat, müssen wir jetzt auch den Open-Source-Aspekt berücksichtigen. Die Software Composition Analysis (SCA) erkennt Open-Source-Schwachstellen im Code. Beim Dynamic Application Security Testing (DAST) wird der Code einer laufenden Anwendung untersucht, ohne dass die internen Interaktionen oder das Design der Anwendung auf Systemebene bekannt sind und ohne Zugriff oder Einblick in das Quellprogramm. Dazu sollten Penetrationstests kommen, bevor eine Anwendung in der Cloud bereitgestellt wird, Konfigurationsdateien und Containerkennzahlen überprüft werden. Die Liste ließe sich beliebig fortsetzen.

Wie Sie sehen, sind wir an einem Punkt angelangt, an dem wir die Sicherheit nicht per se »nach links« verlagern, sondern über den gesamten SDLC hinweg testen müssen. Wir verschieben die Sicherheit »überall hin«. Denn genau dort sind die Schwachstellen – überall!

Die richtigen Tests zur richtigen Zeit durchzuführen, also sobald das jeweilige Artefakt verfügbar ist, spielt eine entscheidende Rolle. Bei dem jeweiligen Artefakt kann es sich um Code, eine Konfigurationsdatei, Skripte, APIs oder Container-Images handeln. Das Testen in der richtigen Breite und Tiefe und so schnell wie möglich, verschiebt die Sicherheit also tatsächlich in einem »shift everywhere«.

Wichtig ist die Frage, wie sich Sicherheitstests so durchführen lassen, dass Entwicklungsteams sie nicht ignorieren. Und das ist eine gute Frage! Wenn man die Sicherheit aus der DevOps-Perspektive betrachtet, ist Geschwindigkeit ausschlaggebend. Als DevOps-Ingenieur oder Entwickler liegt ihr Hauptaugenmerk darauf, neuen Code mit differenzierenden Funktionen so schnell und so oft wie möglich herauszubringen. Alles, was dieses Tempo bremst, führt zu Reibungsverlusten im SDLC. In der Regel möchte ein Entwickler das natürlich vermeiden, sodass automatisierte Tests, die schnell, zur richtigen Zeit und in der richtigen Tiefe ablaufen, nur minimale Reibung verursachen.

Allerdings lassen sich nicht alle Softwareprobleme mit automatisierten Tests erkennen. Dazu zählen beispielsweise Fehler in der Planungs- und Entwurfsphase, also sehr früh im SDLC. Hier kommen Bedrohungsmodellierung und eine Überprüfung der Architektur ins Spiel. Mit diesen Techniken ist es möglich, solche Fehler frühzeitig aufzudecken, bevor automatisierte Tests greifen.

Das klingt, als gäbe es für einen Chief Information Security Officer (CISOs) ausreichend viel zu tun. Wie kann ein CISO die Risiken in der Informationssicherheit messen, melden und die Situation verbessern? 

Gute Frage. Um es mit Peter Drucker zu sagen: »Was man nicht messen kann, kann man nicht verbessern.« Der erste Schritt besteht also darin, sich darüber klar zu werden, wo Sie auf Ihrem Weg stehen. Messen Sie, was Sie heute tun, damit Sie Lücken und Bereiche mit Verbesserungspotenzial identifizieren können. Eine Möglichkeit, den aktuellen Stand zu ermitteln, ist die Bewertung nach dem Building Security In Maturity Model (BSIMM). Das BSIMM ist ein datengestütztes Modell, das durch die Analyse realer Softwaresicherheitsinitiativen entwickelt wurde. BSIMM12 wurde im September 2021 veröffentlicht, und bietet eine detaillierte Messlatte für die Softwaresicherheit, basierend auf der Analyse von 128 Unternehmen aus 9 unterschiedlichen Schlüsselbranchen.

Nehmen wir an, Sie leiten ein überschaubares AppSec-Team mit begrenzten Kompetenzen und Ressourcen. Welche Empfehlung geben Sie jemanden in dieser Position?

Es geht vor allem um die richtige Kombination aus Kompetenzen und Tools. Stellen Sie geeignete Entwickler ein oder schulen Sie Ihr existierendes Team. So, dass es sicheren Code entwickeln und diesen konsistent pflegen kann. Die Bedrohungslandschaft ist ständig in Bewegung, Anwendungen werden erweitert und entwickeln sich zusammen mit den Bedrohungen weiter. Hacker sind permanent auf der Suche nach neuen Techniken, um Schwachstellen auszunutzen. Und täglich kommen weitere hinzu. Entwickler- und Sicherheitsteams kommen nicht umhin, hier auf dem Laufenden zu bleiben. Andernfalls werden Anwendungen zunehmend anfälliger für Angriffe.

Das alles ist oft leichter gesagt als getan, Qualifikationen im Bereich Sicherheit sind gesucht, Fachkräfte Mangelware. Alternativ sollte man sich mit einem Anbieter von Managed Services zusammentun.

Gerade wenn Sie in einer stark regulierten Branche wie dem Finanzdienstleistungssektor oder dem Gesundheitswesen tätig sind, in denen spezifische Compliance- und Regulierungsanforderungen gelten. Wenn die Budgets und Ressourcen begrenzt sind, kann die Unterstützung durch Dritte eine lohnende Investition sein. Jedenfalls, wenn man die ganzheitlichen Anforderungen an die Anwendungssicherheit erfüllen will.