Así que creo que uno de los retos a los que nos enfrentamos en el desarrollo de software y la seguridad, es que hemos estado viendo las mismas o actuales vulnerabilidades de software durante los últimos 20 años. Tanto si se utiliza el análisis de código estático, como si se utilizan evaluaciones de vulnerabilidad o pruebas de penetración, los mismos problemas se repiten en diferentes tecnologías y diferentes partes del código. 

Y creo que el segundo desafío que tenemos, ya sea que estés usando el análisis de código estático o usando evaluaciones de vulnerabilidad y pruebas de penetración, es que estas tecnologías a menudo sólo señalan un problema, y no te dan realmente soluciones prácticas y cómo arreglar las cosas. Y creo que esa es una de las razones por las que necesitamos pasar de la reacción a la prevención, porque sabemos que no sólo queremos prevenir la recurrencia de los problemas de seguridad del software, sino que también queremos resolverlos muy rápidamente en el ciclo de desarrollo del software. 

Una de las cosas que intentamos hacer en Secure Code Warrior es integrarnos en los procesos de desarrollo y en las herramientas del desarrollador, porque queremos ser muy relevantes y contextuales para ese desarrollador de software. Queremos estar ahí para ayudarles a entrenar y guiar el problema real. Un ejemplo es la integración en los sistemas de tickets. Queremos estar en ese sistema de tickets, cuando se presente un error de seguridad, ya sea por una herramienta de análisis de código estático, o sobre las pruebas de pluma, queremos estar allí, con el desarrollador con algunos patrones de codificación pertinentes y la información sobre cómo se puede ahora solucionar rápidamente este problema en su lenguaje de codificación específico. Y de esta manera, queremos hacernos realmente contextuales, y estar allí para el desarrollador, cuando él o ella realmente lo necesita. Con tecnología como sensei, queremos ser realmente contextuales dentro del IDE del desarrollador. Y cuando nos demos cuenta de que un recién contratado o un desarrollador junior está realizando o utilizando prácticas de codificación que podrían conducir a una vulnerabilidad de seguridad, queremos estar ahí, no sólo para detectar el problema y formarle en el acto, sino que queremos ser capaces de ofrecerle orientación sobre cómo solucionarlo rápidamente, e incluso reescribir automáticamente el código por él dentro de su IDE. De este modo, queremos ser hiperrelevantes en el contexto y también ofrecer soluciones al desarrollador en su propio lenguaje de codificación sobre cómo corregir y producir código seguro en sus equipos. 

Así que nuestro objetivo final es construir la seguridad en el ADN de un desarrollador. No queremos cambiar a la izquierda, estamos empezando a la izquierda. Queremos ayudar al desarrollador y capacitarlo para que escriba código seguro desde el principio. Y es por eso que construimos un entorno en el que proporcionamos experiencias de aprendizaje prácticas y divertidas, que son específicas para la codificación y el lenguaje, que un desarrollador utiliza. Porque queremos hacer de la seguridad algo que se construya, positivo y una experiencia divertida para el desarrollador, para que pueda escribir código seguro a la velocidad.

Entonces, ¿por qué los desarrolladores aman Secure Code Warrior? Bueno, en primer lugar, porque básicamente les ayudamos a mejorar sus habilidades en su propio lenguaje de codificación y el marco, si usted es un desarrollador frontal que está codificando en reaccionar o un desarrollador móvil que está haciendo Java o swift, o incluso los desarrolladores de la vieja escuela que se centran en COBOL, RPG, o Java y C #, básicamente hemos construido una biblioteca de contenido en su lenguaje de codificación y el marco específico, para que podamos ayudarle de una manera práctica, entender y hacer la seguridad algo que no es miedo y algo que es realmente divertido de aprender.