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., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
Inhaltsverzeichnis
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.