
Las 10 mejores API de la serie OWASP de Coders Conquer Security: gestión inadecuada de activos
A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.


Esta vulnerabilidad es más bien un problema humano o de administración que permite que las API antiguas permanezcan en su lugar mucho después de que deberían haber sido reemplazadas por versiones más nuevas y seguras.
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 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.
Reserve 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.


A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior 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 informeReserve 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.
A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Tabla de contenido
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 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.
Reserve 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.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
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.
Facilitador 1: Criterios de éxito definidos y medibles
El habilitador 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.




%20(1).avif)
.avif)
