Coders Conquer Security OWASP Top 10 API Series - Funciones de seguridad deshabilitadas/Funciones de depuración habilitadas/Permisos inadecuados
Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las APIs, el problema de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados es uno que puede atacar en cualquier lugar. Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallas sin parches y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo. Peor aún, existen herramientas automatizadas para detectar y explotar las desconfiguraciones de seguridad, por lo que si las tienes en tu entorno, hay muchas posibilidades de que sean explotadas, razón por la cual esta vulnerabilidad entró en la lista OWASP de fallos peligrosos de API.
Antes de entrar en la diversión, vea si puede resolver este desafío de depuración:
¿Cómo se cuela en una API el fallo de las funciones de seguridad deshabilitadas/las funciones de depuración habilitadas/los permisos inadecuados?
Para ver cómo esta falla multidimensional de la API se agrega a las redes, debemos desglosarla en sus partes componentes. Empecemos por el problema de las funciones de depuración habilitadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o cometen errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver lo que salió mal y solucionar los problemas. Es perfectamente correcto tener esto activo mientras una aplicación está todavía en desarrollo.
Sin embargo, hay una razón por la que la mayoría de los frameworks vienen con advertencias sobre la ejecución del modo de depuración en un entorno de producción, probablemente justo en el código donde se activa la depuración. Por ejemplo:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = True
En este ejemplo, se ha activado la depuración. La aplicación Django generará páginas de error detalladas cuando se produzca una excepción. Si esto se hace en un entorno de producción, un adversario tendría acceso a estas páginas de error, que incluyen información de metadatos sobre el entorno. Aunque la mayoría de los frameworks tienen la depuración desactivada por defecto, es fácil olvidarse de volver a desactivarla si se activa durante un largo proceso de desarrollo. Luego, cuando la aplicación se traslada a un entorno de producción, proporciona a los atacantes mucha información sobre cómo comprometer una aplicación, o incluso un servidor o una red entera.
Mientras que la activación del modo de depuración es en su mayoría un problema independiente, las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas a menudo funcionan juntas. Por ejemplo, en un escenario real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Como el popular sistema de gestión de bases de datos estaba utilizando su configuración por defecto, la autenticación estaba deshabilitada. Así, combinando las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas, el atacante obtuvo acceso a millones de registros con PII, preferencias personales y datos de autenticación.
Eliminación de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados
Probablemente, para eliminar esta vulnerabilidad, se necesita un enfoque doble. Para eliminar la parte de depuración habilitada del problema, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración está deshabilitada antes de mover una API o aplicación al entorno de producción. Desde nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = False
Ahora las características de depuración en la aplicación Django están deshabilitadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los errores. Si un adversario aún logra acceder a las páginas de error, éstas no contendrán ningún metadato útil, y no supondrán un riesgo para la aplicación.
Eliminar las características de seguridad deshabilitadas y las vulnerabilidades de permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de vulnerabilidades específicas. La mejor manera de detenerlas es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos bloqueados en el entorno de producción.
Incluso entonces, debería crear un proceso en el que los archivos de orquestación, los componentes de la API y los servicios en la nube, como los permisos de los cubos de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debería evaluar la eficacia general de la configuración de seguridad en todo el entorno a lo largo del tiempo para asegurarse de que la organización siempre está mejorando la seguridad de su API.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.


Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallos sin parches y archivos o directorios desprotegidos en cualquier lugar de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.


Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las APIs, el problema de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados es uno que puede atacar en cualquier lugar. Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallas sin parches y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo. Peor aún, existen herramientas automatizadas para detectar y explotar las desconfiguraciones de seguridad, por lo que si las tienes en tu entorno, hay muchas posibilidades de que sean explotadas, razón por la cual esta vulnerabilidad entró en la lista OWASP de fallos peligrosos de API.
Antes de entrar en la diversión, vea si puede resolver este desafío de depuración:
¿Cómo se cuela en una API el fallo de las funciones de seguridad deshabilitadas/las funciones de depuración habilitadas/los permisos inadecuados?
Para ver cómo esta falla multidimensional de la API se agrega a las redes, debemos desglosarla en sus partes componentes. Empecemos por el problema de las funciones de depuración habilitadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o cometen errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver lo que salió mal y solucionar los problemas. Es perfectamente correcto tener esto activo mientras una aplicación está todavía en desarrollo.
Sin embargo, hay una razón por la que la mayoría de los frameworks vienen con advertencias sobre la ejecución del modo de depuración en un entorno de producción, probablemente justo en el código donde se activa la depuración. Por ejemplo:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = True
En este ejemplo, se ha activado la depuración. La aplicación Django generará páginas de error detalladas cuando se produzca una excepción. Si esto se hace en un entorno de producción, un adversario tendría acceso a estas páginas de error, que incluyen información de metadatos sobre el entorno. Aunque la mayoría de los frameworks tienen la depuración desactivada por defecto, es fácil olvidarse de volver a desactivarla si se activa durante un largo proceso de desarrollo. Luego, cuando la aplicación se traslada a un entorno de producción, proporciona a los atacantes mucha información sobre cómo comprometer una aplicación, o incluso un servidor o una red entera.
Mientras que la activación del modo de depuración es en su mayoría un problema independiente, las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas a menudo funcionan juntas. Por ejemplo, en un escenario real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Como el popular sistema de gestión de bases de datos estaba utilizando su configuración por defecto, la autenticación estaba deshabilitada. Así, combinando las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas, el atacante obtuvo acceso a millones de registros con PII, preferencias personales y datos de autenticación.
Eliminación de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados
Probablemente, para eliminar esta vulnerabilidad, se necesita un enfoque doble. Para eliminar la parte de depuración habilitada del problema, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración está deshabilitada antes de mover una API o aplicación al entorno de producción. Desde nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = False
Ahora las características de depuración en la aplicación Django están deshabilitadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los errores. Si un adversario aún logra acceder a las páginas de error, éstas no contendrán ningún metadato útil, y no supondrán un riesgo para la aplicación.
Eliminar las características de seguridad deshabilitadas y las vulnerabilidades de permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de vulnerabilidades específicas. La mejor manera de detenerlas es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos bloqueados en el entorno de producción.
Incluso entonces, debería crear un proceso en el que los archivos de orquestación, los componentes de la API y los servicios en la nube, como los permisos de los cubos de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debería evaluar la eficacia general de la configuración de seguridad en todo el entorno a lo largo del tiempo para asegurarse de que la organización siempre está mejorando la seguridad de su API.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.

Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las APIs, el problema de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados es uno que puede atacar en cualquier lugar. Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallas sin parches y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo. Peor aún, existen herramientas automatizadas para detectar y explotar las desconfiguraciones de seguridad, por lo que si las tienes en tu entorno, hay muchas posibilidades de que sean explotadas, razón por la cual esta vulnerabilidad entró en la lista OWASP de fallos peligrosos de API.
Antes de entrar en la diversión, vea si puede resolver este desafío de depuración:
¿Cómo se cuela en una API el fallo de las funciones de seguridad deshabilitadas/las funciones de depuración habilitadas/los permisos inadecuados?
Para ver cómo esta falla multidimensional de la API se agrega a las redes, debemos desglosarla en sus partes componentes. Empecemos por el problema de las funciones de depuración habilitadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o cometen errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver lo que salió mal y solucionar los problemas. Es perfectamente correcto tener esto activo mientras una aplicación está todavía en desarrollo.
Sin embargo, hay una razón por la que la mayoría de los frameworks vienen con advertencias sobre la ejecución del modo de depuración en un entorno de producción, probablemente justo en el código donde se activa la depuración. Por ejemplo:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = True
En este ejemplo, se ha activado la depuración. La aplicación Django generará páginas de error detalladas cuando se produzca una excepción. Si esto se hace en un entorno de producción, un adversario tendría acceso a estas páginas de error, que incluyen información de metadatos sobre el entorno. Aunque la mayoría de los frameworks tienen la depuración desactivada por defecto, es fácil olvidarse de volver a desactivarla si se activa durante un largo proceso de desarrollo. Luego, cuando la aplicación se traslada a un entorno de producción, proporciona a los atacantes mucha información sobre cómo comprometer una aplicación, o incluso un servidor o una red entera.
Mientras que la activación del modo de depuración es en su mayoría un problema independiente, las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas a menudo funcionan juntas. Por ejemplo, en un escenario real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Como el popular sistema de gestión de bases de datos estaba utilizando su configuración por defecto, la autenticación estaba deshabilitada. Así, combinando las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas, el atacante obtuvo acceso a millones de registros con PII, preferencias personales y datos de autenticación.
Eliminación de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados
Probablemente, para eliminar esta vulnerabilidad, se necesita un enfoque doble. Para eliminar la parte de depuración habilitada del problema, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración está deshabilitada antes de mover una API o aplicación al entorno de producción. Desde nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = False
Ahora las características de depuración en la aplicación Django están deshabilitadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los errores. Si un adversario aún logra acceder a las páginas de error, éstas no contendrán ningún metadato útil, y no supondrán un riesgo para la aplicación.
Eliminar las características de seguridad deshabilitadas y las vulnerabilidades de permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de vulnerabilidades específicas. La mejor manera de detenerlas es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos bloqueados en el entorno de producción.
Incluso entonces, debería crear un proceso en el que los archivos de orquestación, los componentes de la API y los servicios en la nube, como los permisos de los cubos de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debería evaluar la eficacia general de la configuración de seguridad en todo el entorno a lo largo del tiempo para asegurarse de que la organización siempre está mejorando la seguridad de su API.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.

Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las APIs, el problema de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados es uno que puede atacar en cualquier lugar. Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallas sin parches y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo. Peor aún, existen herramientas automatizadas para detectar y explotar las desconfiguraciones de seguridad, por lo que si las tienes en tu entorno, hay muchas posibilidades de que sean explotadas, razón por la cual esta vulnerabilidad entró en la lista OWASP de fallos peligrosos de API.
Antes de entrar en la diversión, vea si puede resolver este desafío de depuración:
¿Cómo se cuela en una API el fallo de las funciones de seguridad deshabilitadas/las funciones de depuración habilitadas/los permisos inadecuados?
Para ver cómo esta falla multidimensional de la API se agrega a las redes, debemos desglosarla en sus partes componentes. Empecemos por el problema de las funciones de depuración habilitadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o cometen errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver lo que salió mal y solucionar los problemas. Es perfectamente correcto tener esto activo mientras una aplicación está todavía en desarrollo.
Sin embargo, hay una razón por la que la mayoría de los frameworks vienen con advertencias sobre la ejecución del modo de depuración en un entorno de producción, probablemente justo en el código donde se activa la depuración. Por ejemplo:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = True
En este ejemplo, se ha activado la depuración. La aplicación Django generará páginas de error detalladas cuando se produzca una excepción. Si esto se hace en un entorno de producción, un adversario tendría acceso a estas páginas de error, que incluyen información de metadatos sobre el entorno. Aunque la mayoría de los frameworks tienen la depuración desactivada por defecto, es fácil olvidarse de volver a desactivarla si se activa durante un largo proceso de desarrollo. Luego, cuando la aplicación se traslada a un entorno de producción, proporciona a los atacantes mucha información sobre cómo comprometer una aplicación, o incluso un servidor o una red entera.
Mientras que la activación del modo de depuración es en su mayoría un problema independiente, las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas a menudo funcionan juntas. Por ejemplo, en un escenario real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Como el popular sistema de gestión de bases de datos estaba utilizando su configuración por defecto, la autenticación estaba deshabilitada. Así, combinando las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas, el atacante obtuvo acceso a millones de registros con PII, preferencias personales y datos de autenticación.
Eliminación de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados
Probablemente, para eliminar esta vulnerabilidad, se necesita un enfoque doble. Para eliminar la parte de depuración habilitada del problema, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración está deshabilitada antes de mover una API o aplicación al entorno de producción. Desde nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:
# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = False
Ahora las características de depuración en la aplicación Django están deshabilitadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los errores. Si un adversario aún logra acceder a las páginas de error, éstas no contendrán ningún metadato útil, y no supondrán un riesgo para la aplicación.
Eliminar las características de seguridad deshabilitadas y las vulnerabilidades de permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de vulnerabilidades específicas. La mejor manera de detenerlas es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos bloqueados en el entorno de producción.
Incluso entonces, debería crear un proceso en el que los archivos de orquestación, los componentes de la API y los servicios en la nube, como los permisos de los cubos de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debería evaluar la eficacia general de la configuración de seguridad en todo el entorno a lo largo del tiempo para asegurarse de que la organización siempre está mejorando la seguridad de su API.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Recursos para empezar
Estableciendo el estándar: SCW publica reglas de seguridad de codificación de IA gratuitas en GitHub
El desarrollo asistido por IA ya no es una posibilidad: ya está aquí y está transformando rápidamente la forma de escribir software. Herramientas como GitHub Copilot, Cline, Roo, Cursor, Aider y Windsurf están transformando a los desarrolladores en sus propios copilotos, permitiendo iteraciones más rápidas y acelerando todo, desde la creación de prototipos hasta grandes proyectos de refactorización.
Cierre el círculo de las vulnerabilidades con Secure Code Warrior + HackerOne
Secure Code Warrior se complace en anunciar nuestra nueva integración con HackerOne, líder en soluciones de seguridad ofensiva. Juntos, estamos construyendo un ecosistema potente e integrado. HackerOne señala dónde se producen realmente las vulnerabilidades en entornos reales, exponiendo el "qué" y el "dónde" de los problemas de seguridad.
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.