Wie App-Sicherheit nach links verschoben wird

Es besteht zwar ein allgemeiner Konsens darüber, dass mehr Verantwortung für die Anwendungssicherheit in Richtung Entwickler verlagert werden muss, aber wenn es darum geht zu bestimmen, wie dieses Ziel erreicht werden soll, herrscht keine große Einigkeit.

Theoretisch sollten Entwickler mehr Tools zur Verfügung stehen, um ihren Code auf Schwachstellen zu scannen, bevor er dem Build hinzugefügt wird, der schließlich in einer Produktionsumgebung bereitgestellt wird. Die Herausforderung besteht darin, dass die meisten Entwickler wenig bis gar kein Fachwissen in Cybersecurity haben und daher nicht gerüstet sind, den Schweregrad einer Schwachstelle zu identifizieren. Die meisten Anwendungen enthalten heutzutage Open-Source-Komponenten, die Schwachstellen haben. Es ist also fast unmöglich, eine Anwendung zu erstellen, die keine Schwachstellen enthält.

Die zweite Herausforderung besteht darin, dass die meisten Anwendungen von mehreren Entwicklern erstellt werden, die über unterschiedliche Kenntnisse und Fertigkeiten in Cybersecurity verfügen. Daher ist die Wahrscheinlichkeit groß, dass Code, der eine schwerwiegende Schwachstelle aufweisen könnte, seinen Weg in den zu erstellenden Build findet. Das bedeutet, dass nicht nur der Build, sondern auch der Code, mit dem er erstellt wurde, auf Schwachstellen geprüft werden muss, während er eine Softwareentwicklungspipeline durchläuft.

Schließlich sind jetzt auch die Tools und Plattformen, die zur Erstellung dieser Pipelines verwendet werden, Angriffen ausgesetzt. Organisationen jeder Größe müssen sicherstellen, dass Malware nicht in die Tools und Plattformen eingebettet ist, die zur Verwaltung der Softwareentwicklungspipelines verwendet werden, um die Integrität der Softwarelieferketten zu gewährleisten.

All diese Probleme sollen durch die Einführung einer Reihe von DevSecOps-Best Practices angegangen werden können. Die Wahrscheinlichkeit, dass Anwendungsentwickler über das erforderliche Fachwissen verfügen, um jede Phase ihres Anwendungsentwicklung-Prozesses zu sichern, ist jedoch gering bis nicht gegeben.

Die Hoffnung ist natürlich, dass der gesamte Prozess der Security-Gewährleistung stärker automatisiert wird, wenn mehr Cybersecurity-Schutzgeländer in die Tools und Plattformen eingebettet werden, die zum Erstellen und Bereitstellen von Software verwendet werden. Unabhängig davon, wie automatisiert die in diese Tools eingebetteten Cybersecurity-Schutzgeländer werden, ist es dennoch erforderlich, dass jemand mit Cybersecurity-Fachkenntnissen involviert ist. Organisationen gehen auf diese Anforderung auf drei Arten ein. Sie suchen jemanden im Entwicklerteam, der ein echtes Händchen für Cybersecurity hat, um alle anderen zu coachen. Eine zweite Option ist, dem Team, das den DevOps-Workflow verwaltet, einen spezialisierten Security-Ingenieur zur Seite zu stellen. Die dritte Option ist, ein Cybersecurity-Kompetenzzentrum zu schaffen, dem Cybersecurity-Experten angehören, die zusammen mit Entwicklern an der Erstellung von Anwendungen arbeiten.

Jedes Unternehmen, das Software entwickelt, muss selbst entscheiden, welcher Ansatz am sinnvollsten ist. Einige größere Organisationen werden zweifellos alle drei Ansätze verfolgen, da die Benutzer von Anwendungen weiterhin die Zusicherung verlangen, dass die gelieferte Software einen bestimmten Cybersecurity-Schwellenwert erfüllt.

Unabhängig von der Herangehensweise ist klar, dass mehr Unternehmen Cybersecurity-Experten in ihren Workflow bei der Anwendungsentwicklung einbinden wollen. Weniger klar ist, welche Auswirkungen diese Einbeziehung auf die Geschwindigkeit haben wird, mit der Anwendungen heutzutage entwickelt werden. Für die meisten Entwicklungsteams ist Geschwindigkeit wichtiger als alles andere, ausgenommen die Leistung vielleicht. Die Führungskräfte, die diese Projekte finanzieren, lassen jedoch verlauten, dass Cybersecurity nun eine wesentlich größere Bedeutung für sie hat, selbst wenn sie mehr Zeit beim Erstellen von Anwendungen in Anspruch nimmt.

Natürlich fanden Cybersecurity-Experten es noch nie besonders sinnvoll, Anwendungen zu entwickeln und einzusetzen, die mit Schwachstellen durchsetzt sind. Die gute Nachricht ist, dass so gut wie alle anderen inzwischen ebenfalls zu dieser Schlussfolgerung kommen.