Wenn AppSec-Tooling der Königsweg ist, warum setzen so viele Unternehmen es nicht ein?
Eine Version dieses Artikels erschien in SC Zeitschrift. Er wurde aktualisiert und hier syndiziert.
Eines der vielen Rätsel, mit denen die Sicherheitsspezialisten von heute konfrontiert sind, besteht darin, die Balance zwischen den Lösungen zu finden, die sie zur Bewältigung der Cyber-Risiken einsetzen werden, denen sie ausgesetzt sind. Wie soll das Budget zwischen Tools und Mitarbeitern aufgeteilt werden? Welche Tool-Suite passt am besten zum vorhandenen Tech-Stack? Bei so vielen Optionen gibt es keine einfachen Antworten, und die Wahl der falschen Optionen wird später Zeit und Geld kosten.
Ein kürzlich veröffentlichter Bericht zeigt, dass der Markt für Anwendungssicherheits-Tools bis 2025 ein "explosives" Wachstum verzeichnen wird. Dies ist ein deutlicher Hinweis auf die unbestrittene Rolle dieser Tools für erfolgreiche DevSecOps-Praktiken und die zunehmende Relevanz in der Branche angesichts der wachsenden Mengen an Code mit potenziellen Sicherheitslücken.
Es gibt jedoch ein etwas merkwürdiges Problem. Fast die Hälfte aller Unternehmen liefert wissentlich angreifbaren Code aus, obwohl sie eine Reihe von AppSec-Tools einsetzen, die genau das verhindern sollen. Für Produkte mit einer unbestreitbaren Marktnachfrage, die schnell an Zugkraft gewinnt, macht das wenig Sinn. Warum kaufen sich so viele in ausgeklügelte Sicherheitstools ein, nur um deren Ergebnisse zu ignorieren oder sie gar nicht zu nutzen? Das ist ein bisschen so, als würde man ein Haus am Strand kaufen, nur um dann in einem Zelt im Wald zu schlafen.
Es gibt einige Gründe, warum AppSec-Tools nicht so genutzt werden, wie wir es vielleicht erwarten. Dabei geht es weniger um die Tools und ihre Funktionalität, sondern vielmehr darum, wie sie sich in ein Sicherheitsprogramm als Ganzes integrieren.
Mehr Werkzeuge sind nicht gleichbedeutend mit weniger Problemen.
Wenn Unternehmen ihre Softwareentwicklungsprozesse weiterentwickeln, von Agile über DevOps bis hin zum heiligen Nirwana DevSecOps (hey, für den Moment ist es das Beste, was wir haben), ist es unvermeidlich, dass auf dem Weg dorthin mehrere Scanner, Monitore, Firewalls und alle möglichen AppSec-Tools gekauft werden. Auch wenn es den Anschein hat, dass es ein Fall von "je mehr, desto besser" ist, führt dies sehr oft zu einem Tech-Stack, der Frankensteins Monster ähnelt, mit all der Unvorhersehbarkeit, die dies mit sich bringt.
Mit Budgets und Expertenressourcen, die für den Umfang der erforderlichen Arbeit zunehmend begrenzt sind, ist der Versuch, das Chaos zu beseitigen und den besten Tooling-Pfad für die Zukunft zu finden, eine entmutigende Aufgabe, und der Code, der gescannt und behoben werden muss, kommt einfach immer wieder. Es ist nicht verwunderlich, dass viele Unternehmen weiterhin Code ausliefern müssen, auch wenn dies ziemlich alarmierend ist und immer noch ein immenses Risiko für unsere Daten und unsere Privatsphäre darstellt.
Scanning-Tools sind langsam, was sich auf die Agilität von Releases auswirkt.
Sicherheit mit Geschwindigkeit zu erreichen, ist so etwas wie ein weißer Wal in der Softwareentwicklung, und die Wahrheit ist, dass wir immer noch versuchen, das richtig hinzubekommen, selbst wenn wir Organisationen dazu bringen, einen DevSecOps-orientierten Ansatz zu übernehmen. Akribisches, manuelles Code-Review mag in den 90er Jahren als Sicherheitsgarantie funktioniert haben, aber in einer Zeit, in der wir Hunderte von Milliarden Codezeilen produzieren, ist dieser Plan ungefähr so effektiv wie die Vorbereitung eines Fußballfeldes mit einer Nagelschere.
Scanning-Tools automatisieren den Prozess der Suche nach potenziellen Schwachstellen und übernehmen den Teil der akribischen Codeüberprüfung für uns. Das Problem ist, dass sie im Kontext einer CI/CD-Pipeline, die auf allen Zylindern läuft, immer noch langsam sind, und kein einziges Tool findet jede Schwachstelle. Es gibt auch ein paar eklatante Probleme mit den Ergebnissen, die nach einem Scan an das Sicherheitsteam ausgespuckt werden:
- Es gibt eine Menge falsch positiver (und negativer) Ergebnisse
- Irgendein armer Sicherheitsexperte muss immer noch dasitzen und eine manuelle Überprüfung durchführen, um die echten Bugs von den Phantom-Bugs zu trennen
- Oft werden viel zu viele allgemeine Schwachstellen aufgedeckt, die schon vor der Bereitstellung des Codes hätten erkannt werden müssen. Wollen Sie wirklich, dass Ihre sehr teuren Sicherheitsexperten von den großen, haarigen Sicherheitsproblemen mit dem Kleinkram abgelenkt werden?
- Scanner finden, sie beheben nicht.
Selbst in einer Organisation, die ihr Bestes tut, um nach den besten Praktiken der Cybersicherheit zu arbeiten und mit der Zeit zu gehen, um Sicherheit in jede Phase des Prozesses einzubeziehen, ist der oben beschriebene Prozess immer noch ein Showstopper, wenn Scanner die wichtigste Schutzmaßnahme sind und zu viele häufige Fehler das Team bei der Bereitstellung von sicherem Code behindern. Es liegt auf der Hand, dass hier an der falschen Stelle gespart wird, und zwar in der Regel in der Form, dass man sich auf das absolute Minimum an Tools verlässt, die unmöglich alle potenziellen Risiken abdecken können, selbst wenn man eine ganze Reihe von Lösungen gekauft hat.
Einige technisch geführte Automatisierungen können zu einer verminderten Codequalität führen
Scannen und Testen tragen die Hauptlast der automatisierten Prozesse im AppSec-Tooling, zusammen mit essenziellen Dingen wie Firewalls und Monitoring, aber andere gängige Tools können mit der Zeit unbeabsichtigt die praktischen Sicherheitsgrundlagen aushöhlen.
So wird beispielsweise die RASP-Technologie (Runtime Application Self-Protection) häufig eingesetzt, um die Sicherheitslage zu verbessern, ohne die Codierungsgeschwindigkeit zu beeinträchtigen. Sie arbeitet in der Laufzeitumgebung einer Anwendung und schützt vor böswilligen Code-Eingaben, Echtzeitangriffen und meldet jedes merkwürdige Ausführungsverhalten.
Es ist sicherlich ein zusätzlicher Schutz, aber wenn man es als Ausfallsicherung gegen potenzielle Schwachstellen in der Codebasis betrachtet, können Entwickler selbstgefällig werden, besonders wenn sie mit immer unmöglicheren Terminen für die Markteinführung neuer Funktionen konfrontiert werden. Sichere Coding-Praktiken werden möglicherweise nicht befolgt, in der Annahme, dass der Selbstschutz zur Laufzeit alle Fehler erkennen wird. Entwickler machen sich nicht die Mühe, unsichere Codierungsmuster zu erstellen, aber die Sicherheit wird oft zugunsten der Bereitstellung von Funktionen zurückgestellt, vor allem in der Annahme, dass es einen automatischen Schutz gibt.
Tools können versagen (und laufen im Fall von RASP oft im Überwachungsmodus, um False Positives zu vermeiden, was wiederum nur Sichtbarkeit - aber keinen Schutz - vor einem Angriff bietet), und wenn das passiert, ist es hochwertiger, sicherer Code, auf den man sich jedes Mal verlassen kann. Sicherheitsbewusstsein in jeder Rolle, die mit Code in Berührung kommt, ist grundlegend für DevSecOps, und Entwickler, die keinen sicheren Code trainieren oder produzieren, machen einen Fehler. Das Schreiben von sicherem und unsicherem Code erfordert den gleichen Aufwand; es ist die Aneignung des Wissens, um sicher zu codieren, die die wirkliche Energie erfordert. Die Zeit, die für die Implementierung und Optimierung von RASP aufgewendet wird, kann viel besser für die Weiterbildung von Entwicklern genutzt werden, damit diese den Fehler gar nicht erst machen.
Das Gleichgewicht zwischen Werkzeugen und Menschen: Es ist kein Allheilmittel, aber es kommt dem am nächsten (im Moment).
Das Hauptethos von DevSecOps besteht darin, Sicherheit zu einer gemeinsamen Verantwortung zu machen. Unternehmen, die die Software entwickeln, die unser Leben bestimmt - vom Stromnetz bis hin zu unseren Türklingeln - müssen alle Beteiligten mit einbeziehen, um ein höheres Maß an Sicherheit zu gewährleisten.
Mit Tools lässt sich nicht alles erreichen, und es ist nicht einmal der billigste Weg. Die bei weitem besten Ergebnisse werden erzielt, indem man relevante Sicherheitsschulungen für jeden, der mit Code in Berührung kommt, priorisiert, aktiv daran arbeitet, die Sicherheit für das Entwicklungsteam in den Vordergrund zu stellen, und eine positive Sicherheitskultur aufbaut, die von Menschen geführt wird, wobei eine Tooling-Suite eine unterstützende Rolle spielt.
Selbst angesichts von Zeitbeschränkungen, abgeschnittenen Ecken und anderen Dingen, die Sicherheitsexperten nachts den Schlaf rauben, stellen diese Tools (und ob sie nun verwendet werden oder nicht) einen weitaus geringeren Risikofaktor dar, wenn die Entwickler gängige Sicherheitsmängel gar nicht erst einführen.
Es gibt einige Gründe, warum AppSec-Tools nicht so genutzt werden, wie wir es vielleicht erwarten. Dabei geht es weniger um die Tools und ihre Funktionalität, sondern vielmehr darum, wie sie sich in ein Sicherheitsprogramm als Ganzes integrieren.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Eine Version dieses Artikels erschien in SC Zeitschrift. Er wurde aktualisiert und hier syndiziert.
Eines der vielen Rätsel, mit denen die Sicherheitsspezialisten von heute konfrontiert sind, besteht darin, die Balance zwischen den Lösungen zu finden, die sie zur Bewältigung der Cyber-Risiken einsetzen werden, denen sie ausgesetzt sind. Wie soll das Budget zwischen Tools und Mitarbeitern aufgeteilt werden? Welche Tool-Suite passt am besten zum vorhandenen Tech-Stack? Bei so vielen Optionen gibt es keine einfachen Antworten, und die Wahl der falschen Optionen wird später Zeit und Geld kosten.
Ein kürzlich veröffentlichter Bericht zeigt, dass der Markt für Anwendungssicherheits-Tools bis 2025 ein "explosives" Wachstum verzeichnen wird. Dies ist ein deutlicher Hinweis auf die unbestrittene Rolle dieser Tools für erfolgreiche DevSecOps-Praktiken und die zunehmende Relevanz in der Branche angesichts der wachsenden Mengen an Code mit potenziellen Sicherheitslücken.
Es gibt jedoch ein etwas merkwürdiges Problem. Fast die Hälfte aller Unternehmen liefert wissentlich angreifbaren Code aus, obwohl sie eine Reihe von AppSec-Tools einsetzen, die genau das verhindern sollen. Für Produkte mit einer unbestreitbaren Marktnachfrage, die schnell an Zugkraft gewinnt, macht das wenig Sinn. Warum kaufen sich so viele in ausgeklügelte Sicherheitstools ein, nur um deren Ergebnisse zu ignorieren oder sie gar nicht zu nutzen? Das ist ein bisschen so, als würde man ein Haus am Strand kaufen, nur um dann in einem Zelt im Wald zu schlafen.
Es gibt einige Gründe, warum AppSec-Tools nicht so genutzt werden, wie wir es vielleicht erwarten. Dabei geht es weniger um die Tools und ihre Funktionalität, sondern vielmehr darum, wie sie sich in ein Sicherheitsprogramm als Ganzes integrieren.
Mehr Werkzeuge sind nicht gleichbedeutend mit weniger Problemen.
Wenn Unternehmen ihre Softwareentwicklungsprozesse weiterentwickeln, von Agile über DevOps bis hin zum heiligen Nirwana DevSecOps (hey, für den Moment ist es das Beste, was wir haben), ist es unvermeidlich, dass auf dem Weg dorthin mehrere Scanner, Monitore, Firewalls und alle möglichen AppSec-Tools gekauft werden. Auch wenn es den Anschein hat, dass es ein Fall von "je mehr, desto besser" ist, führt dies sehr oft zu einem Tech-Stack, der Frankensteins Monster ähnelt, mit all der Unvorhersehbarkeit, die dies mit sich bringt.
Mit Budgets und Expertenressourcen, die für den Umfang der erforderlichen Arbeit zunehmend begrenzt sind, ist der Versuch, das Chaos zu beseitigen und den besten Tooling-Pfad für die Zukunft zu finden, eine entmutigende Aufgabe, und der Code, der gescannt und behoben werden muss, kommt einfach immer wieder. Es ist nicht verwunderlich, dass viele Unternehmen weiterhin Code ausliefern müssen, auch wenn dies ziemlich alarmierend ist und immer noch ein immenses Risiko für unsere Daten und unsere Privatsphäre darstellt.
Scanning-Tools sind langsam, was sich auf die Agilität von Releases auswirkt.
Sicherheit mit Geschwindigkeit zu erreichen, ist so etwas wie ein weißer Wal in der Softwareentwicklung, und die Wahrheit ist, dass wir immer noch versuchen, das richtig hinzubekommen, selbst wenn wir Organisationen dazu bringen, einen DevSecOps-orientierten Ansatz zu übernehmen. Akribisches, manuelles Code-Review mag in den 90er Jahren als Sicherheitsgarantie funktioniert haben, aber in einer Zeit, in der wir Hunderte von Milliarden Codezeilen produzieren, ist dieser Plan ungefähr so effektiv wie die Vorbereitung eines Fußballfeldes mit einer Nagelschere.
Scanning-Tools automatisieren den Prozess der Suche nach potenziellen Schwachstellen und übernehmen den Teil der akribischen Codeüberprüfung für uns. Das Problem ist, dass sie im Kontext einer CI/CD-Pipeline, die auf allen Zylindern läuft, immer noch langsam sind, und kein einziges Tool findet jede Schwachstelle. Es gibt auch ein paar eklatante Probleme mit den Ergebnissen, die nach einem Scan an das Sicherheitsteam ausgespuckt werden:
- Es gibt eine Menge falsch positiver (und negativer) Ergebnisse
- Irgendein armer Sicherheitsexperte muss immer noch dasitzen und eine manuelle Überprüfung durchführen, um die echten Bugs von den Phantom-Bugs zu trennen
- Oft werden viel zu viele allgemeine Schwachstellen aufgedeckt, die schon vor der Bereitstellung des Codes hätten erkannt werden müssen. Wollen Sie wirklich, dass Ihre sehr teuren Sicherheitsexperten von den großen, haarigen Sicherheitsproblemen mit dem Kleinkram abgelenkt werden?
- Scanner finden, sie beheben nicht.
Selbst in einer Organisation, die ihr Bestes tut, um nach den besten Praktiken der Cybersicherheit zu arbeiten und mit der Zeit zu gehen, um Sicherheit in jede Phase des Prozesses einzubeziehen, ist der oben beschriebene Prozess immer noch ein Showstopper, wenn Scanner die wichtigste Schutzmaßnahme sind und zu viele häufige Fehler das Team bei der Bereitstellung von sicherem Code behindern. Es liegt auf der Hand, dass hier an der falschen Stelle gespart wird, und zwar in der Regel in der Form, dass man sich auf das absolute Minimum an Tools verlässt, die unmöglich alle potenziellen Risiken abdecken können, selbst wenn man eine ganze Reihe von Lösungen gekauft hat.
Einige technisch geführte Automatisierungen können zu einer verminderten Codequalität führen
Scannen und Testen tragen die Hauptlast der automatisierten Prozesse im AppSec-Tooling, zusammen mit essenziellen Dingen wie Firewalls und Monitoring, aber andere gängige Tools können mit der Zeit unbeabsichtigt die praktischen Sicherheitsgrundlagen aushöhlen.
So wird beispielsweise die RASP-Technologie (Runtime Application Self-Protection) häufig eingesetzt, um die Sicherheitslage zu verbessern, ohne die Codierungsgeschwindigkeit zu beeinträchtigen. Sie arbeitet in der Laufzeitumgebung einer Anwendung und schützt vor böswilligen Code-Eingaben, Echtzeitangriffen und meldet jedes merkwürdige Ausführungsverhalten.
Es ist sicherlich ein zusätzlicher Schutz, aber wenn man es als Ausfallsicherung gegen potenzielle Schwachstellen in der Codebasis betrachtet, können Entwickler selbstgefällig werden, besonders wenn sie mit immer unmöglicheren Terminen für die Markteinführung neuer Funktionen konfrontiert werden. Sichere Coding-Praktiken werden möglicherweise nicht befolgt, in der Annahme, dass der Selbstschutz zur Laufzeit alle Fehler erkennen wird. Entwickler machen sich nicht die Mühe, unsichere Codierungsmuster zu erstellen, aber die Sicherheit wird oft zugunsten der Bereitstellung von Funktionen zurückgestellt, vor allem in der Annahme, dass es einen automatischen Schutz gibt.
Tools können versagen (und laufen im Fall von RASP oft im Überwachungsmodus, um False Positives zu vermeiden, was wiederum nur Sichtbarkeit - aber keinen Schutz - vor einem Angriff bietet), und wenn das passiert, ist es hochwertiger, sicherer Code, auf den man sich jedes Mal verlassen kann. Sicherheitsbewusstsein in jeder Rolle, die mit Code in Berührung kommt, ist grundlegend für DevSecOps, und Entwickler, die keinen sicheren Code trainieren oder produzieren, machen einen Fehler. Das Schreiben von sicherem und unsicherem Code erfordert den gleichen Aufwand; es ist die Aneignung des Wissens, um sicher zu codieren, die die wirkliche Energie erfordert. Die Zeit, die für die Implementierung und Optimierung von RASP aufgewendet wird, kann viel besser für die Weiterbildung von Entwicklern genutzt werden, damit diese den Fehler gar nicht erst machen.
Das Gleichgewicht zwischen Werkzeugen und Menschen: Es ist kein Allheilmittel, aber es kommt dem am nächsten (im Moment).
Das Hauptethos von DevSecOps besteht darin, Sicherheit zu einer gemeinsamen Verantwortung zu machen. Unternehmen, die die Software entwickeln, die unser Leben bestimmt - vom Stromnetz bis hin zu unseren Türklingeln - müssen alle Beteiligten mit einbeziehen, um ein höheres Maß an Sicherheit zu gewährleisten.
Mit Tools lässt sich nicht alles erreichen, und es ist nicht einmal der billigste Weg. Die bei weitem besten Ergebnisse werden erzielt, indem man relevante Sicherheitsschulungen für jeden, der mit Code in Berührung kommt, priorisiert, aktiv daran arbeitet, die Sicherheit für das Entwicklungsteam in den Vordergrund zu stellen, und eine positive Sicherheitskultur aufbaut, die von Menschen geführt wird, wobei eine Tooling-Suite eine unterstützende Rolle spielt.
Selbst angesichts von Zeitbeschränkungen, abgeschnittenen Ecken und anderen Dingen, die Sicherheitsexperten nachts den Schlaf rauben, stellen diese Tools (und ob sie nun verwendet werden oder nicht) einen weitaus geringeren Risikofaktor dar, wenn die Entwickler gängige Sicherheitsmängel gar nicht erst einführen.
Eine Version dieses Artikels erschien in SC Zeitschrift. Er wurde aktualisiert und hier syndiziert.
Eines der vielen Rätsel, mit denen die Sicherheitsspezialisten von heute konfrontiert sind, besteht darin, die Balance zwischen den Lösungen zu finden, die sie zur Bewältigung der Cyber-Risiken einsetzen werden, denen sie ausgesetzt sind. Wie soll das Budget zwischen Tools und Mitarbeitern aufgeteilt werden? Welche Tool-Suite passt am besten zum vorhandenen Tech-Stack? Bei so vielen Optionen gibt es keine einfachen Antworten, und die Wahl der falschen Optionen wird später Zeit und Geld kosten.
Ein kürzlich veröffentlichter Bericht zeigt, dass der Markt für Anwendungssicherheits-Tools bis 2025 ein "explosives" Wachstum verzeichnen wird. Dies ist ein deutlicher Hinweis auf die unbestrittene Rolle dieser Tools für erfolgreiche DevSecOps-Praktiken und die zunehmende Relevanz in der Branche angesichts der wachsenden Mengen an Code mit potenziellen Sicherheitslücken.
Es gibt jedoch ein etwas merkwürdiges Problem. Fast die Hälfte aller Unternehmen liefert wissentlich angreifbaren Code aus, obwohl sie eine Reihe von AppSec-Tools einsetzen, die genau das verhindern sollen. Für Produkte mit einer unbestreitbaren Marktnachfrage, die schnell an Zugkraft gewinnt, macht das wenig Sinn. Warum kaufen sich so viele in ausgeklügelte Sicherheitstools ein, nur um deren Ergebnisse zu ignorieren oder sie gar nicht zu nutzen? Das ist ein bisschen so, als würde man ein Haus am Strand kaufen, nur um dann in einem Zelt im Wald zu schlafen.
Es gibt einige Gründe, warum AppSec-Tools nicht so genutzt werden, wie wir es vielleicht erwarten. Dabei geht es weniger um die Tools und ihre Funktionalität, sondern vielmehr darum, wie sie sich in ein Sicherheitsprogramm als Ganzes integrieren.
Mehr Werkzeuge sind nicht gleichbedeutend mit weniger Problemen.
Wenn Unternehmen ihre Softwareentwicklungsprozesse weiterentwickeln, von Agile über DevOps bis hin zum heiligen Nirwana DevSecOps (hey, für den Moment ist es das Beste, was wir haben), ist es unvermeidlich, dass auf dem Weg dorthin mehrere Scanner, Monitore, Firewalls und alle möglichen AppSec-Tools gekauft werden. Auch wenn es den Anschein hat, dass es ein Fall von "je mehr, desto besser" ist, führt dies sehr oft zu einem Tech-Stack, der Frankensteins Monster ähnelt, mit all der Unvorhersehbarkeit, die dies mit sich bringt.
Mit Budgets und Expertenressourcen, die für den Umfang der erforderlichen Arbeit zunehmend begrenzt sind, ist der Versuch, das Chaos zu beseitigen und den besten Tooling-Pfad für die Zukunft zu finden, eine entmutigende Aufgabe, und der Code, der gescannt und behoben werden muss, kommt einfach immer wieder. Es ist nicht verwunderlich, dass viele Unternehmen weiterhin Code ausliefern müssen, auch wenn dies ziemlich alarmierend ist und immer noch ein immenses Risiko für unsere Daten und unsere Privatsphäre darstellt.
Scanning-Tools sind langsam, was sich auf die Agilität von Releases auswirkt.
Sicherheit mit Geschwindigkeit zu erreichen, ist so etwas wie ein weißer Wal in der Softwareentwicklung, und die Wahrheit ist, dass wir immer noch versuchen, das richtig hinzubekommen, selbst wenn wir Organisationen dazu bringen, einen DevSecOps-orientierten Ansatz zu übernehmen. Akribisches, manuelles Code-Review mag in den 90er Jahren als Sicherheitsgarantie funktioniert haben, aber in einer Zeit, in der wir Hunderte von Milliarden Codezeilen produzieren, ist dieser Plan ungefähr so effektiv wie die Vorbereitung eines Fußballfeldes mit einer Nagelschere.
Scanning-Tools automatisieren den Prozess der Suche nach potenziellen Schwachstellen und übernehmen den Teil der akribischen Codeüberprüfung für uns. Das Problem ist, dass sie im Kontext einer CI/CD-Pipeline, die auf allen Zylindern läuft, immer noch langsam sind, und kein einziges Tool findet jede Schwachstelle. Es gibt auch ein paar eklatante Probleme mit den Ergebnissen, die nach einem Scan an das Sicherheitsteam ausgespuckt werden:
- Es gibt eine Menge falsch positiver (und negativer) Ergebnisse
- Irgendein armer Sicherheitsexperte muss immer noch dasitzen und eine manuelle Überprüfung durchführen, um die echten Bugs von den Phantom-Bugs zu trennen
- Oft werden viel zu viele allgemeine Schwachstellen aufgedeckt, die schon vor der Bereitstellung des Codes hätten erkannt werden müssen. Wollen Sie wirklich, dass Ihre sehr teuren Sicherheitsexperten von den großen, haarigen Sicherheitsproblemen mit dem Kleinkram abgelenkt werden?
- Scanner finden, sie beheben nicht.
Selbst in einer Organisation, die ihr Bestes tut, um nach den besten Praktiken der Cybersicherheit zu arbeiten und mit der Zeit zu gehen, um Sicherheit in jede Phase des Prozesses einzubeziehen, ist der oben beschriebene Prozess immer noch ein Showstopper, wenn Scanner die wichtigste Schutzmaßnahme sind und zu viele häufige Fehler das Team bei der Bereitstellung von sicherem Code behindern. Es liegt auf der Hand, dass hier an der falschen Stelle gespart wird, und zwar in der Regel in der Form, dass man sich auf das absolute Minimum an Tools verlässt, die unmöglich alle potenziellen Risiken abdecken können, selbst wenn man eine ganze Reihe von Lösungen gekauft hat.
Einige technisch geführte Automatisierungen können zu einer verminderten Codequalität führen
Scannen und Testen tragen die Hauptlast der automatisierten Prozesse im AppSec-Tooling, zusammen mit essenziellen Dingen wie Firewalls und Monitoring, aber andere gängige Tools können mit der Zeit unbeabsichtigt die praktischen Sicherheitsgrundlagen aushöhlen.
So wird beispielsweise die RASP-Technologie (Runtime Application Self-Protection) häufig eingesetzt, um die Sicherheitslage zu verbessern, ohne die Codierungsgeschwindigkeit zu beeinträchtigen. Sie arbeitet in der Laufzeitumgebung einer Anwendung und schützt vor böswilligen Code-Eingaben, Echtzeitangriffen und meldet jedes merkwürdige Ausführungsverhalten.
Es ist sicherlich ein zusätzlicher Schutz, aber wenn man es als Ausfallsicherung gegen potenzielle Schwachstellen in der Codebasis betrachtet, können Entwickler selbstgefällig werden, besonders wenn sie mit immer unmöglicheren Terminen für die Markteinführung neuer Funktionen konfrontiert werden. Sichere Coding-Praktiken werden möglicherweise nicht befolgt, in der Annahme, dass der Selbstschutz zur Laufzeit alle Fehler erkennen wird. Entwickler machen sich nicht die Mühe, unsichere Codierungsmuster zu erstellen, aber die Sicherheit wird oft zugunsten der Bereitstellung von Funktionen zurückgestellt, vor allem in der Annahme, dass es einen automatischen Schutz gibt.
Tools können versagen (und laufen im Fall von RASP oft im Überwachungsmodus, um False Positives zu vermeiden, was wiederum nur Sichtbarkeit - aber keinen Schutz - vor einem Angriff bietet), und wenn das passiert, ist es hochwertiger, sicherer Code, auf den man sich jedes Mal verlassen kann. Sicherheitsbewusstsein in jeder Rolle, die mit Code in Berührung kommt, ist grundlegend für DevSecOps, und Entwickler, die keinen sicheren Code trainieren oder produzieren, machen einen Fehler. Das Schreiben von sicherem und unsicherem Code erfordert den gleichen Aufwand; es ist die Aneignung des Wissens, um sicher zu codieren, die die wirkliche Energie erfordert. Die Zeit, die für die Implementierung und Optimierung von RASP aufgewendet wird, kann viel besser für die Weiterbildung von Entwicklern genutzt werden, damit diese den Fehler gar nicht erst machen.
Das Gleichgewicht zwischen Werkzeugen und Menschen: Es ist kein Allheilmittel, aber es kommt dem am nächsten (im Moment).
Das Hauptethos von DevSecOps besteht darin, Sicherheit zu einer gemeinsamen Verantwortung zu machen. Unternehmen, die die Software entwickeln, die unser Leben bestimmt - vom Stromnetz bis hin zu unseren Türklingeln - müssen alle Beteiligten mit einbeziehen, um ein höheres Maß an Sicherheit zu gewährleisten.
Mit Tools lässt sich nicht alles erreichen, und es ist nicht einmal der billigste Weg. Die bei weitem besten Ergebnisse werden erzielt, indem man relevante Sicherheitsschulungen für jeden, der mit Code in Berührung kommt, priorisiert, aktiv daran arbeitet, die Sicherheit für das Entwicklungsteam in den Vordergrund zu stellen, und eine positive Sicherheitskultur aufbaut, die von Menschen geführt wird, wobei eine Tooling-Suite eine unterstützende Rolle spielt.
Selbst angesichts von Zeitbeschränkungen, abgeschnittenen Ecken und anderen Dingen, die Sicherheitsexperten nachts den Schlaf rauben, stellen diese Tools (und ob sie nun verwendet werden oder nicht) einen weitaus geringeren Risikofaktor dar, wenn die Entwickler gängige Sicherheitsmängel gar nicht erst einführen.
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Eine Version dieses Artikels erschien in SC Zeitschrift. Er wurde aktualisiert und hier syndiziert.
Eines der vielen Rätsel, mit denen die Sicherheitsspezialisten von heute konfrontiert sind, besteht darin, die Balance zwischen den Lösungen zu finden, die sie zur Bewältigung der Cyber-Risiken einsetzen werden, denen sie ausgesetzt sind. Wie soll das Budget zwischen Tools und Mitarbeitern aufgeteilt werden? Welche Tool-Suite passt am besten zum vorhandenen Tech-Stack? Bei so vielen Optionen gibt es keine einfachen Antworten, und die Wahl der falschen Optionen wird später Zeit und Geld kosten.
Ein kürzlich veröffentlichter Bericht zeigt, dass der Markt für Anwendungssicherheits-Tools bis 2025 ein "explosives" Wachstum verzeichnen wird. Dies ist ein deutlicher Hinweis auf die unbestrittene Rolle dieser Tools für erfolgreiche DevSecOps-Praktiken und die zunehmende Relevanz in der Branche angesichts der wachsenden Mengen an Code mit potenziellen Sicherheitslücken.
Es gibt jedoch ein etwas merkwürdiges Problem. Fast die Hälfte aller Unternehmen liefert wissentlich angreifbaren Code aus, obwohl sie eine Reihe von AppSec-Tools einsetzen, die genau das verhindern sollen. Für Produkte mit einer unbestreitbaren Marktnachfrage, die schnell an Zugkraft gewinnt, macht das wenig Sinn. Warum kaufen sich so viele in ausgeklügelte Sicherheitstools ein, nur um deren Ergebnisse zu ignorieren oder sie gar nicht zu nutzen? Das ist ein bisschen so, als würde man ein Haus am Strand kaufen, nur um dann in einem Zelt im Wald zu schlafen.
Es gibt einige Gründe, warum AppSec-Tools nicht so genutzt werden, wie wir es vielleicht erwarten. Dabei geht es weniger um die Tools und ihre Funktionalität, sondern vielmehr darum, wie sie sich in ein Sicherheitsprogramm als Ganzes integrieren.
Mehr Werkzeuge sind nicht gleichbedeutend mit weniger Problemen.
Wenn Unternehmen ihre Softwareentwicklungsprozesse weiterentwickeln, von Agile über DevOps bis hin zum heiligen Nirwana DevSecOps (hey, für den Moment ist es das Beste, was wir haben), ist es unvermeidlich, dass auf dem Weg dorthin mehrere Scanner, Monitore, Firewalls und alle möglichen AppSec-Tools gekauft werden. Auch wenn es den Anschein hat, dass es ein Fall von "je mehr, desto besser" ist, führt dies sehr oft zu einem Tech-Stack, der Frankensteins Monster ähnelt, mit all der Unvorhersehbarkeit, die dies mit sich bringt.
Mit Budgets und Expertenressourcen, die für den Umfang der erforderlichen Arbeit zunehmend begrenzt sind, ist der Versuch, das Chaos zu beseitigen und den besten Tooling-Pfad für die Zukunft zu finden, eine entmutigende Aufgabe, und der Code, der gescannt und behoben werden muss, kommt einfach immer wieder. Es ist nicht verwunderlich, dass viele Unternehmen weiterhin Code ausliefern müssen, auch wenn dies ziemlich alarmierend ist und immer noch ein immenses Risiko für unsere Daten und unsere Privatsphäre darstellt.
Scanning-Tools sind langsam, was sich auf die Agilität von Releases auswirkt.
Sicherheit mit Geschwindigkeit zu erreichen, ist so etwas wie ein weißer Wal in der Softwareentwicklung, und die Wahrheit ist, dass wir immer noch versuchen, das richtig hinzubekommen, selbst wenn wir Organisationen dazu bringen, einen DevSecOps-orientierten Ansatz zu übernehmen. Akribisches, manuelles Code-Review mag in den 90er Jahren als Sicherheitsgarantie funktioniert haben, aber in einer Zeit, in der wir Hunderte von Milliarden Codezeilen produzieren, ist dieser Plan ungefähr so effektiv wie die Vorbereitung eines Fußballfeldes mit einer Nagelschere.
Scanning-Tools automatisieren den Prozess der Suche nach potenziellen Schwachstellen und übernehmen den Teil der akribischen Codeüberprüfung für uns. Das Problem ist, dass sie im Kontext einer CI/CD-Pipeline, die auf allen Zylindern läuft, immer noch langsam sind, und kein einziges Tool findet jede Schwachstelle. Es gibt auch ein paar eklatante Probleme mit den Ergebnissen, die nach einem Scan an das Sicherheitsteam ausgespuckt werden:
- Es gibt eine Menge falsch positiver (und negativer) Ergebnisse
- Irgendein armer Sicherheitsexperte muss immer noch dasitzen und eine manuelle Überprüfung durchführen, um die echten Bugs von den Phantom-Bugs zu trennen
- Oft werden viel zu viele allgemeine Schwachstellen aufgedeckt, die schon vor der Bereitstellung des Codes hätten erkannt werden müssen. Wollen Sie wirklich, dass Ihre sehr teuren Sicherheitsexperten von den großen, haarigen Sicherheitsproblemen mit dem Kleinkram abgelenkt werden?
- Scanner finden, sie beheben nicht.
Selbst in einer Organisation, die ihr Bestes tut, um nach den besten Praktiken der Cybersicherheit zu arbeiten und mit der Zeit zu gehen, um Sicherheit in jede Phase des Prozesses einzubeziehen, ist der oben beschriebene Prozess immer noch ein Showstopper, wenn Scanner die wichtigste Schutzmaßnahme sind und zu viele häufige Fehler das Team bei der Bereitstellung von sicherem Code behindern. Es liegt auf der Hand, dass hier an der falschen Stelle gespart wird, und zwar in der Regel in der Form, dass man sich auf das absolute Minimum an Tools verlässt, die unmöglich alle potenziellen Risiken abdecken können, selbst wenn man eine ganze Reihe von Lösungen gekauft hat.
Einige technisch geführte Automatisierungen können zu einer verminderten Codequalität führen
Scannen und Testen tragen die Hauptlast der automatisierten Prozesse im AppSec-Tooling, zusammen mit essenziellen Dingen wie Firewalls und Monitoring, aber andere gängige Tools können mit der Zeit unbeabsichtigt die praktischen Sicherheitsgrundlagen aushöhlen.
So wird beispielsweise die RASP-Technologie (Runtime Application Self-Protection) häufig eingesetzt, um die Sicherheitslage zu verbessern, ohne die Codierungsgeschwindigkeit zu beeinträchtigen. Sie arbeitet in der Laufzeitumgebung einer Anwendung und schützt vor böswilligen Code-Eingaben, Echtzeitangriffen und meldet jedes merkwürdige Ausführungsverhalten.
Es ist sicherlich ein zusätzlicher Schutz, aber wenn man es als Ausfallsicherung gegen potenzielle Schwachstellen in der Codebasis betrachtet, können Entwickler selbstgefällig werden, besonders wenn sie mit immer unmöglicheren Terminen für die Markteinführung neuer Funktionen konfrontiert werden. Sichere Coding-Praktiken werden möglicherweise nicht befolgt, in der Annahme, dass der Selbstschutz zur Laufzeit alle Fehler erkennen wird. Entwickler machen sich nicht die Mühe, unsichere Codierungsmuster zu erstellen, aber die Sicherheit wird oft zugunsten der Bereitstellung von Funktionen zurückgestellt, vor allem in der Annahme, dass es einen automatischen Schutz gibt.
Tools können versagen (und laufen im Fall von RASP oft im Überwachungsmodus, um False Positives zu vermeiden, was wiederum nur Sichtbarkeit - aber keinen Schutz - vor einem Angriff bietet), und wenn das passiert, ist es hochwertiger, sicherer Code, auf den man sich jedes Mal verlassen kann. Sicherheitsbewusstsein in jeder Rolle, die mit Code in Berührung kommt, ist grundlegend für DevSecOps, und Entwickler, die keinen sicheren Code trainieren oder produzieren, machen einen Fehler. Das Schreiben von sicherem und unsicherem Code erfordert den gleichen Aufwand; es ist die Aneignung des Wissens, um sicher zu codieren, die die wirkliche Energie erfordert. Die Zeit, die für die Implementierung und Optimierung von RASP aufgewendet wird, kann viel besser für die Weiterbildung von Entwicklern genutzt werden, damit diese den Fehler gar nicht erst machen.
Das Gleichgewicht zwischen Werkzeugen und Menschen: Es ist kein Allheilmittel, aber es kommt dem am nächsten (im Moment).
Das Hauptethos von DevSecOps besteht darin, Sicherheit zu einer gemeinsamen Verantwortung zu machen. Unternehmen, die die Software entwickeln, die unser Leben bestimmt - vom Stromnetz bis hin zu unseren Türklingeln - müssen alle Beteiligten mit einbeziehen, um ein höheres Maß an Sicherheit zu gewährleisten.
Mit Tools lässt sich nicht alles erreichen, und es ist nicht einmal der billigste Weg. Die bei weitem besten Ergebnisse werden erzielt, indem man relevante Sicherheitsschulungen für jeden, der mit Code in Berührung kommt, priorisiert, aktiv daran arbeitet, die Sicherheit für das Entwicklungsteam in den Vordergrund zu stellen, und eine positive Sicherheitskultur aufbaut, die von Menschen geführt wird, wobei eine Tooling-Suite eine unterstützende Rolle spielt.
Selbst angesichts von Zeitbeschränkungen, abgeschnittenen Ecken und anderen Dingen, die Sicherheitsexperten nachts den Schlaf rauben, stellen diese Tools (und ob sie nun verwendet werden oder nicht) einen weitaus geringeren Risikofaktor dar, wenn die Entwickler gängige Sicherheitsmängel gar nicht erst einführen.
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
In diesem Monat des Cyber-Bewusstseins wird aus Bewusstsein Handeln
Lassen Sie diesen Oktober das Bewusstsein in Aktion treten. Machen Sie den Cyber Awareness Month für Ihre Entwickler zu einem denkwürdigen Ereignis mit großer Wirkung und hoher Beteiligung - geleitet vom Secure Code Warrior Professional Services Team.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Ressourcen für den Einstieg
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Das Jahrzehnt der Defenders: Secure Code Warrior Zehnte Runde
Secure Code WarriorDas Gründungsteam von SCW ist zusammengeblieben und hat das Schiff ein ganzes Jahrzehnt lang durch alle Lektionen, Triumphe und Rückschläge gesteuert. Wir vergrößern uns und sind bereit für unser nächstes Kapitel, SCW 2.0, als führendes Unternehmen im Risikomanagement für Entwickler.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
