Cybersicherheit bleibt für viele Unternehmen ein großer Schmerzpunkt: Eine Studie des etablierten Sicherheitsanbieters Palo Alto Networks aus dem vergangenen Jahr ergab, dass Sicherheitsteams in großen Unternehmen im Durchschnitt mehr als 130 separate Sicherheitslösungen verwenden . Auf der diesjährigen gerade zu Ende gegangenen RSA-Sicherheitskonferenz in San Francisco haben mehr als 700 Sicherheitsanbieter und -aussteller um Aufmerksamkeit gekämpft. Einige dieser Unternehmen liefern neue Technologien, um automatisch statt manuell die wachsende Zahl von Sicherheitsproblemen zu lösen, die durch die neuen Cloud-nativen Umgebungen in vielen Unternehmen entstehen, in denen Teams neue DevOps-Praktiken nutzen und Microservices in öffentlichen und hybriden Clouds bereitstellen Startups.

Wir glauben, dass das aktuelle Unternehmenssicherheitsmodell angesichts dieser Umstellung auf Cloud-native Praktiken nicht nachhaltig ist. Mit mehr als 40 Millionen Entwicklern allein auf GitHub und Milliardenausgaben für entwicklergeführte digitale Transformationsbemühungen in Unternehmen aller Branchen ist klar, dass immer mehr Sicherheitsbedenken von Entwicklern früher im Softwareentwicklungszyklus angegangen werden müssen. In der Tat entstehen jetzt viele neue Startups, um Entwicklern und ihren Organisationen und nicht nur hochrangigen Führungskräften für Unternehmenssicherheit dabei zu helfen, sich proaktiver auf Sicherheit zu konzentrieren.

Wir haben in unserem OpenCloud-Bericht 2019 erörtert, dass die Verlagerung in die Cloud die „Angriffsfläche“ für Angreifer vergrößert und neue Sicherheitslücken für Unternehmen schafft, aber auch neue Möglichkeiten für Startups, die ihnen helfen wollen, sich zu wehren. Im weiteren Sinne verändert die Cloud die Philosophie, wie Unternehmen an Sicherheit herangehen, indem sie Entwickler dazu bringt, früher über Sicherheit nachzudenken, Sicherheitslösungen tiefer in ihre Arbeitsabläufe zu integrieren und Sicherheit als Code zu kodifizieren, um die Entwicklung schnell voranzutreiben.

Wie sind wir hierher gekommen?

In der Vergangenheit waren Chief Information Security Officers (CISOs) für die Kaufentscheidungen für Sicherheitssoftware in Unternehmen verantwortlich. Sie beaufsichtigten zentralisierte Security Operations Centers (SOCs), die Sicherheitssoftware verwendeten, um Bedrohungen und Schwachstellen im gesamten Unternehmen manuell zu erkennen und zu beheben (denken Sie an die Erkennung von Malware in einem Netzwerk, Firewall-Verletzungen, Änderung von Zugriffsberechtigungen usw.). In einer Welt, in der Infrastrukturumgebungen statisch waren und der Softwareentwicklungsprozess Monate dauerte, war diese Struktur überschaubar.

Aber mit dem Aufkommen der Cloud wurde die Infrastruktur dynamisch: Open-Source-Software und wiederverwendbare Softwaremodule wurden zu grundlegenden Bausteinen und die Entwicklungszeiten auf Tage/Wochen komprimiert. Heute muss sich das SOC nur noch mit den risikoreichsten Bedrohungen und Schwachstellen befassen, die umfassende sicherheitsforensische Expertise erfordern. Der Rest der Vorfälle wird automatisch an Entwickler und DevOps-Teams weitergeleitet, die über den Kontext zur Behebung der Probleme verfügen. Dies hat neuen Unternehmen die Möglichkeit eröffnet, neue, zielgerichtetere Tools für diese Entwickler und DevOps-Teams bereitzustellen, um Sicherheitsprobleme anzugehen.

Frühe Unternehmen der Branche

Die erste Welle von Unternehmen in diesem Bereich konzentrierte sich auf das Sichern und Scannen von Anwendungen während des Entwicklungsprozesses – vor allem, weil diese Anwendungen Einnahmen generierten und eine hohe Verfügbarkeit und Sicherheit erforderten.  Zu diesen Unternehmen gehörten Contrast Security* und etablierte Unternehmen wie Veracode und Fortify. Unternehmen beginnen auch damit, Entwickler proaktiv über Best Practices im Bereich Sicherheit aufzuklären, indem sie personalisierte Programme und Mitteilungen bereitstellen, die ihnen helfen, Sicherheit in ihre Arbeitsabläufe zu integrieren. Unternehmen wie Secure Code Warrior haben dafür Bildungsplattformen entwickelt. Obwohl solche Tools von CISOs vorgeschrieben wurden, wurden sie für Entwickler und nicht für Sicherheitsanalysten entwickelt. Dies bedeutete eine enge Zusammenarbeit zwischen dem CISO und dem Chief Technology Officer („CTO“) einer Organisation.

Heute stellen andere Unternehmen Tools bereit, die es Entwicklern und DevOps-Teams ermöglichen, Sicherheitslösungen organisch zu übernehmen und sie noch tiefer in ihre Arbeitsabläufe einzubetten. JFrog*, das als Artefakt-Repository begann und nun kontinuierliche Sicherheit für Container und Software-Artefakte bietet, kann sich einer Community von drei Millionen Entwicklern rühmen. Snyk, das Code-Scanning-Sicherheit für Open-Source-Bibliotheken und -Container bietet, hat 400.000 Entwickler auf seiner Plattform und sammelte Anfang dieses Jahres Mittel, die das Unternehmen auf mehr als 1 Milliarde US-Dollar bewerteten.

Da DevOps-Teams außerdem die Time-to-Production mithilfe von „Infrastructure as Code“ (IaC)-Vorlagen verkürzen, ist die Kodifizierung von Sicherheitspraktiken – oder „Security as Code“ (SaC) – ebenfalls Teil ihres Arbeitsablaufs geworden. Unternehmen wie Styra und HashiCorp Sentinel kodifizieren die Behebung von Vorfällen in Richtlinienrahmen, während andere wie Bridgecrew alles zusammen in Build-Time- und Run-Time-Umgebungen automatisieren.

Außerhalb von Unternehmen und Entwicklungsteams beginnen auch Cloud-Anbieter, die sich traditionell darauf konzentriert haben, Entwickler anzuziehen, Sicherheit in ihre Angebote einzubetten und Sicherheit ernst zu nehmen. Github (2018 von Microsoft für 7,5 Milliarden US-Dollar übernommen) erwarb Semmle und Dependabot, um die Codequalität zu verbessern und Abhängigkeitsdateien auf veraltete Anforderungen zu überprüfen. Palo Alto Networks hat in den letzten 24 Monaten mehr als 1 Milliarde US-Dollar für Cloud-native Sicherheitslösungen wie Evident.io RedLock, Twistlock, Demisto und andere ausgegeben. Darüber hinaus veranstaltete der Cloud-Gigant Amazon Web Services 2019 seine erste Konferenz zum Thema Cloud-Sicherheit: AWS re:Inforce.

Learnings und Überlegungen für Gründer

Bei Battery haben wir die letzten Jahre damit verbracht, die Transformation der Sicherheit und ihre Verlagerung auf die Entwicklerebene zu untersuchen. Wir sehen ein paar wichtige Überlegungen, die Sie berücksichtigen sollten, wenn Sie ein Gründer sind, der ein sicherheitsorientiertes Unternehmen für Entwickler aufbaut.

Der Markt ist noch am Anfang: Wir befinden uns erst in den frühen Innings dieser Branchentransformation. Große Unternehmen verlassen sich immer noch auf viele Sicherheitstaktiken der alten Schule, wie z. B. den Einsatz von SOC Analyst und die Einbeziehung von Managed Security Service Providern. Während sich immer mehr Verantwortlichkeiten auf die Entwicklerebene verlagern, geschieht dies nicht über Nacht. Daher ist es wichtig, dass Sie als entwicklerorientiertes Sicherheits-Startup vom Käufer vertraut werden. Die Anteile sind viel höher, wenn eine Drittanbieterlösung den Code einer Organisation berührt oder proaktiv Änderungen an Workloads und Infrastruktur vornimmt. Unser Rat ist, Vertrauen bei Ihren potenziellen Käufern aufzubauen und sicherzustellen, dass die Benutzer ihr Entwicklungstempo beibehalten können, indem Sie entweder: sich mit einem erfahrenen und glaubwürdigen Team umgeben; Aufbau mit Blick auf einfache Implementierung und Überprüfbarkeit; Aufbau und Einbeziehung der Entwicklergemeinschaft in irgendeine Form von Gemeinschaftsbeziehungen durch Entwicklerbeziehungen; und/oder Erstellen von und Beitragen zu Open-Source-Projekten, die das Ökosystem unterstützen.

Sicherheitsteams wird es geben, aber die Verantwortlichkeiten verschmelzen: Sicherheitsteams werden immer spezialisierter. Einige der fortschrittlichsten Unternehmen wie Netflix, Spotify, Stripe und Airbnb haben spezielle Teams für die Anwendungssicherheit oder die Sicherheit der Cloud-Infrastruktur. Vorbei sind die Zeiten, in denen ein Team die Sicherheit für das gesamte Unternehmen verwaltete. Infolgedessen verschwimmen die Verantwortlichkeiten für die Sicherheit von CISO und CTO. Erwarten Sie, dass mehr CISOs und CTOs ihre eigenen Sicherheitsbudgets besitzen – wissen Sie, was Ihre Sicherheitslösung letztendlich erreichen wird, um den richtigen Käufer zu qualifizieren.

Der Käufer ist nicht der Benutzer: Da diese Transformation noch am Anfang steht, handelt es sich noch um einen Dual-Persona-Verkauf. Sie müssen nicht nur das Budget des CISO und der Sicherheitsorganisation freigeben, sondern auch die Herzen und Köpfe der Entwickler gewinnen, die die Lösung letztendlich verwenden werden. Stellen Sie als Gründer sicher, dass Sie Ihr Wertversprechen entsprechend ausrichten. Wir haben gesehen, dass einige Unternehmen Sicherheiten für beide Personas erstellt haben – die Sicherheitsorganisation und die technische Organisation. Verkaufen Sie im Rahmen des Budgets, aber bauen Sie Vertrauen auf und zeigen Sie dem Benutzer, dass sich der Zeitwert amortisiert.

Wir denken, dass es eine großartige Zeit ist, ein Gründer zu sein, der eine entwicklerzentrierte Sicherheitslösung entwickelt. Da die Cloud-Akzeptanz weiter zunimmt – und die Softwareentwicklung noch schneller wird – werden mehr Sicherheitsverantwortlichkeiten auf die Entwicklerebene verlagert und Sicherheit wird weiterhin ein vorrangiges Anliegen für Unternehmen sein, was viele Möglichkeiten für Sicherheitsunternehmer bedeutet.

Dieser Artikel erschien ursprünglich auf Forbes.