
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 est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.


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.

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
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.
Table des matières
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour débuter
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu de pointe évolue constamment afin de s'adapter au paysage changeant du développement logiciel, en tenant compte de votre rôle. Nous proposons des thèmes allant de l'IA à l'injection XQuery pour différents postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par thème et par fonction.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions IA de Beat the Boss sont désormais disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année chez SCW. Mettez en œuvre des défis de sécurité avancés basés sur l'IA et le LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer grâce à des pratiques de conception sécurisées, à la prévention des vulnérabilités et au développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en 10 parties intitulée « Les catalyseurs de la réussite », qui montre comment relier la codification sécurisée aux résultats commerciaux, tels que la réduction des risques et la rapidité d'atteinte de la maturité du programme à long terme.




%20(1).avif)
.avif)
