¿Su organización está realmente preparada para DevSec? Póngalo a prueba.
Apenas estamos a la mitad de 2020 y, sin embargo, ya estamos en camino de establecer un sombrío récord de violaciones de datos, viendo un aumento del 273% en los datos robados en comparación con el primer semestre de 2019. Hoy en día, es más preciso preguntar cuántos datos no ha ha sido robada todavía. Con acontecimientos mundiales como la pandemia de la COVID-19, estos ataques no han hecho más que aumentar en frecuencia y potencia, y los objetivos son cada vez más vulnerables.
Esto es algo que todos sabemos desde hace tiempo: la seguridad ya no es opcional y debemos centrarnos en un ataque preventivo. Para que sea efectivo, todos en el SDLC deben ser conscientes de la seguridad, especialmente los desarrolladores. Esta es la parte «DevSec» de DevSecOps, una metodología de desarrollo de software ideal para el clima, pero muchas organizaciones no están totalmente preparadas para ejecutarla de manera eficaz.
Con su organización en mente, piense en estas preguntas en el contexto de su función. ¿Cómo le iría cuando se sometiera a la prueba de DevSec?
Autoevaluación de DevSec: ¿Está su jardín de SDLC preparado para que florezcan los ingenieros preocupados por la seguridad?
- ¿La seguridad es una prioridad en el proceso de desarrollo interno?
Es posible que una serie de factores de riesgo de ciberseguridad mantengan despierto al CISO promedio por la noche, pero la preocupante realidad es que, si bien muchas empresas dan más prioridad a la seguridad, es posible que su enfoque interno no sea lo suficientemente sólido como para mitigar posibles desastres (o, al menos, los enormes quebraderos de cabeza para el equipo de AppSec y el retraso en el envío del software).
DevSecOps puede ser el estado actual del nirvana de seguridad, pero pocas empresas trabajan con esta metodología. Si aún usas Agile (o incluso Waterfall), la seguridad sigue considerándose como un dominio de especialistas que están muy alejados del proceso y se activan al final del SDLC, apareciendo para arruinarle el día a un desarrollador con correcciones para su código. En un entorno como este, va a ser difícil impulsar una cultura de DevSec: a los desarrolladores les encanta la creación de funciones y la priorizan, y simplemente no habrán tenido suficiente experiencia práctica con la seguridad como para considerarla una vía de mejora de habilidades deseable. De hecho, sus puntos de contacto con ella pueden ser los de frustración y negatividad. Esto debe solucionarse rápidamente para inculcar un enfoque prioritario a todos los involucrados en el proceso de desarrollo de software.
- ¿Su organización sigue intentando ponerse al día en lo que respecta al modelado de amenazas?
Es una estadística aleccionadora que El 60% de las pymes cierra en un plazo de seis meses tras un ciberataque exitoso, y al igual que otros desastres, el impacto es mucho mayor sin una planificación adecuada.
El modelado de amenazas es un elemento crucial de las mejores prácticas de seguridad, ya que permite a los profesionales de AppSec evaluar el alcance total de la superficie de ataque y estructurar las defensas, las contramedidas y la planificación adecuadas. En las empresas que han adoptado DevSecOps por completo, la seguridad se habilita en las primeras etapas del proceso de CI/CD, de forma que no se ralentice la producción tanto como en el pasado. La seguridad, la codificación segura y la entrega continua forman parte del proceso, y los equipos de desarrollo cuentan con los recursos y la exposición necesarios para convertirse en los principales componentes del motor que produce código hermético.
- ¿Los gerentes de desarrollo dan prioridad a las mejores prácticas de seguridad?
Les guste o no, los gerentes de desarrollo son modelos a seguir para su equipo. Y no es solo por cuestiones relacionadas con la cultura y el ambiente, como llevar chanclas en la oficina o cómo «se las arreglan para ascender». Inevitablemente, sus prioridades laborales serán absorbidas por los miembros de su equipo, y si la seguridad no forma parte de los objetivos clave ni se planifica desde el punto de vista de la formación y el soporte, los ingenieros que están detrás de ellos se quedarán perdiendo la oportunidad y la empresa correrá más riesgos de lo que debería.
- ¿Se les da a los desarrolladores una razón para preocuparse por la seguridad?
Según mi experiencia, la forma más rápida de poner a alguien fuera de juego es decirle que tiene que hacer algo que es ajeno a su enfoque actual, sin decirle por qué.
Que te digan que «cambies» implica que el enfoque anterior era incorrecto, cuando en muchos casos se trata simplemente de una mejora que, con suerte, hará las cosas más fáciles y eficientes más adelante. Para abrazar realmente el movimiento DevSec, los desarrolladores deben tener una razón para preocuparse por la seguridad en primer lugar; al fin y al cabo, en la mayoría de las organizaciones, sigue siendo en gran medida «un problema de otra persona» (es decir, los magos de AppSec encerrados en otra habitación, muy, muy lejos).
DevSecOps simplemente no funciona si la seguridad no es una responsabilidad compartida. Los desarrolladores necesitan las herramientas, el soporte y la formación adecuados para hacer su parte... y esto requiere tiempo para implementarlo y perfeccionarlo como parte de un programa de seguridad general. El peor enfoque es el que abruma y aleja, lo que puede ocurrir cuando los desarrolladores tienen demasiadas prioridades que compiten entre sí y carecen de ayuda para gestionarlas sin volverse locos. Se trata de un cambio cultural y no ocurre de la noche a la mañana.
- ¿Confías en un puñado de unicornios mágicos de seguridad para asumir la tarea de muchos?
Los profesionales de la seguridad están en suministro muy escaso, y necesitamos mucho más de lo que está disponible actualmente. Eso es un hecho, pero cada vez hay más desarrolladores que adoptan funciones más centradas en la seguridad. Por lo general, pueden aparecer bajo títulos como «ingeniero de seguridad» o «ingeniero de DevOps» (poco a poco, veremos cómo este título se transforma en Ingeniero de DevSecOps, ¡con un poco de suerte!). Un ingeniero de DevOps con armas es capaz de desarrollar funciones para prácticamente cualquier aplicación y, al mismo tiempo, implementarlas utilizando una verdadera canalización de CI/CD. Lo hacen todo de principio a fin y, por lo general, vienen con una buena dosis de conciencia sobre la seguridad. En ese sentido, son algo mágicos y, por lo tanto, raros.
Sin embargo, algunas empresas cometen el error de contratar a estos ingenieros especializados, unirlos en un equipo y esperar que se enfrenten a todos los problemas de seguridad en cada etapa del proceso de desarrollo, y esto por sí solo es la panacea. Si sobrecargas a tus magos de DevSecOps, acabarás donde empezaste: publicando código inseguro sin los controles, contrapesos y precisión de seguridad para los que fueron contratados en primer lugar. Es de suma importancia que el equipo de desarrollo, en general, esté cualificado y formado en un entorno de seguridad positivo, de forma que esté preparado para compartir la carga de forma significativa.
Busca el cambio que quieres ver en tu organización.
Si implementas una formación sólida como parte de tu programa de seguridad, descubrirás algunas joyas ocultas en tu cohorte de desarrollo. Estas son las personas que, a pesar de las experiencias negativas que puedan haber tenido en su trabajo diario, sienten cierta pasión por la codificación segura y las mejores prácticas de seguridad. Estas personas son las principales candidatas para convertirse en campeones de la seguridad dentro del equipo; son un punto de contacto entre la seguridad y la ingeniería que da un gran ejemplo a los demás, mantiene la concienciación al respecto y ayuda con las iniciativas de participación. Sus habilidades interpersonales también son muy importantes para difundir el entusiasmo por la seguridad y para defender las necesidades de los desarrolladores ante la dirección y el equipo de seguridad.
El «¿qué hay para mí?» la conversación es un paso adelante positivo.
Incluso los humanos más nobles necesitan algo parecido a una «zanahoria» para sumergirse en un territorio desconocido, o una actividad que tal vez no tenga las curvas de aprendizaje más agradables.
Dar el salto de «dev» a «DevSec» supone un gran impulso para la carrera de un desarrollador. Los desarrolladores preocupados por la seguridad han trabajado arduamente para entender la seguridad, asumir la responsabilidad en las áreas que pueden controlar y operar con el entendimiento de que el único código de calidad es el código seguro. Por lo general, los desarrolladores quieren mejorar, abordar nuevos problemas y crear funciones envidiables que les ayuden a destacar entre sus pares. Bríndeles una vía para alcanzar un nivel superior de desarrollo de software y es una situación en la que todos salen ganando.
Nunca es demasiado tarde para crear el equipo de DevSec de tus sueños.
Si dirige desarrolladores, dirige un equipo de concienciación sobre AppSec o es una de las muchas mentes que trabajan arduamente para diseñar estrategias de programas de seguridad, ahora es el momento de ir mejor que «girar» a la izquierda. Con la formación, las herramientas y el entorno adecuados, puede crear una incubadora de seguridad para desarrolladores que generará grandes beneficios para todas las partes. Si en esta lista de verificación se destacan algunas áreas que pueden mejorarse, es una gran oportunidad para preparar a su organización para contar con un departamento de ingeniería dirigido por DevSec que pueda reducir los riesgos desde el principio del SDLC.
Con su organización en mente, piense en estas preguntas en el contexto de su función. ¿Cómo le iría cuando se sometiera a la prueba de DevSec?
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Apenas estamos a la mitad de 2020 y, sin embargo, ya estamos en camino de establecer un sombrío récord de violaciones de datos, viendo un aumento del 273% en los datos robados en comparación con el primer semestre de 2019. Hoy en día, es más preciso preguntar cuántos datos no ha ha sido robada todavía. Con acontecimientos mundiales como la pandemia de la COVID-19, estos ataques no han hecho más que aumentar en frecuencia y potencia, y los objetivos son cada vez más vulnerables.
Esto es algo que todos sabemos desde hace tiempo: la seguridad ya no es opcional y debemos centrarnos en un ataque preventivo. Para que sea efectivo, todos en el SDLC deben ser conscientes de la seguridad, especialmente los desarrolladores. Esta es la parte «DevSec» de DevSecOps, una metodología de desarrollo de software ideal para el clima, pero muchas organizaciones no están totalmente preparadas para ejecutarla de manera eficaz.
Con su organización en mente, piense en estas preguntas en el contexto de su función. ¿Cómo le iría cuando se sometiera a la prueba de DevSec?
Autoevaluación de DevSec: ¿Está su jardín de SDLC preparado para que florezcan los ingenieros preocupados por la seguridad?
- ¿La seguridad es una prioridad en el proceso de desarrollo interno?
Es posible que una serie de factores de riesgo de ciberseguridad mantengan despierto al CISO promedio por la noche, pero la preocupante realidad es que, si bien muchas empresas dan más prioridad a la seguridad, es posible que su enfoque interno no sea lo suficientemente sólido como para mitigar posibles desastres (o, al menos, los enormes quebraderos de cabeza para el equipo de AppSec y el retraso en el envío del software).
DevSecOps puede ser el estado actual del nirvana de seguridad, pero pocas empresas trabajan con esta metodología. Si aún usas Agile (o incluso Waterfall), la seguridad sigue considerándose como un dominio de especialistas que están muy alejados del proceso y se activan al final del SDLC, apareciendo para arruinarle el día a un desarrollador con correcciones para su código. En un entorno como este, va a ser difícil impulsar una cultura de DevSec: a los desarrolladores les encanta la creación de funciones y la priorizan, y simplemente no habrán tenido suficiente experiencia práctica con la seguridad como para considerarla una vía de mejora de habilidades deseable. De hecho, sus puntos de contacto con ella pueden ser los de frustración y negatividad. Esto debe solucionarse rápidamente para inculcar un enfoque prioritario a todos los involucrados en el proceso de desarrollo de software.
- ¿Su organización sigue intentando ponerse al día en lo que respecta al modelado de amenazas?
Es una estadística aleccionadora que El 60% de las pymes cierra en un plazo de seis meses tras un ciberataque exitoso, y al igual que otros desastres, el impacto es mucho mayor sin una planificación adecuada.
El modelado de amenazas es un elemento crucial de las mejores prácticas de seguridad, ya que permite a los profesionales de AppSec evaluar el alcance total de la superficie de ataque y estructurar las defensas, las contramedidas y la planificación adecuadas. En las empresas que han adoptado DevSecOps por completo, la seguridad se habilita en las primeras etapas del proceso de CI/CD, de forma que no se ralentice la producción tanto como en el pasado. La seguridad, la codificación segura y la entrega continua forman parte del proceso, y los equipos de desarrollo cuentan con los recursos y la exposición necesarios para convertirse en los principales componentes del motor que produce código hermético.
- ¿Los gerentes de desarrollo dan prioridad a las mejores prácticas de seguridad?
Les guste o no, los gerentes de desarrollo son modelos a seguir para su equipo. Y no es solo por cuestiones relacionadas con la cultura y el ambiente, como llevar chanclas en la oficina o cómo «se las arreglan para ascender». Inevitablemente, sus prioridades laborales serán absorbidas por los miembros de su equipo, y si la seguridad no forma parte de los objetivos clave ni se planifica desde el punto de vista de la formación y el soporte, los ingenieros que están detrás de ellos se quedarán perdiendo la oportunidad y la empresa correrá más riesgos de lo que debería.
- ¿Se les da a los desarrolladores una razón para preocuparse por la seguridad?
Según mi experiencia, la forma más rápida de poner a alguien fuera de juego es decirle que tiene que hacer algo que es ajeno a su enfoque actual, sin decirle por qué.
Que te digan que «cambies» implica que el enfoque anterior era incorrecto, cuando en muchos casos se trata simplemente de una mejora que, con suerte, hará las cosas más fáciles y eficientes más adelante. Para abrazar realmente el movimiento DevSec, los desarrolladores deben tener una razón para preocuparse por la seguridad en primer lugar; al fin y al cabo, en la mayoría de las organizaciones, sigue siendo en gran medida «un problema de otra persona» (es decir, los magos de AppSec encerrados en otra habitación, muy, muy lejos).
DevSecOps simplemente no funciona si la seguridad no es una responsabilidad compartida. Los desarrolladores necesitan las herramientas, el soporte y la formación adecuados para hacer su parte... y esto requiere tiempo para implementarlo y perfeccionarlo como parte de un programa de seguridad general. El peor enfoque es el que abruma y aleja, lo que puede ocurrir cuando los desarrolladores tienen demasiadas prioridades que compiten entre sí y carecen de ayuda para gestionarlas sin volverse locos. Se trata de un cambio cultural y no ocurre de la noche a la mañana.
- ¿Confías en un puñado de unicornios mágicos de seguridad para asumir la tarea de muchos?
Los profesionales de la seguridad están en suministro muy escaso, y necesitamos mucho más de lo que está disponible actualmente. Eso es un hecho, pero cada vez hay más desarrolladores que adoptan funciones más centradas en la seguridad. Por lo general, pueden aparecer bajo títulos como «ingeniero de seguridad» o «ingeniero de DevOps» (poco a poco, veremos cómo este título se transforma en Ingeniero de DevSecOps, ¡con un poco de suerte!). Un ingeniero de DevOps con armas es capaz de desarrollar funciones para prácticamente cualquier aplicación y, al mismo tiempo, implementarlas utilizando una verdadera canalización de CI/CD. Lo hacen todo de principio a fin y, por lo general, vienen con una buena dosis de conciencia sobre la seguridad. En ese sentido, son algo mágicos y, por lo tanto, raros.
Sin embargo, algunas empresas cometen el error de contratar a estos ingenieros especializados, unirlos en un equipo y esperar que se enfrenten a todos los problemas de seguridad en cada etapa del proceso de desarrollo, y esto por sí solo es la panacea. Si sobrecargas a tus magos de DevSecOps, acabarás donde empezaste: publicando código inseguro sin los controles, contrapesos y precisión de seguridad para los que fueron contratados en primer lugar. Es de suma importancia que el equipo de desarrollo, en general, esté cualificado y formado en un entorno de seguridad positivo, de forma que esté preparado para compartir la carga de forma significativa.
Busca el cambio que quieres ver en tu organización.
Si implementas una formación sólida como parte de tu programa de seguridad, descubrirás algunas joyas ocultas en tu cohorte de desarrollo. Estas son las personas que, a pesar de las experiencias negativas que puedan haber tenido en su trabajo diario, sienten cierta pasión por la codificación segura y las mejores prácticas de seguridad. Estas personas son las principales candidatas para convertirse en campeones de la seguridad dentro del equipo; son un punto de contacto entre la seguridad y la ingeniería que da un gran ejemplo a los demás, mantiene la concienciación al respecto y ayuda con las iniciativas de participación. Sus habilidades interpersonales también son muy importantes para difundir el entusiasmo por la seguridad y para defender las necesidades de los desarrolladores ante la dirección y el equipo de seguridad.
El «¿qué hay para mí?» la conversación es un paso adelante positivo.
Incluso los humanos más nobles necesitan algo parecido a una «zanahoria» para sumergirse en un territorio desconocido, o una actividad que tal vez no tenga las curvas de aprendizaje más agradables.
Dar el salto de «dev» a «DevSec» supone un gran impulso para la carrera de un desarrollador. Los desarrolladores preocupados por la seguridad han trabajado arduamente para entender la seguridad, asumir la responsabilidad en las áreas que pueden controlar y operar con el entendimiento de que el único código de calidad es el código seguro. Por lo general, los desarrolladores quieren mejorar, abordar nuevos problemas y crear funciones envidiables que les ayuden a destacar entre sus pares. Bríndeles una vía para alcanzar un nivel superior de desarrollo de software y es una situación en la que todos salen ganando.
Nunca es demasiado tarde para crear el equipo de DevSec de tus sueños.
Si dirige desarrolladores, dirige un equipo de concienciación sobre AppSec o es una de las muchas mentes que trabajan arduamente para diseñar estrategias de programas de seguridad, ahora es el momento de ir mejor que «girar» a la izquierda. Con la formación, las herramientas y el entorno adecuados, puede crear una incubadora de seguridad para desarrolladores que generará grandes beneficios para todas las partes. Si en esta lista de verificación se destacan algunas áreas que pueden mejorarse, es una gran oportunidad para preparar a su organización para contar con un departamento de ingeniería dirigido por DevSec que pueda reducir los riesgos desde el principio del SDLC.
Apenas estamos a la mitad de 2020 y, sin embargo, ya estamos en camino de establecer un sombrío récord de violaciones de datos, viendo un aumento del 273% en los datos robados en comparación con el primer semestre de 2019. Hoy en día, es más preciso preguntar cuántos datos no ha ha sido robada todavía. Con acontecimientos mundiales como la pandemia de la COVID-19, estos ataques no han hecho más que aumentar en frecuencia y potencia, y los objetivos son cada vez más vulnerables.
Esto es algo que todos sabemos desde hace tiempo: la seguridad ya no es opcional y debemos centrarnos en un ataque preventivo. Para que sea efectivo, todos en el SDLC deben ser conscientes de la seguridad, especialmente los desarrolladores. Esta es la parte «DevSec» de DevSecOps, una metodología de desarrollo de software ideal para el clima, pero muchas organizaciones no están totalmente preparadas para ejecutarla de manera eficaz.
Con su organización en mente, piense en estas preguntas en el contexto de su función. ¿Cómo le iría cuando se sometiera a la prueba de DevSec?
Autoevaluación de DevSec: ¿Está su jardín de SDLC preparado para que florezcan los ingenieros preocupados por la seguridad?
- ¿La seguridad es una prioridad en el proceso de desarrollo interno?
Es posible que una serie de factores de riesgo de ciberseguridad mantengan despierto al CISO promedio por la noche, pero la preocupante realidad es que, si bien muchas empresas dan más prioridad a la seguridad, es posible que su enfoque interno no sea lo suficientemente sólido como para mitigar posibles desastres (o, al menos, los enormes quebraderos de cabeza para el equipo de AppSec y el retraso en el envío del software).
DevSecOps puede ser el estado actual del nirvana de seguridad, pero pocas empresas trabajan con esta metodología. Si aún usas Agile (o incluso Waterfall), la seguridad sigue considerándose como un dominio de especialistas que están muy alejados del proceso y se activan al final del SDLC, apareciendo para arruinarle el día a un desarrollador con correcciones para su código. En un entorno como este, va a ser difícil impulsar una cultura de DevSec: a los desarrolladores les encanta la creación de funciones y la priorizan, y simplemente no habrán tenido suficiente experiencia práctica con la seguridad como para considerarla una vía de mejora de habilidades deseable. De hecho, sus puntos de contacto con ella pueden ser los de frustración y negatividad. Esto debe solucionarse rápidamente para inculcar un enfoque prioritario a todos los involucrados en el proceso de desarrollo de software.
- ¿Su organización sigue intentando ponerse al día en lo que respecta al modelado de amenazas?
Es una estadística aleccionadora que El 60% de las pymes cierra en un plazo de seis meses tras un ciberataque exitoso, y al igual que otros desastres, el impacto es mucho mayor sin una planificación adecuada.
El modelado de amenazas es un elemento crucial de las mejores prácticas de seguridad, ya que permite a los profesionales de AppSec evaluar el alcance total de la superficie de ataque y estructurar las defensas, las contramedidas y la planificación adecuadas. En las empresas que han adoptado DevSecOps por completo, la seguridad se habilita en las primeras etapas del proceso de CI/CD, de forma que no se ralentice la producción tanto como en el pasado. La seguridad, la codificación segura y la entrega continua forman parte del proceso, y los equipos de desarrollo cuentan con los recursos y la exposición necesarios para convertirse en los principales componentes del motor que produce código hermético.
- ¿Los gerentes de desarrollo dan prioridad a las mejores prácticas de seguridad?
Les guste o no, los gerentes de desarrollo son modelos a seguir para su equipo. Y no es solo por cuestiones relacionadas con la cultura y el ambiente, como llevar chanclas en la oficina o cómo «se las arreglan para ascender». Inevitablemente, sus prioridades laborales serán absorbidas por los miembros de su equipo, y si la seguridad no forma parte de los objetivos clave ni se planifica desde el punto de vista de la formación y el soporte, los ingenieros que están detrás de ellos se quedarán perdiendo la oportunidad y la empresa correrá más riesgos de lo que debería.
- ¿Se les da a los desarrolladores una razón para preocuparse por la seguridad?
Según mi experiencia, la forma más rápida de poner a alguien fuera de juego es decirle que tiene que hacer algo que es ajeno a su enfoque actual, sin decirle por qué.
Que te digan que «cambies» implica que el enfoque anterior era incorrecto, cuando en muchos casos se trata simplemente de una mejora que, con suerte, hará las cosas más fáciles y eficientes más adelante. Para abrazar realmente el movimiento DevSec, los desarrolladores deben tener una razón para preocuparse por la seguridad en primer lugar; al fin y al cabo, en la mayoría de las organizaciones, sigue siendo en gran medida «un problema de otra persona» (es decir, los magos de AppSec encerrados en otra habitación, muy, muy lejos).
DevSecOps simplemente no funciona si la seguridad no es una responsabilidad compartida. Los desarrolladores necesitan las herramientas, el soporte y la formación adecuados para hacer su parte... y esto requiere tiempo para implementarlo y perfeccionarlo como parte de un programa de seguridad general. El peor enfoque es el que abruma y aleja, lo que puede ocurrir cuando los desarrolladores tienen demasiadas prioridades que compiten entre sí y carecen de ayuda para gestionarlas sin volverse locos. Se trata de un cambio cultural y no ocurre de la noche a la mañana.
- ¿Confías en un puñado de unicornios mágicos de seguridad para asumir la tarea de muchos?
Los profesionales de la seguridad están en suministro muy escaso, y necesitamos mucho más de lo que está disponible actualmente. Eso es un hecho, pero cada vez hay más desarrolladores que adoptan funciones más centradas en la seguridad. Por lo general, pueden aparecer bajo títulos como «ingeniero de seguridad» o «ingeniero de DevOps» (poco a poco, veremos cómo este título se transforma en Ingeniero de DevSecOps, ¡con un poco de suerte!). Un ingeniero de DevOps con armas es capaz de desarrollar funciones para prácticamente cualquier aplicación y, al mismo tiempo, implementarlas utilizando una verdadera canalización de CI/CD. Lo hacen todo de principio a fin y, por lo general, vienen con una buena dosis de conciencia sobre la seguridad. En ese sentido, son algo mágicos y, por lo tanto, raros.
Sin embargo, algunas empresas cometen el error de contratar a estos ingenieros especializados, unirlos en un equipo y esperar que se enfrenten a todos los problemas de seguridad en cada etapa del proceso de desarrollo, y esto por sí solo es la panacea. Si sobrecargas a tus magos de DevSecOps, acabarás donde empezaste: publicando código inseguro sin los controles, contrapesos y precisión de seguridad para los que fueron contratados en primer lugar. Es de suma importancia que el equipo de desarrollo, en general, esté cualificado y formado en un entorno de seguridad positivo, de forma que esté preparado para compartir la carga de forma significativa.
Busca el cambio que quieres ver en tu organización.
Si implementas una formación sólida como parte de tu programa de seguridad, descubrirás algunas joyas ocultas en tu cohorte de desarrollo. Estas son las personas que, a pesar de las experiencias negativas que puedan haber tenido en su trabajo diario, sienten cierta pasión por la codificación segura y las mejores prácticas de seguridad. Estas personas son las principales candidatas para convertirse en campeones de la seguridad dentro del equipo; son un punto de contacto entre la seguridad y la ingeniería que da un gran ejemplo a los demás, mantiene la concienciación al respecto y ayuda con las iniciativas de participación. Sus habilidades interpersonales también son muy importantes para difundir el entusiasmo por la seguridad y para defender las necesidades de los desarrolladores ante la dirección y el equipo de seguridad.
El «¿qué hay para mí?» la conversación es un paso adelante positivo.
Incluso los humanos más nobles necesitan algo parecido a una «zanahoria» para sumergirse en un territorio desconocido, o una actividad que tal vez no tenga las curvas de aprendizaje más agradables.
Dar el salto de «dev» a «DevSec» supone un gran impulso para la carrera de un desarrollador. Los desarrolladores preocupados por la seguridad han trabajado arduamente para entender la seguridad, asumir la responsabilidad en las áreas que pueden controlar y operar con el entendimiento de que el único código de calidad es el código seguro. Por lo general, los desarrolladores quieren mejorar, abordar nuevos problemas y crear funciones envidiables que les ayuden a destacar entre sus pares. Bríndeles una vía para alcanzar un nivel superior de desarrollo de software y es una situación en la que todos salen ganando.
Nunca es demasiado tarde para crear el equipo de DevSec de tus sueños.
Si dirige desarrolladores, dirige un equipo de concienciación sobre AppSec o es una de las muchas mentes que trabajan arduamente para diseñar estrategias de programas de seguridad, ahora es el momento de ir mejor que «girar» a la izquierda. Con la formación, las herramientas y el entorno adecuados, puede crear una incubadora de seguridad para desarrolladores que generará grandes beneficios para todas las partes. Si en esta lista de verificación se destacan algunas áreas que pueden mejorarse, es una gran oportunidad para preparar a su organización para contar con un departamento de ingeniería dirigido por DevSec que pueda reducir los riesgos desde el principio del SDLC.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Apenas estamos a la mitad de 2020 y, sin embargo, ya estamos en camino de establecer un sombrío récord de violaciones de datos, viendo un aumento del 273% en los datos robados en comparación con el primer semestre de 2019. Hoy en día, es más preciso preguntar cuántos datos no ha ha sido robada todavía. Con acontecimientos mundiales como la pandemia de la COVID-19, estos ataques no han hecho más que aumentar en frecuencia y potencia, y los objetivos son cada vez más vulnerables.
Esto es algo que todos sabemos desde hace tiempo: la seguridad ya no es opcional y debemos centrarnos en un ataque preventivo. Para que sea efectivo, todos en el SDLC deben ser conscientes de la seguridad, especialmente los desarrolladores. Esta es la parte «DevSec» de DevSecOps, una metodología de desarrollo de software ideal para el clima, pero muchas organizaciones no están totalmente preparadas para ejecutarla de manera eficaz.
Con su organización en mente, piense en estas preguntas en el contexto de su función. ¿Cómo le iría cuando se sometiera a la prueba de DevSec?
Autoevaluación de DevSec: ¿Está su jardín de SDLC preparado para que florezcan los ingenieros preocupados por la seguridad?
- ¿La seguridad es una prioridad en el proceso de desarrollo interno?
Es posible que una serie de factores de riesgo de ciberseguridad mantengan despierto al CISO promedio por la noche, pero la preocupante realidad es que, si bien muchas empresas dan más prioridad a la seguridad, es posible que su enfoque interno no sea lo suficientemente sólido como para mitigar posibles desastres (o, al menos, los enormes quebraderos de cabeza para el equipo de AppSec y el retraso en el envío del software).
DevSecOps puede ser el estado actual del nirvana de seguridad, pero pocas empresas trabajan con esta metodología. Si aún usas Agile (o incluso Waterfall), la seguridad sigue considerándose como un dominio de especialistas que están muy alejados del proceso y se activan al final del SDLC, apareciendo para arruinarle el día a un desarrollador con correcciones para su código. En un entorno como este, va a ser difícil impulsar una cultura de DevSec: a los desarrolladores les encanta la creación de funciones y la priorizan, y simplemente no habrán tenido suficiente experiencia práctica con la seguridad como para considerarla una vía de mejora de habilidades deseable. De hecho, sus puntos de contacto con ella pueden ser los de frustración y negatividad. Esto debe solucionarse rápidamente para inculcar un enfoque prioritario a todos los involucrados en el proceso de desarrollo de software.
- ¿Su organización sigue intentando ponerse al día en lo que respecta al modelado de amenazas?
Es una estadística aleccionadora que El 60% de las pymes cierra en un plazo de seis meses tras un ciberataque exitoso, y al igual que otros desastres, el impacto es mucho mayor sin una planificación adecuada.
El modelado de amenazas es un elemento crucial de las mejores prácticas de seguridad, ya que permite a los profesionales de AppSec evaluar el alcance total de la superficie de ataque y estructurar las defensas, las contramedidas y la planificación adecuadas. En las empresas que han adoptado DevSecOps por completo, la seguridad se habilita en las primeras etapas del proceso de CI/CD, de forma que no se ralentice la producción tanto como en el pasado. La seguridad, la codificación segura y la entrega continua forman parte del proceso, y los equipos de desarrollo cuentan con los recursos y la exposición necesarios para convertirse en los principales componentes del motor que produce código hermético.
- ¿Los gerentes de desarrollo dan prioridad a las mejores prácticas de seguridad?
Les guste o no, los gerentes de desarrollo son modelos a seguir para su equipo. Y no es solo por cuestiones relacionadas con la cultura y el ambiente, como llevar chanclas en la oficina o cómo «se las arreglan para ascender». Inevitablemente, sus prioridades laborales serán absorbidas por los miembros de su equipo, y si la seguridad no forma parte de los objetivos clave ni se planifica desde el punto de vista de la formación y el soporte, los ingenieros que están detrás de ellos se quedarán perdiendo la oportunidad y la empresa correrá más riesgos de lo que debería.
- ¿Se les da a los desarrolladores una razón para preocuparse por la seguridad?
Según mi experiencia, la forma más rápida de poner a alguien fuera de juego es decirle que tiene que hacer algo que es ajeno a su enfoque actual, sin decirle por qué.
Que te digan que «cambies» implica que el enfoque anterior era incorrecto, cuando en muchos casos se trata simplemente de una mejora que, con suerte, hará las cosas más fáciles y eficientes más adelante. Para abrazar realmente el movimiento DevSec, los desarrolladores deben tener una razón para preocuparse por la seguridad en primer lugar; al fin y al cabo, en la mayoría de las organizaciones, sigue siendo en gran medida «un problema de otra persona» (es decir, los magos de AppSec encerrados en otra habitación, muy, muy lejos).
DevSecOps simplemente no funciona si la seguridad no es una responsabilidad compartida. Los desarrolladores necesitan las herramientas, el soporte y la formación adecuados para hacer su parte... y esto requiere tiempo para implementarlo y perfeccionarlo como parte de un programa de seguridad general. El peor enfoque es el que abruma y aleja, lo que puede ocurrir cuando los desarrolladores tienen demasiadas prioridades que compiten entre sí y carecen de ayuda para gestionarlas sin volverse locos. Se trata de un cambio cultural y no ocurre de la noche a la mañana.
- ¿Confías en un puñado de unicornios mágicos de seguridad para asumir la tarea de muchos?
Los profesionales de la seguridad están en suministro muy escaso, y necesitamos mucho más de lo que está disponible actualmente. Eso es un hecho, pero cada vez hay más desarrolladores que adoptan funciones más centradas en la seguridad. Por lo general, pueden aparecer bajo títulos como «ingeniero de seguridad» o «ingeniero de DevOps» (poco a poco, veremos cómo este título se transforma en Ingeniero de DevSecOps, ¡con un poco de suerte!). Un ingeniero de DevOps con armas es capaz de desarrollar funciones para prácticamente cualquier aplicación y, al mismo tiempo, implementarlas utilizando una verdadera canalización de CI/CD. Lo hacen todo de principio a fin y, por lo general, vienen con una buena dosis de conciencia sobre la seguridad. En ese sentido, son algo mágicos y, por lo tanto, raros.
Sin embargo, algunas empresas cometen el error de contratar a estos ingenieros especializados, unirlos en un equipo y esperar que se enfrenten a todos los problemas de seguridad en cada etapa del proceso de desarrollo, y esto por sí solo es la panacea. Si sobrecargas a tus magos de DevSecOps, acabarás donde empezaste: publicando código inseguro sin los controles, contrapesos y precisión de seguridad para los que fueron contratados en primer lugar. Es de suma importancia que el equipo de desarrollo, en general, esté cualificado y formado en un entorno de seguridad positivo, de forma que esté preparado para compartir la carga de forma significativa.
Busca el cambio que quieres ver en tu organización.
Si implementas una formación sólida como parte de tu programa de seguridad, descubrirás algunas joyas ocultas en tu cohorte de desarrollo. Estas son las personas que, a pesar de las experiencias negativas que puedan haber tenido en su trabajo diario, sienten cierta pasión por la codificación segura y las mejores prácticas de seguridad. Estas personas son las principales candidatas para convertirse en campeones de la seguridad dentro del equipo; son un punto de contacto entre la seguridad y la ingeniería que da un gran ejemplo a los demás, mantiene la concienciación al respecto y ayuda con las iniciativas de participación. Sus habilidades interpersonales también son muy importantes para difundir el entusiasmo por la seguridad y para defender las necesidades de los desarrolladores ante la dirección y el equipo de seguridad.
El «¿qué hay para mí?» la conversación es un paso adelante positivo.
Incluso los humanos más nobles necesitan algo parecido a una «zanahoria» para sumergirse en un territorio desconocido, o una actividad que tal vez no tenga las curvas de aprendizaje más agradables.
Dar el salto de «dev» a «DevSec» supone un gran impulso para la carrera de un desarrollador. Los desarrolladores preocupados por la seguridad han trabajado arduamente para entender la seguridad, asumir la responsabilidad en las áreas que pueden controlar y operar con el entendimiento de que el único código de calidad es el código seguro. Por lo general, los desarrolladores quieren mejorar, abordar nuevos problemas y crear funciones envidiables que les ayuden a destacar entre sus pares. Bríndeles una vía para alcanzar un nivel superior de desarrollo de software y es una situación en la que todos salen ganando.
Nunca es demasiado tarde para crear el equipo de DevSec de tus sueños.
Si dirige desarrolladores, dirige un equipo de concienciación sobre AppSec o es una de las muchas mentes que trabajan arduamente para diseñar estrategias de programas de seguridad, ahora es el momento de ir mejor que «girar» a la izquierda. Con la formación, las herramientas y el entorno adecuados, puede crear una incubadora de seguridad para desarrolladores que generará grandes beneficios para todas las partes. Si en esta lista de verificación se destacan algunas áreas que pueden mejorarse, es una gran oportunidad para preparar a su organización para contar con un departamento de ingeniería dirigido por DevSec que pueda reducir los riesgos desde el principio del SDLC.
Tabla de contenido
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
