Si las herramientas de AppSec son la solución mágica, ¿por qué tantas empresas no las utilizan?
Una versión de este artículo apareció en Revista SC. Se ha actualizado y distribuido aquí.
Uno de los muchos acertijos a los que se enfrentan los especialistas en seguridad de hoy en día es determinar el equilibrio de las soluciones que utilizarán para gestionar los riesgos cibernéticos a los que se enfrentan. ¿Cómo se debe dividir el presupuesto entre las herramientas y las personas? ¿Qué conjunto de herramientas funcionará mejor para el conjunto tecnológico existente? Con tantas opciones disponibles, no hay respuestas fáciles, y elegir las opciones incorrectas costará tiempo y dinero más adelante.
Un informe reciente reveló que el mercado de herramientas de seguridad de aplicaciones está rastreando crecimiento «explosivo» de aquí a 2025, un claro indicio de su papel indiscutible en las prácticas exitosas de DevSecOps y de su creciente relevancia en la industria ante los crecientes volúmenes de código con posibles vulnerabilidades de seguridad.
Sin embargo, hay un problema un tanto curioso. Casi la mitad de las organizaciones envían código vulnerable a sabiendas, A pesar de utilizando una serie de herramientas de AppSec diseñadas para detener precisamente eso. En el caso de productos con una demanda de mercado innegable que están ganando terreno rápidamente, no tiene mucho sentido. ¿Por qué tantas personas comprarían herramientas de seguridad sofisticadas, solo para ignorar sus hallazgos o no utilizarlas en absoluto? Es un poco como comprar una casa frente a la playa, solo para dormir en una tienda de campaña en el bosque.
Hay algunas razones por las que las herramientas de AppSec no se utilizan como cabría esperar, y se trata menos de las herramientas y su funcionalidad, y más de cómo se integran con un programa de seguridad en su conjunto.
Más herramientas no equivalen a menos problemas.
A medida que las empresas evolucionan sus procesos de desarrollo de software, pasando de Agile a DevOps y al sagrado nirvana que es DevSecOps (por ahora, es lo mejor que tenemos), es inevitable que, por el camino, adquieran varios escáneres, monitores, firewalls y todo tipo de herramientas de AppSec. Aunque parezca que se trata de «cuanto más, mejor», muy a menudo esto lleva a una pila tecnológica que se parece al Monstruo de Frankenstein, con toda la imprevisibilidad que esto implica.
Con los presupuestos y los recursos de expertos cada vez más limitados para el alcance del trabajo requerido, tratar de deshacer el lío y encontrar las mejores herramientas para avanzar es una tarea abrumadora, y el código que necesita ser escaneado y corregido no deja de llegar. No es de extrañar que muchas organizaciones hayan tenido que conservar el código de envío, aunque es bastante alarmante y sigue representando un enorme riesgo para nuestros datos y nuestra privacidad.
Las herramientas de escaneo son lentas y esto afecta a la agilidad de las versiones.
Lograr la seguridad a gran velocidad es una especie de ballena blanca en el desarrollo de software, y la verdad es que seguimos intentando hacerlo bien a pesar de que estamos llevando a las organizaciones a adoptar un enfoque orientado a DevSecops. La revisión manual y meticulosa del código podría haber funcionado como sistema de seguridad a prueba de fallos en los años 90, pero en una época en la que producimos cientos de miles de millones de líneas de código, es un plan casi tan eficaz como preparar un campo de fútbol con unas tijeras para uñas.
Las herramientas de escaneo automatizan el proceso de búsqueda de posibles problemas y se encargan de revisar meticulosamente el código por nosotros. El problema es que siguen siendo lentas en el contexto de un proceso de CI/CD que funciona a toda máquina, y ninguna herramienta encuentra todas las vulnerabilidades por sí solas. También hay un par de problemas evidentes con los resultados que el equipo de seguridad recibe tras un escaneo:
- Hay un mucho de falsos positivos (y negativos)
- Algún pobre experto en seguridad todavía tiene que sentarse y hacer una revisión manual para separar los errores reales de los fantasmas.
- Muy a menudo, se revelan demasiadas vulnerabilidades comunes que deberían haberse detectado antes de implementar el código. ¿De verdad quiere que sus costosos expertos en seguridad se distraigan de los grandes y complicados problemas de seguridad que plantean las cosas pequeñas?
- Los escáneres encuentran, no arreglan.
Incluso en una organización que está haciendo todo lo posible por aplicar las mejores prácticas de ciberseguridad y adaptarse a los tiempos para incluir la seguridad en cada etapa del proceso, el proceso anterior sigue siendo un éxito si los escáneres son la principal medida de protección, y hay demasiados errores comunes que hacen tropezar al equipo a la hora de implementar código seguro. Es lógico pensar que en este caso se pueden tomar atajos, y eso suele consistir en confiar en el mínimo de herramientas que no pueden cubrir todos los riesgos potenciales, incluso si se ha adquirido un conjunto de soluciones.
Parte de la automatización líder en tecnología puede provocar una disminución de la calidad del código
El escaneo y las pruebas soportan la carga de los procesos automatizados de las herramientas de AppSec, junto con elementos esenciales como los firewalls y la supervisión, pero otras herramientas comunes pueden erosionar inadvertidamente las bases prácticas de seguridad con el tiempo.
Por ejemplo, la tecnología RASP (autoprotección de aplicaciones en tiempo de ejecución) se aplica a menudo para reforzar la postura de seguridad sin sacrificar la velocidad de codificación. Funciona en el entorno de ejecución de una aplicación, lo que protege contra la entrada de código malintencionado y los ataques en tiempo real, y detecta cualquier comportamiento de ejecución extraño.
No cabe duda de que se trata de una capa de protección adicional, pero si se piensa que es una protección contra cualquier posible debilidad del código base, los desarrolladores pueden caer en la autocomplacencia, especialmente cuando se enfrentan a plazos de comercialización cada vez más imposibles para lanzar nuevas funciones. Es posible que no se sigan prácticas de codificación seguras, con el supuesto de que la autoprotección durante el tiempo de ejecución detectará cualquier error. Los desarrolladores no se esfuerzan por crear patrones de codificación inseguros, pero con frecuencia la seguridad pierde prioridad en favor de la entrega de funciones, especialmente si se parte de la hipótesis de que se trata de una protección automatizada.
Las herramientas pueden fallar (y en el caso del RASP, suelen ejecutarse en modo de supervisión para evitar falsos positivos, lo que a su vez solo proporciona visibilidad, no protección, contra un ataque) y, cuando eso ocurre, se trata de un código seguro y de alta calidad en el que se puede confiar en todo momento. La concienciación sobre la seguridad en todas las funciones relacionadas con el código es fundamental para DevSecOps, y los desarrolladores que no se forman en código seguro o no producen código seguro es un error. Escribir código seguro e inseguro requiere el mismo esfuerzo; lo que más se necesita es adquirir los conocimientos necesarios para programar de forma segura. El tiempo dedicado a implementar y optimizar RASP se puede utilizar mucho mejor para mejorar las habilidades de los desarrolladores para que no cometan el error desde el principio.
Equilibrar herramientas y personas: no es una fórmula mágica, pero es lo más cerca que tenemos (por ahora).
El espíritu principal de DevSecOps es hacer de la seguridad una responsabilidad compartida, y para las organizaciones que están creando el software que impulsa nuestras vidas (desde la red eléctrica hasta nuestros timbres), necesitan llevar a todos a la aventura para garantizar un mayor nivel de seguridad.
Las herramientas no lo hacen todo, y ni siquiera es la forma más barata. Con diferencia, los mejores resultados se obtienen dando prioridad a la formación en seguridad adecuada para todos los que se dedican al código, trabajando activamente para que el equipo de desarrollo tenga en cuenta la seguridad y creando una cultura de seguridad positiva dirigida por personas, con un conjunto de herramientas que desempeñe un papel de apoyo.
Incluso teniendo en cuenta las limitaciones de tiempo, los recortes y otras cosas que hacen que los expertos en seguridad pierdan el sueño por la noche, si los desarrolladores no introducen los defectos de seguridad comunes desde el principio, esas herramientas (y si se utilizan o no) representan un factor de riesgo mucho menor.
Hay algunas razones por las que las herramientas de AppSec no se utilizan como cabría esperar, y se trata menos de las herramientas y su funcionalidad, y más de cómo se integran con un programa de seguridad en su conjunto.
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.
Una versión de este artículo apareció en Revista SC. Se ha actualizado y distribuido aquí.
Uno de los muchos acertijos a los que se enfrentan los especialistas en seguridad de hoy en día es determinar el equilibrio de las soluciones que utilizarán para gestionar los riesgos cibernéticos a los que se enfrentan. ¿Cómo se debe dividir el presupuesto entre las herramientas y las personas? ¿Qué conjunto de herramientas funcionará mejor para el conjunto tecnológico existente? Con tantas opciones disponibles, no hay respuestas fáciles, y elegir las opciones incorrectas costará tiempo y dinero más adelante.
Un informe reciente reveló que el mercado de herramientas de seguridad de aplicaciones está rastreando crecimiento «explosivo» de aquí a 2025, un claro indicio de su papel indiscutible en las prácticas exitosas de DevSecOps y de su creciente relevancia en la industria ante los crecientes volúmenes de código con posibles vulnerabilidades de seguridad.
Sin embargo, hay un problema un tanto curioso. Casi la mitad de las organizaciones envían código vulnerable a sabiendas, A pesar de utilizando una serie de herramientas de AppSec diseñadas para detener precisamente eso. En el caso de productos con una demanda de mercado innegable que están ganando terreno rápidamente, no tiene mucho sentido. ¿Por qué tantas personas comprarían herramientas de seguridad sofisticadas, solo para ignorar sus hallazgos o no utilizarlas en absoluto? Es un poco como comprar una casa frente a la playa, solo para dormir en una tienda de campaña en el bosque.
Hay algunas razones por las que las herramientas de AppSec no se utilizan como cabría esperar, y se trata menos de las herramientas y su funcionalidad, y más de cómo se integran con un programa de seguridad en su conjunto.
Más herramientas no equivalen a menos problemas.
A medida que las empresas evolucionan sus procesos de desarrollo de software, pasando de Agile a DevOps y al sagrado nirvana que es DevSecOps (por ahora, es lo mejor que tenemos), es inevitable que, por el camino, adquieran varios escáneres, monitores, firewalls y todo tipo de herramientas de AppSec. Aunque parezca que se trata de «cuanto más, mejor», muy a menudo esto lleva a una pila tecnológica que se parece al Monstruo de Frankenstein, con toda la imprevisibilidad que esto implica.
Con los presupuestos y los recursos de expertos cada vez más limitados para el alcance del trabajo requerido, tratar de deshacer el lío y encontrar las mejores herramientas para avanzar es una tarea abrumadora, y el código que necesita ser escaneado y corregido no deja de llegar. No es de extrañar que muchas organizaciones hayan tenido que conservar el código de envío, aunque es bastante alarmante y sigue representando un enorme riesgo para nuestros datos y nuestra privacidad.
Las herramientas de escaneo son lentas y esto afecta a la agilidad de las versiones.
Lograr la seguridad a gran velocidad es una especie de ballena blanca en el desarrollo de software, y la verdad es que seguimos intentando hacerlo bien a pesar de que estamos llevando a las organizaciones a adoptar un enfoque orientado a DevSecops. La revisión manual y meticulosa del código podría haber funcionado como sistema de seguridad a prueba de fallos en los años 90, pero en una época en la que producimos cientos de miles de millones de líneas de código, es un plan casi tan eficaz como preparar un campo de fútbol con unas tijeras para uñas.
Las herramientas de escaneo automatizan el proceso de búsqueda de posibles problemas y se encargan de revisar meticulosamente el código por nosotros. El problema es que siguen siendo lentas en el contexto de un proceso de CI/CD que funciona a toda máquina, y ninguna herramienta encuentra todas las vulnerabilidades por sí solas. También hay un par de problemas evidentes con los resultados que el equipo de seguridad recibe tras un escaneo:
- Hay un mucho de falsos positivos (y negativos)
- Algún pobre experto en seguridad todavía tiene que sentarse y hacer una revisión manual para separar los errores reales de los fantasmas.
- Muy a menudo, se revelan demasiadas vulnerabilidades comunes que deberían haberse detectado antes de implementar el código. ¿De verdad quiere que sus costosos expertos en seguridad se distraigan de los grandes y complicados problemas de seguridad que plantean las cosas pequeñas?
- Los escáneres encuentran, no arreglan.
Incluso en una organización que está haciendo todo lo posible por aplicar las mejores prácticas de ciberseguridad y adaptarse a los tiempos para incluir la seguridad en cada etapa del proceso, el proceso anterior sigue siendo un éxito si los escáneres son la principal medida de protección, y hay demasiados errores comunes que hacen tropezar al equipo a la hora de implementar código seguro. Es lógico pensar que en este caso se pueden tomar atajos, y eso suele consistir en confiar en el mínimo de herramientas que no pueden cubrir todos los riesgos potenciales, incluso si se ha adquirido un conjunto de soluciones.
Parte de la automatización líder en tecnología puede provocar una disminución de la calidad del código
El escaneo y las pruebas soportan la carga de los procesos automatizados de las herramientas de AppSec, junto con elementos esenciales como los firewalls y la supervisión, pero otras herramientas comunes pueden erosionar inadvertidamente las bases prácticas de seguridad con el tiempo.
Por ejemplo, la tecnología RASP (autoprotección de aplicaciones en tiempo de ejecución) se aplica a menudo para reforzar la postura de seguridad sin sacrificar la velocidad de codificación. Funciona en el entorno de ejecución de una aplicación, lo que protege contra la entrada de código malintencionado y los ataques en tiempo real, y detecta cualquier comportamiento de ejecución extraño.
No cabe duda de que se trata de una capa de protección adicional, pero si se piensa que es una protección contra cualquier posible debilidad del código base, los desarrolladores pueden caer en la autocomplacencia, especialmente cuando se enfrentan a plazos de comercialización cada vez más imposibles para lanzar nuevas funciones. Es posible que no se sigan prácticas de codificación seguras, con el supuesto de que la autoprotección durante el tiempo de ejecución detectará cualquier error. Los desarrolladores no se esfuerzan por crear patrones de codificación inseguros, pero con frecuencia la seguridad pierde prioridad en favor de la entrega de funciones, especialmente si se parte de la hipótesis de que se trata de una protección automatizada.
Las herramientas pueden fallar (y en el caso del RASP, suelen ejecutarse en modo de supervisión para evitar falsos positivos, lo que a su vez solo proporciona visibilidad, no protección, contra un ataque) y, cuando eso ocurre, se trata de un código seguro y de alta calidad en el que se puede confiar en todo momento. La concienciación sobre la seguridad en todas las funciones relacionadas con el código es fundamental para DevSecOps, y los desarrolladores que no se forman en código seguro o no producen código seguro es un error. Escribir código seguro e inseguro requiere el mismo esfuerzo; lo que más se necesita es adquirir los conocimientos necesarios para programar de forma segura. El tiempo dedicado a implementar y optimizar RASP se puede utilizar mucho mejor para mejorar las habilidades de los desarrolladores para que no cometan el error desde el principio.
Equilibrar herramientas y personas: no es una fórmula mágica, pero es lo más cerca que tenemos (por ahora).
El espíritu principal de DevSecOps es hacer de la seguridad una responsabilidad compartida, y para las organizaciones que están creando el software que impulsa nuestras vidas (desde la red eléctrica hasta nuestros timbres), necesitan llevar a todos a la aventura para garantizar un mayor nivel de seguridad.
Las herramientas no lo hacen todo, y ni siquiera es la forma más barata. Con diferencia, los mejores resultados se obtienen dando prioridad a la formación en seguridad adecuada para todos los que se dedican al código, trabajando activamente para que el equipo de desarrollo tenga en cuenta la seguridad y creando una cultura de seguridad positiva dirigida por personas, con un conjunto de herramientas que desempeñe un papel de apoyo.
Incluso teniendo en cuenta las limitaciones de tiempo, los recortes y otras cosas que hacen que los expertos en seguridad pierdan el sueño por la noche, si los desarrolladores no introducen los defectos de seguridad comunes desde el principio, esas herramientas (y si se utilizan o no) representan un factor de riesgo mucho menor.
Una versión de este artículo apareció en Revista SC. Se ha actualizado y distribuido aquí.
Uno de los muchos acertijos a los que se enfrentan los especialistas en seguridad de hoy en día es determinar el equilibrio de las soluciones que utilizarán para gestionar los riesgos cibernéticos a los que se enfrentan. ¿Cómo se debe dividir el presupuesto entre las herramientas y las personas? ¿Qué conjunto de herramientas funcionará mejor para el conjunto tecnológico existente? Con tantas opciones disponibles, no hay respuestas fáciles, y elegir las opciones incorrectas costará tiempo y dinero más adelante.
Un informe reciente reveló que el mercado de herramientas de seguridad de aplicaciones está rastreando crecimiento «explosivo» de aquí a 2025, un claro indicio de su papel indiscutible en las prácticas exitosas de DevSecOps y de su creciente relevancia en la industria ante los crecientes volúmenes de código con posibles vulnerabilidades de seguridad.
Sin embargo, hay un problema un tanto curioso. Casi la mitad de las organizaciones envían código vulnerable a sabiendas, A pesar de utilizando una serie de herramientas de AppSec diseñadas para detener precisamente eso. En el caso de productos con una demanda de mercado innegable que están ganando terreno rápidamente, no tiene mucho sentido. ¿Por qué tantas personas comprarían herramientas de seguridad sofisticadas, solo para ignorar sus hallazgos o no utilizarlas en absoluto? Es un poco como comprar una casa frente a la playa, solo para dormir en una tienda de campaña en el bosque.
Hay algunas razones por las que las herramientas de AppSec no se utilizan como cabría esperar, y se trata menos de las herramientas y su funcionalidad, y más de cómo se integran con un programa de seguridad en su conjunto.
Más herramientas no equivalen a menos problemas.
A medida que las empresas evolucionan sus procesos de desarrollo de software, pasando de Agile a DevOps y al sagrado nirvana que es DevSecOps (por ahora, es lo mejor que tenemos), es inevitable que, por el camino, adquieran varios escáneres, monitores, firewalls y todo tipo de herramientas de AppSec. Aunque parezca que se trata de «cuanto más, mejor», muy a menudo esto lleva a una pila tecnológica que se parece al Monstruo de Frankenstein, con toda la imprevisibilidad que esto implica.
Con los presupuestos y los recursos de expertos cada vez más limitados para el alcance del trabajo requerido, tratar de deshacer el lío y encontrar las mejores herramientas para avanzar es una tarea abrumadora, y el código que necesita ser escaneado y corregido no deja de llegar. No es de extrañar que muchas organizaciones hayan tenido que conservar el código de envío, aunque es bastante alarmante y sigue representando un enorme riesgo para nuestros datos y nuestra privacidad.
Las herramientas de escaneo son lentas y esto afecta a la agilidad de las versiones.
Lograr la seguridad a gran velocidad es una especie de ballena blanca en el desarrollo de software, y la verdad es que seguimos intentando hacerlo bien a pesar de que estamos llevando a las organizaciones a adoptar un enfoque orientado a DevSecops. La revisión manual y meticulosa del código podría haber funcionado como sistema de seguridad a prueba de fallos en los años 90, pero en una época en la que producimos cientos de miles de millones de líneas de código, es un plan casi tan eficaz como preparar un campo de fútbol con unas tijeras para uñas.
Las herramientas de escaneo automatizan el proceso de búsqueda de posibles problemas y se encargan de revisar meticulosamente el código por nosotros. El problema es que siguen siendo lentas en el contexto de un proceso de CI/CD que funciona a toda máquina, y ninguna herramienta encuentra todas las vulnerabilidades por sí solas. También hay un par de problemas evidentes con los resultados que el equipo de seguridad recibe tras un escaneo:
- Hay un mucho de falsos positivos (y negativos)
- Algún pobre experto en seguridad todavía tiene que sentarse y hacer una revisión manual para separar los errores reales de los fantasmas.
- Muy a menudo, se revelan demasiadas vulnerabilidades comunes que deberían haberse detectado antes de implementar el código. ¿De verdad quiere que sus costosos expertos en seguridad se distraigan de los grandes y complicados problemas de seguridad que plantean las cosas pequeñas?
- Los escáneres encuentran, no arreglan.
Incluso en una organización que está haciendo todo lo posible por aplicar las mejores prácticas de ciberseguridad y adaptarse a los tiempos para incluir la seguridad en cada etapa del proceso, el proceso anterior sigue siendo un éxito si los escáneres son la principal medida de protección, y hay demasiados errores comunes que hacen tropezar al equipo a la hora de implementar código seguro. Es lógico pensar que en este caso se pueden tomar atajos, y eso suele consistir en confiar en el mínimo de herramientas que no pueden cubrir todos los riesgos potenciales, incluso si se ha adquirido un conjunto de soluciones.
Parte de la automatización líder en tecnología puede provocar una disminución de la calidad del código
El escaneo y las pruebas soportan la carga de los procesos automatizados de las herramientas de AppSec, junto con elementos esenciales como los firewalls y la supervisión, pero otras herramientas comunes pueden erosionar inadvertidamente las bases prácticas de seguridad con el tiempo.
Por ejemplo, la tecnología RASP (autoprotección de aplicaciones en tiempo de ejecución) se aplica a menudo para reforzar la postura de seguridad sin sacrificar la velocidad de codificación. Funciona en el entorno de ejecución de una aplicación, lo que protege contra la entrada de código malintencionado y los ataques en tiempo real, y detecta cualquier comportamiento de ejecución extraño.
No cabe duda de que se trata de una capa de protección adicional, pero si se piensa que es una protección contra cualquier posible debilidad del código base, los desarrolladores pueden caer en la autocomplacencia, especialmente cuando se enfrentan a plazos de comercialización cada vez más imposibles para lanzar nuevas funciones. Es posible que no se sigan prácticas de codificación seguras, con el supuesto de que la autoprotección durante el tiempo de ejecución detectará cualquier error. Los desarrolladores no se esfuerzan por crear patrones de codificación inseguros, pero con frecuencia la seguridad pierde prioridad en favor de la entrega de funciones, especialmente si se parte de la hipótesis de que se trata de una protección automatizada.
Las herramientas pueden fallar (y en el caso del RASP, suelen ejecutarse en modo de supervisión para evitar falsos positivos, lo que a su vez solo proporciona visibilidad, no protección, contra un ataque) y, cuando eso ocurre, se trata de un código seguro y de alta calidad en el que se puede confiar en todo momento. La concienciación sobre la seguridad en todas las funciones relacionadas con el código es fundamental para DevSecOps, y los desarrolladores que no se forman en código seguro o no producen código seguro es un error. Escribir código seguro e inseguro requiere el mismo esfuerzo; lo que más se necesita es adquirir los conocimientos necesarios para programar de forma segura. El tiempo dedicado a implementar y optimizar RASP se puede utilizar mucho mejor para mejorar las habilidades de los desarrolladores para que no cometan el error desde el principio.
Equilibrar herramientas y personas: no es una fórmula mágica, pero es lo más cerca que tenemos (por ahora).
El espíritu principal de DevSecOps es hacer de la seguridad una responsabilidad compartida, y para las organizaciones que están creando el software que impulsa nuestras vidas (desde la red eléctrica hasta nuestros timbres), necesitan llevar a todos a la aventura para garantizar un mayor nivel de seguridad.
Las herramientas no lo hacen todo, y ni siquiera es la forma más barata. Con diferencia, los mejores resultados se obtienen dando prioridad a la formación en seguridad adecuada para todos los que se dedican al código, trabajando activamente para que el equipo de desarrollo tenga en cuenta la seguridad y creando una cultura de seguridad positiva dirigida por personas, con un conjunto de herramientas que desempeñe un papel de apoyo.
Incluso teniendo en cuenta las limitaciones de tiempo, los recortes y otras cosas que hacen que los expertos en seguridad pierdan el sueño por la noche, si los desarrolladores no introducen los defectos de seguridad comunes desde el principio, esas herramientas (y si se utilizan o no) representan un factor de riesgo mucho menor.
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.
Una versión de este artículo apareció en Revista SC. Se ha actualizado y distribuido aquí.
Uno de los muchos acertijos a los que se enfrentan los especialistas en seguridad de hoy en día es determinar el equilibrio de las soluciones que utilizarán para gestionar los riesgos cibernéticos a los que se enfrentan. ¿Cómo se debe dividir el presupuesto entre las herramientas y las personas? ¿Qué conjunto de herramientas funcionará mejor para el conjunto tecnológico existente? Con tantas opciones disponibles, no hay respuestas fáciles, y elegir las opciones incorrectas costará tiempo y dinero más adelante.
Un informe reciente reveló que el mercado de herramientas de seguridad de aplicaciones está rastreando crecimiento «explosivo» de aquí a 2025, un claro indicio de su papel indiscutible en las prácticas exitosas de DevSecOps y de su creciente relevancia en la industria ante los crecientes volúmenes de código con posibles vulnerabilidades de seguridad.
Sin embargo, hay un problema un tanto curioso. Casi la mitad de las organizaciones envían código vulnerable a sabiendas, A pesar de utilizando una serie de herramientas de AppSec diseñadas para detener precisamente eso. En el caso de productos con una demanda de mercado innegable que están ganando terreno rápidamente, no tiene mucho sentido. ¿Por qué tantas personas comprarían herramientas de seguridad sofisticadas, solo para ignorar sus hallazgos o no utilizarlas en absoluto? Es un poco como comprar una casa frente a la playa, solo para dormir en una tienda de campaña en el bosque.
Hay algunas razones por las que las herramientas de AppSec no se utilizan como cabría esperar, y se trata menos de las herramientas y su funcionalidad, y más de cómo se integran con un programa de seguridad en su conjunto.
Más herramientas no equivalen a menos problemas.
A medida que las empresas evolucionan sus procesos de desarrollo de software, pasando de Agile a DevOps y al sagrado nirvana que es DevSecOps (por ahora, es lo mejor que tenemos), es inevitable que, por el camino, adquieran varios escáneres, monitores, firewalls y todo tipo de herramientas de AppSec. Aunque parezca que se trata de «cuanto más, mejor», muy a menudo esto lleva a una pila tecnológica que se parece al Monstruo de Frankenstein, con toda la imprevisibilidad que esto implica.
Con los presupuestos y los recursos de expertos cada vez más limitados para el alcance del trabajo requerido, tratar de deshacer el lío y encontrar las mejores herramientas para avanzar es una tarea abrumadora, y el código que necesita ser escaneado y corregido no deja de llegar. No es de extrañar que muchas organizaciones hayan tenido que conservar el código de envío, aunque es bastante alarmante y sigue representando un enorme riesgo para nuestros datos y nuestra privacidad.
Las herramientas de escaneo son lentas y esto afecta a la agilidad de las versiones.
Lograr la seguridad a gran velocidad es una especie de ballena blanca en el desarrollo de software, y la verdad es que seguimos intentando hacerlo bien a pesar de que estamos llevando a las organizaciones a adoptar un enfoque orientado a DevSecops. La revisión manual y meticulosa del código podría haber funcionado como sistema de seguridad a prueba de fallos en los años 90, pero en una época en la que producimos cientos de miles de millones de líneas de código, es un plan casi tan eficaz como preparar un campo de fútbol con unas tijeras para uñas.
Las herramientas de escaneo automatizan el proceso de búsqueda de posibles problemas y se encargan de revisar meticulosamente el código por nosotros. El problema es que siguen siendo lentas en el contexto de un proceso de CI/CD que funciona a toda máquina, y ninguna herramienta encuentra todas las vulnerabilidades por sí solas. También hay un par de problemas evidentes con los resultados que el equipo de seguridad recibe tras un escaneo:
- Hay un mucho de falsos positivos (y negativos)
- Algún pobre experto en seguridad todavía tiene que sentarse y hacer una revisión manual para separar los errores reales de los fantasmas.
- Muy a menudo, se revelan demasiadas vulnerabilidades comunes que deberían haberse detectado antes de implementar el código. ¿De verdad quiere que sus costosos expertos en seguridad se distraigan de los grandes y complicados problemas de seguridad que plantean las cosas pequeñas?
- Los escáneres encuentran, no arreglan.
Incluso en una organización que está haciendo todo lo posible por aplicar las mejores prácticas de ciberseguridad y adaptarse a los tiempos para incluir la seguridad en cada etapa del proceso, el proceso anterior sigue siendo un éxito si los escáneres son la principal medida de protección, y hay demasiados errores comunes que hacen tropezar al equipo a la hora de implementar código seguro. Es lógico pensar que en este caso se pueden tomar atajos, y eso suele consistir en confiar en el mínimo de herramientas que no pueden cubrir todos los riesgos potenciales, incluso si se ha adquirido un conjunto de soluciones.
Parte de la automatización líder en tecnología puede provocar una disminución de la calidad del código
El escaneo y las pruebas soportan la carga de los procesos automatizados de las herramientas de AppSec, junto con elementos esenciales como los firewalls y la supervisión, pero otras herramientas comunes pueden erosionar inadvertidamente las bases prácticas de seguridad con el tiempo.
Por ejemplo, la tecnología RASP (autoprotección de aplicaciones en tiempo de ejecución) se aplica a menudo para reforzar la postura de seguridad sin sacrificar la velocidad de codificación. Funciona en el entorno de ejecución de una aplicación, lo que protege contra la entrada de código malintencionado y los ataques en tiempo real, y detecta cualquier comportamiento de ejecución extraño.
No cabe duda de que se trata de una capa de protección adicional, pero si se piensa que es una protección contra cualquier posible debilidad del código base, los desarrolladores pueden caer en la autocomplacencia, especialmente cuando se enfrentan a plazos de comercialización cada vez más imposibles para lanzar nuevas funciones. Es posible que no se sigan prácticas de codificación seguras, con el supuesto de que la autoprotección durante el tiempo de ejecución detectará cualquier error. Los desarrolladores no se esfuerzan por crear patrones de codificación inseguros, pero con frecuencia la seguridad pierde prioridad en favor de la entrega de funciones, especialmente si se parte de la hipótesis de que se trata de una protección automatizada.
Las herramientas pueden fallar (y en el caso del RASP, suelen ejecutarse en modo de supervisión para evitar falsos positivos, lo que a su vez solo proporciona visibilidad, no protección, contra un ataque) y, cuando eso ocurre, se trata de un código seguro y de alta calidad en el que se puede confiar en todo momento. La concienciación sobre la seguridad en todas las funciones relacionadas con el código es fundamental para DevSecOps, y los desarrolladores que no se forman en código seguro o no producen código seguro es un error. Escribir código seguro e inseguro requiere el mismo esfuerzo; lo que más se necesita es adquirir los conocimientos necesarios para programar de forma segura. El tiempo dedicado a implementar y optimizar RASP se puede utilizar mucho mejor para mejorar las habilidades de los desarrolladores para que no cometan el error desde el principio.
Equilibrar herramientas y personas: no es una fórmula mágica, pero es lo más cerca que tenemos (por ahora).
El espíritu principal de DevSecOps es hacer de la seguridad una responsabilidad compartida, y para las organizaciones que están creando el software que impulsa nuestras vidas (desde la red eléctrica hasta nuestros timbres), necesitan llevar a todos a la aventura para garantizar un mayor nivel de seguridad.
Las herramientas no lo hacen todo, y ni siquiera es la forma más barata. Con diferencia, los mejores resultados se obtienen dando prioridad a la formación en seguridad adecuada para todos los que se dedican al código, trabajando activamente para que el equipo de desarrollo tenga en cuenta la seguridad y creando una cultura de seguridad positiva dirigida por personas, con un conjunto de herramientas que desempeñe un papel de apoyo.
Incluso teniendo en cuenta las limitaciones de tiempo, los recortes y otras cosas que hacen que los expertos en seguridad pierdan el sueño por la noche, si los desarrolladores no introducen los defectos de seguridad comunes desde el principio, esas herramientas (y si se utilizan o no) representan un factor de riesgo mucho menor.
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.
