Übergang von der Reaktion zur Prävention

Ich denke, eine der Herausforderungen, vor denen wir in der Softwareentwicklung und Sicherheit stehen, besteht darin, dass wir in den letzten 20 Jahren dieselben oder aktuelle Softwareschwachstellen gesehen haben. Ganz gleich, ob Sie statische Codeanalysen verwenden, ob Sie Schwachstellenanalysen oder Penetrationstests durchführen, dieselben Probleme treten bei verschiedenen Technologien und verschiedenen Teilen des Codes immer wieder auf.

Und ich denke, die zweite Herausforderung, vor der wir stehen, ob Sie nun statische Codeanalysen oder Schwachstellenanalysen und Penetrationstests verwenden, besteht darin, dass diese Technologien oft nur auf ein Problem hinweisen und Ihnen nicht wirklich praktische Lösungen und Problemlösungen bieten. Und ich denke, das ist einer der Gründe, warum wir von der Reaktion zur Prävention übergehen müssen, weil wir wissen, dass wir nicht nur das wiederkehrende Softwaresicherheitsproblem verhindern wollen, sondern dass wir es auch sehr schnell im Softwareentwicklungszyklus lösen wollen.

Eines der Dinge, die wir bei Secure Code Warrior wirklich versuchen, ist die Integration in die Entwicklungsprozesse und Tools des Entwicklers, weil wir für diesen Softwareentwickler hyperrelevant und kontextbezogen sein wollen. Wir wollen da sein, um ihnen beim Coaching und bei der Lösung des eigentlichen Problems zu helfen. Ein Beispiel ist die Integration in Ticketsysteme. Wir wollen in diesem Ticketsystem sein, wenn eine Sicherheitslücke gemeldet wird, sei es durch ein statisches Codeanalyse-Tool oder durch Pen-Tests, wir wollen da sein, zusammen mit dem Entwickler mit einigen relevanten Codierungsmustern und Informationen, wie Sie dieses Problem jetzt schnell in Ihrer spezifischen Programmiersprache beheben können. Und auf diese Weise wollen wir wirklich kontextuell sein und für den Entwickler da sein, wenn er oder sie es wirklich braucht. Mit Technologien wie Sensei wollen wir eigentlich innerhalb der IDE des Entwicklers kontextbezogen sein. Und wenn wir feststellen, dass ein neuer Mitarbeiter oder ein junger Entwickler Programmierpraktiken entwickelt oder verwendet, die zu einer Sicherheitslücke führen würden, wollen wir tatsächlich da sein, um das Problem nicht nur zu erkennen und sie vor Ort zu schulen, sondern wir wollen ihnen auch Anleitungen geben können, wie sie es schnell beheben können, und sogar den Code für sie automatisch in ihrer IDE neu schreiben können. Auf diese Weise wollen wir hyperrelevant sein und Entwicklern in ihrer eigenen Programmiersprache auch Lösungen anbieten, wie sie sicheren Code in ihren Teams reparieren und produzieren können.

Unser oberstes Ziel ist es also, Sicherheit in die DNA eines Entwicklers zu integrieren. Wir wollen nicht links abbiegen, wir fangen links an. Wir wollen den Entwicklern helfen und sie befähigen, von Anfang an sicheren Code zu schreiben. Und deshalb schaffen wir eine Umgebung, in der wir praxisnahes Gamify und unterhaltsame Lernerlebnisse bieten, die spezifisch für die Codierung und Sprache sind, die ein Entwickler verwendet. Weil wir Sicherheit zu einer aufbauenden, positiven und unterhaltsamen Erfahrung für Entwickler machen wollen, damit sie schnell sicheren Code schreiben können.

Warum lieben Entwickler Secure Code Warrior? Zunächst einmal, weil wir ihnen im Grunde helfen, ihre Fähigkeiten in ihrer eigenen Programmiersprache und ihrem eigenen Framework zu verbessern, egal ob Sie ein Frontend-Entwickler sind, der in React codiert, oder ein mobiler Entwickler, der Java oder Swift verwendet, oder sogar Old-School-Entwickler, die sich auf COBOL, RPG oder Java und C# konzentrieren, haben wir im Grunde eine Bibliothek mit Inhalten in Ihrer spezifischen Programmiersprache und Ihrem Framework erstellt, damit wir Ihnen auf praktische Weise helfen können, sie zu verstehen und zu machen Sicherheit — etwas, das nicht gruselig ist und über das es wirklich Spaß macht, etwas zu lernen.