コーダーがセキュリティを征服：共有して学ぶシリーズ：安全でないダイレクトオブジェクトリファレンス
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
直接オブジェクト参照とは、特定のレコード (「オブジェクト」) がアプリケーション内で参照されることです。通常は一意の識別子の形をとり、URL に表示されることもあります。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
Haga clic en el siguiente enlace para descargar el PDF de este recurso.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Mostrar informeReservar una demostración
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
Índice
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración[Descargar]Recursos para empezar
Temas y contenidos de la formación en código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo siempre en cuenta las funciones de nuestros clientes. Abarca todo tipo de temas, desde la inteligencia artificial hasta la inyección de XQuery, y está diseñado para satisfacer las necesidades de diversos perfiles, desde arquitectos e ingenieros hasta gestores de productos y responsables de control de calidad. Echemos un vistazo al contenido que ofrece nuestro catálogo, clasificado por temas y funciones.
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.
%20(1).avif)
.avif)
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 ha vuelto: la misión de IA para derrotar al jefe ya está disponible bajo demanda.
Ahora se puede jugar a «Cybermon 2025 Beat the Boss» en SCW durante todo el año. Introduzca retos de seguridad avanzados de IA/LLM y refuerce a gran escala el desarrollo seguro de la IA.
Explicación de la Ley de Resiliencia Cibernética: su significado para el desarrollo de software seguro desde el diseño
Descubra qué exige la Ley de Resiliencia Cibernética (CRA) de la UE, a quién se aplica y cómo puede prepararse el equipo de ingeniería para las prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el desarrollo de las capacidades de los desarrolladores.
Enable 1: Criterios de éxito predefinidos y medibles
Enabler 1 es la primera parte de la serie Enablers of Success, compuesta por diez partes, y presenta cómo madurar un programa a largo plazo vinculando la codificación segura con resultados empresariales como la reducción de riesgos y la velocidad.
