Coders Conquer Security OWASP Top 10 API Series - Gestión inadecuada de activos
A diferencia de la mayoría de las vulnerabilidades del top ten de APIs de OWASP, la gestión inadecuada de activos no se centra específicamente en defectos de codificación. En cambio, esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deban ser reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las APIs que todavía están en desarrollo se exponen al entorno de producción antes de que estén completamente reforzadas contra las amenazas.
Esta vulnerabilidad es especialmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, los nuevos servicios pueden ponerse en marcha rápidamente para satisfacer una necesidad temporal y luego olvidarse de ellos y no retirarlos nunca. Si las APIs más 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 fallo de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan los fallos de gestión de activos a las APIs?
El defecto de la gestión de activos inadecuados es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio pueden a veces poner en marcha cientos o miles de servicios y microservicios cada día. Esto se hace a menudo rápidamente y sin la creación de ninguna documentación de acompañamiento, ni ninguna explicación de para qué se utilizan las APIs asociadas, cuánto tiempo se necesitarán o su criticidad. Esto puede generar rápidamente una proliferación de APIs que podría volverse incontrolable con el tiempo, especialmente si no hay políticas generales para definir cuánto tiempo pueden existir las APIs.
En ese entorno, es muy posible que algunas APIs se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también son a veces culpables. Por ejemplo, un grupo de marketing puede crear un servicio para apoyar un evento próximo, como el lanzamiento de un producto, y luego no retirarlo una vez finalizado el evento. Alguien que vea ese servicio y sus APIs asociadas más tarde podría no tener ni idea de por qué existen, y si no hay documentación, podría seguir siendo un misterio. Puede que no se sientan cómodos eliminando esas APIs del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen ni idea de lo críticas que son o de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las APIs en los frameworks mejora con el tiempo. Un investigador puede descubrir una vulnerabilidad, o se puede añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las APIs más antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers suelen buscarlas o utilizar herramientas automatizadas para buscarlas.
En un ejemplo del mundo real proporcionado por OWASP, una empresa actualizó sus APIs utilizadas para buscar en bases de datos de usuarios para parchear un fallo crítico. Pero dejaron las antiguas APIs en su lugar por error.
Un atacante se dio cuenta de que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Reemplazando la URL por (api.criticalservice.com/v1) pudieron utilizar la antigua API con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.
Eliminación de los defectos de gestión de activos inadecuados
La única manera de eliminar el defecto de gestión de activos inadecuados de su entorno es mantener un inventario estricto de todas las APIs, sus usos y versiones. Esto debe comenzar con un inventario de las APIs existentes, centrándose en factores como el entorno en el que deben desplegarse, como producción o desarrollo, quién debe tener acceso a la red y, por supuesto, su versión.
Una vez que se haya completado, es necesario implementar un proceso en el que la documentación se añada automáticamente a cualquier nueva API o servicio que se cree. Esto debería incluir todos los aspectos de la API, incluyendo la limitación de la tasa, cómo maneja las solicitudes y las respuestas, los recursos compartidos, los puntos finales a los que se puede conectar, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas posteriormente. También hay que evitar utilizar nunca en producción APIs que no sean de producción o del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las APIs en el que su uso continuado deba ser justificado por sus propietarios para evitar el desmantelamiento automático.
Siempre que estén disponibles nuevas versiones de las APIs activas, realice un riesgo assessment para determinar si debe actualizar, y cómo debe llevarse a cabo ese proceso para evitar la interrupción del entorno de producción. Una vez que hayas migrado a las nuevas APIs, elimina las antiguas por completo del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la gestión de activos inadecuada perjudique a su organización, a los usuarios o a la red. 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.


Esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deberían haber sido sustituidas 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 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.


A diferencia de la mayoría de las vulnerabilidades del top ten de APIs de OWASP, la gestión inadecuada de activos no se centra específicamente en defectos de codificación. En cambio, esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deban ser reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las APIs que todavía están en desarrollo se exponen al entorno de producción antes de que estén completamente reforzadas contra las amenazas.
Esta vulnerabilidad es especialmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, los nuevos servicios pueden ponerse en marcha rápidamente para satisfacer una necesidad temporal y luego olvidarse de ellos y no retirarlos nunca. Si las APIs más 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 fallo de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan los fallos de gestión de activos a las APIs?
El defecto de la gestión de activos inadecuados es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio pueden a veces poner en marcha cientos o miles de servicios y microservicios cada día. Esto se hace a menudo rápidamente y sin la creación de ninguna documentación de acompañamiento, ni ninguna explicación de para qué se utilizan las APIs asociadas, cuánto tiempo se necesitarán o su criticidad. Esto puede generar rápidamente una proliferación de APIs que podría volverse incontrolable con el tiempo, especialmente si no hay políticas generales para definir cuánto tiempo pueden existir las APIs.
En ese entorno, es muy posible que algunas APIs se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también son a veces culpables. Por ejemplo, un grupo de marketing puede crear un servicio para apoyar un evento próximo, como el lanzamiento de un producto, y luego no retirarlo una vez finalizado el evento. Alguien que vea ese servicio y sus APIs asociadas más tarde podría no tener ni idea de por qué existen, y si no hay documentación, podría seguir siendo un misterio. Puede que no se sientan cómodos eliminando esas APIs del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen ni idea de lo críticas que son o de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las APIs en los frameworks mejora con el tiempo. Un investigador puede descubrir una vulnerabilidad, o se puede añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las APIs más antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers suelen buscarlas o utilizar herramientas automatizadas para buscarlas.
En un ejemplo del mundo real proporcionado por OWASP, una empresa actualizó sus APIs utilizadas para buscar en bases de datos de usuarios para parchear un fallo crítico. Pero dejaron las antiguas APIs en su lugar por error.
Un atacante se dio cuenta de que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Reemplazando la URL por (api.criticalservice.com/v1) pudieron utilizar la antigua API con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.
Eliminación de los defectos de gestión de activos inadecuados
La única manera de eliminar el defecto de gestión de activos inadecuados de su entorno es mantener un inventario estricto de todas las APIs, sus usos y versiones. Esto debe comenzar con un inventario de las APIs existentes, centrándose en factores como el entorno en el que deben desplegarse, como producción o desarrollo, quién debe tener acceso a la red y, por supuesto, su versión.
Una vez que se haya completado, es necesario implementar un proceso en el que la documentación se añada automáticamente a cualquier nueva API o servicio que se cree. Esto debería incluir todos los aspectos de la API, incluyendo la limitación de la tasa, cómo maneja las solicitudes y las respuestas, los recursos compartidos, los puntos finales a los que se puede conectar, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas posteriormente. También hay que evitar utilizar nunca en producción APIs que no sean de producción o del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las APIs en el que su uso continuado deba ser justificado por sus propietarios para evitar el desmantelamiento automático.
Siempre que estén disponibles nuevas versiones de las APIs activas, realice un riesgo assessment para determinar si debe actualizar, y cómo debe llevarse a cabo ese proceso para evitar la interrupción del entorno de producción. Una vez que hayas migrado a las nuevas APIs, elimina las antiguas por completo del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la gestión de activos inadecuada perjudique a su organización, a los usuarios o a la red. 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.

A diferencia de la mayoría de las vulnerabilidades del top ten de APIs de OWASP, la gestión inadecuada de activos no se centra específicamente en defectos de codificación. En cambio, esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deban ser reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las APIs que todavía están en desarrollo se exponen al entorno de producción antes de que estén completamente reforzadas contra las amenazas.
Esta vulnerabilidad es especialmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, los nuevos servicios pueden ponerse en marcha rápidamente para satisfacer una necesidad temporal y luego olvidarse de ellos y no retirarlos nunca. Si las APIs más 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 fallo de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan los fallos de gestión de activos a las APIs?
El defecto de la gestión de activos inadecuados es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio pueden a veces poner en marcha cientos o miles de servicios y microservicios cada día. Esto se hace a menudo rápidamente y sin la creación de ninguna documentación de acompañamiento, ni ninguna explicación de para qué se utilizan las APIs asociadas, cuánto tiempo se necesitarán o su criticidad. Esto puede generar rápidamente una proliferación de APIs que podría volverse incontrolable con el tiempo, especialmente si no hay políticas generales para definir cuánto tiempo pueden existir las APIs.
En ese entorno, es muy posible que algunas APIs se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también son a veces culpables. Por ejemplo, un grupo de marketing puede crear un servicio para apoyar un evento próximo, como el lanzamiento de un producto, y luego no retirarlo una vez finalizado el evento. Alguien que vea ese servicio y sus APIs asociadas más tarde podría no tener ni idea de por qué existen, y si no hay documentación, podría seguir siendo un misterio. Puede que no se sientan cómodos eliminando esas APIs del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen ni idea de lo críticas que son o de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las APIs en los frameworks mejora con el tiempo. Un investigador puede descubrir una vulnerabilidad, o se puede añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las APIs más antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers suelen buscarlas o utilizar herramientas automatizadas para buscarlas.
En un ejemplo del mundo real proporcionado por OWASP, una empresa actualizó sus APIs utilizadas para buscar en bases de datos de usuarios para parchear un fallo crítico. Pero dejaron las antiguas APIs en su lugar por error.
Un atacante se dio cuenta de que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Reemplazando la URL por (api.criticalservice.com/v1) pudieron utilizar la antigua API con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.
Eliminación de los defectos de gestión de activos inadecuados
La única manera de eliminar el defecto de gestión de activos inadecuados de su entorno es mantener un inventario estricto de todas las APIs, sus usos y versiones. Esto debe comenzar con un inventario de las APIs existentes, centrándose en factores como el entorno en el que deben desplegarse, como producción o desarrollo, quién debe tener acceso a la red y, por supuesto, su versión.
Una vez que se haya completado, es necesario implementar un proceso en el que la documentación se añada automáticamente a cualquier nueva API o servicio que se cree. Esto debería incluir todos los aspectos de la API, incluyendo la limitación de la tasa, cómo maneja las solicitudes y las respuestas, los recursos compartidos, los puntos finales a los que se puede conectar, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas posteriormente. También hay que evitar utilizar nunca en producción APIs que no sean de producción o del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las APIs en el que su uso continuado deba ser justificado por sus propietarios para evitar el desmantelamiento automático.
Siempre que estén disponibles nuevas versiones de las APIs activas, realice un riesgo assessment para determinar si debe actualizar, y cómo debe llevarse a cabo ese proceso para evitar la interrupción del entorno de producción. Una vez que hayas migrado a las nuevas APIs, elimina las antiguas por completo del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la gestión de activos inadecuada perjudique a su organización, a los usuarios o a la red. 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.
A diferencia de la mayoría de las vulnerabilidades del top ten de APIs de OWASP, la gestión inadecuada de activos no se centra específicamente en defectos de codificación. En cambio, esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deban ser reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las APIs que todavía están en desarrollo se exponen al entorno de producción antes de que estén completamente reforzadas contra las amenazas.
Esta vulnerabilidad es especialmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, los nuevos servicios pueden ponerse en marcha rápidamente para satisfacer una necesidad temporal y luego olvidarse de ellos y no retirarlos nunca. Si las APIs más 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 fallo de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan los fallos de gestión de activos a las APIs?
El defecto de la gestión de activos inadecuados es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio pueden a veces poner en marcha cientos o miles de servicios y microservicios cada día. Esto se hace a menudo rápidamente y sin la creación de ninguna documentación de acompañamiento, ni ninguna explicación de para qué se utilizan las APIs asociadas, cuánto tiempo se necesitarán o su criticidad. Esto puede generar rápidamente una proliferación de APIs que podría volverse incontrolable con el tiempo, especialmente si no hay políticas generales para definir cuánto tiempo pueden existir las APIs.
En ese entorno, es muy posible que algunas APIs se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también son a veces culpables. Por ejemplo, un grupo de marketing puede crear un servicio para apoyar un evento próximo, como el lanzamiento de un producto, y luego no retirarlo una vez finalizado el evento. Alguien que vea ese servicio y sus APIs asociadas más tarde podría no tener ni idea de por qué existen, y si no hay documentación, podría seguir siendo un misterio. Puede que no se sientan cómodos eliminando esas APIs del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen ni idea de lo críticas que son o de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las APIs en los frameworks mejora con el tiempo. Un investigador puede descubrir una vulnerabilidad, o se puede añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las APIs más antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers suelen buscarlas o utilizar herramientas automatizadas para buscarlas.
En un ejemplo del mundo real proporcionado por OWASP, una empresa actualizó sus APIs utilizadas para buscar en bases de datos de usuarios para parchear un fallo crítico. Pero dejaron las antiguas APIs en su lugar por error.
Un atacante se dio cuenta de que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Reemplazando la URL por (api.criticalservice.com/v1) pudieron utilizar la antigua API con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.
Eliminación de los defectos de gestión de activos inadecuados
La única manera de eliminar el defecto de gestión de activos inadecuados de su entorno es mantener un inventario estricto de todas las APIs, sus usos y versiones. Esto debe comenzar con un inventario de las APIs existentes, centrándose en factores como el entorno en el que deben desplegarse, como producción o desarrollo, quién debe tener acceso a la red y, por supuesto, su versión.
Una vez que se haya completado, es necesario implementar un proceso en el que la documentación se añada automáticamente a cualquier nueva API o servicio que se cree. Esto debería incluir todos los aspectos de la API, incluyendo la limitación de la tasa, cómo maneja las solicitudes y las respuestas, los recursos compartidos, los puntos finales a los que se puede conectar, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas posteriormente. También hay que evitar utilizar nunca en producción APIs que no sean de producción o del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las APIs en el que su uso continuado deba ser justificado por sus propietarios para evitar el desmantelamiento automático.
Siempre que estén disponibles nuevas versiones de las APIs activas, realice un riesgo assessment para determinar si debe actualizar, y cómo debe llevarse a cabo ese proceso para evitar la interrupción del entorno de producción. Una vez que hayas migrado a las nuevas APIs, elimina las antiguas por completo del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la gestión de activos inadecuada perjudique a su organización, a los usuarios o a la red. 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
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
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.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
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.