Coders Conquer Security: Share & Learn Series - Uso de componentes con vulnerabilidades conocidas
¿Qué es lo que tienen todas las aplicaciones? Los componentes, también conocidos como dependencias o bibliotecas. Hay muy poco código en el mundo que no dependa de otro código en algún momento. Incluso se empieza con una montaña de dependencias desde que se crea la aplicación!
Dado que todas las aplicaciones utilizan componentes, la mayoría de los cuales no has escrito, las vulnerabilidades dentro de los componentes que utilizas pueden convertirse en pasivos. Vamos a discutir lo que significa el uso de componentes con vulnerabilidades conocidas, lo peligroso que es, y cómo resolverlo.
Comprender el uso de componentes con vulnerabilidades conocidas
Todo software complejo tiene vulnerabilidades. Es la naturaleza de la bestia. Así que sus componentes nunca serán 100% seguros. Sin embargo, cuando se encuentran vulnerabilidades en los componentes, ¿lo sabes? ¿Está preparado para ello?
Los problemas surgen con mayor frecuencia cuando los componentes se utilizan más allá de su vida útil o después de que se encuentren vulnerabilidades. La mayoría de los componentes y bibliotecas publican parches para las vulnerabilidades de seguridad en el mismo momento en que se anuncia la vulnerabilidad o antes. Por lo tanto, cuando se descubren y anuncian vulnerabilidades en los componentes, es de suma importancia actualizarlos lo antes posible. No deje el software vulnerable en producción.
Los componentes pueden provenir de varias fuentes. A veces se compran productos de terceros que se integran directamente con el código personalizado. Estos componentes pasan a formar parte de tu código y funcionan con el mismo nivel de privilegio. Otra fuente son los proyectos de código abierto alojados en sitios como GitHub. El código abierto puede ser peligroso, ya que no todas las bibliotecas de código abierto han sido cuidadosamente examinadas o auditadas en busca de vulnerabilidades.
Los atacantes utilizan la información sobre la vulnerabilidad de los componentes en su beneficio. Como las vulnerabilidades se anuncian públicamente, los atacantes las conocen al mismo tiempo que usted. Los atacantes también tienen técnicas que pueden utilizar para averiguar qué componentes estás utilizando. Una vez que conozcan esta información, sabrán cómo atacar tu aplicación si no está parcheada.
Sepa por qué los componentes vulnerables son peligrosos
Si buscas pruebas de lo peligroso que es utilizar componentes con vulnerabilidades conocidas, no busques más que la brecha de Equifax de 2017.
En julio de 2017, Equifax, una oficina de crédito de Estados Unidos, descubrió una filtración masiva de datos que filtró la información de identificación personal de más de 147 millones de personas. El alcance y el impacto de esta violación de datos no tiene precedentes. Recientemente, han salido a la luz noticias sobre las prácticas de seguridad poco rigurosas de Equifax.
Una de esas prácticas laxas era la gestión de parches. Equifax no tenía buenas prácticas de gestión de parches, lo que significaba que sus componentes pasaban bastante tiempo sin ser parcheados. Esta fue la causa directa de la brecha.
El sitio web de Equifax utilizaba el marco web Apache Struts. Varios meses antes de que los atacantes hackearan la red, se encontró una vulnerabilidad en el marco Struts, Apache Struts CVE-2017-5638. Sin embargo, Equifax no parcheó la vulnerabilidad. Los atacantes utilizaron esta vulnerabilidad para acceder a la red de Equifax. A partir de ahí, obtuvieron acceso a un tesoro de información personal.
Muchos sitios web se basan en marcos web no escritos por la empresa. Esto es una práctica habitual, ya que construir toda la funcionalidad necesaria desde cero sería una tarea demasiado grande. Sin embargo, depender fuertemente de un marco de trabajo puede abrirle a las vulnerabilidades. No te conviertas en el próximo Equifax.
Cómo protegerse de los componentes vulnerables
No existe una fórmula mágica para protegerse del uso de componentes vulnerables. Sin embargo, hay políticas y controles que puede utilizar para mitigar el riesgo de que se utilicen componentes vulnerables para comprometer sus sistemas.
Necesitas saber qué componentes y qué versión de cada componente estás utilizando para construir tus aplicaciones. Las herramientas de gestión de dependencias, como Dependency Check de OWASP, le ayudan a saber qué dependencias está utilizando. Dependency Check también le dirá si alguno de esos componentes tiene una vulnerabilidad públicamente divulgada.
También es esencial una metodología de gestión de parches. Cuando se descubren vulnerabilidades, hay que tener un sistema para que los parches se descarguen, se prueben y se pongan en producción sin problemas. Mantener el software parcheado evita que los atacantes utilicen vulnerabilidades de hace meses.
Por último, hay que contar con políticas que regulen el uso de componentes de código abierto y de terceros. A los desarrolladores no les gusta la burocracia, y es comprensible. Sin embargo, tiene que haber un proceso de investigación para el código no escrito por su organización. No tiene que ser pesado, pero es imprescindible para evitar que se utilicen componentes desconocidos. Como mínimo, hay que mantener actualizado un inventario de los componentes utilizados.
No se deje picar por el bicho de los terceros
Los componentes tendrán vulnerabilidades. Sus aplicaciones empresariales utilizarán componentes, ya sea de un proveedor o de una biblioteca de código abierto. Esto no significa que su organización tenga que ser vulnerable a los ataques.
Aunque los atacantes saben qué vulnerabilidades existen al mismo tiempo que usted, los parches suelen estar disponibles al mismo tiempo que los anuncios públicos. Por lo tanto, asegúrese de informarse sobre lo que utiliza su aplicación. Conozca lo que es vulnerable. Mantenga sus componentes parcheados.
¿Listo para descubrir (y derrotar) a algunos componentes vulnerables? Dirígete a la arena para participar en la batalla: [Comienza aquí]


Dado que todas las aplicaciones utilizan componentes, la mayoría de los cuales no has escrito, las vulnerabilidades dentro de los componentes que utilizas pueden convertirse en pasivos. Vamos a discutir lo que significa el uso de componentes con vulnerabilidades conocidas, lo peligroso que es, y cómo resolverlo.
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

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ónJaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.


¿Qué es lo que tienen todas las aplicaciones? Los componentes, también conocidos como dependencias o bibliotecas. Hay muy poco código en el mundo que no dependa de otro código en algún momento. Incluso se empieza con una montaña de dependencias desde que se crea la aplicación!
Dado que todas las aplicaciones utilizan componentes, la mayoría de los cuales no has escrito, las vulnerabilidades dentro de los componentes que utilizas pueden convertirse en pasivos. Vamos a discutir lo que significa el uso de componentes con vulnerabilidades conocidas, lo peligroso que es, y cómo resolverlo.
Comprender el uso de componentes con vulnerabilidades conocidas
Todo software complejo tiene vulnerabilidades. Es la naturaleza de la bestia. Así que sus componentes nunca serán 100% seguros. Sin embargo, cuando se encuentran vulnerabilidades en los componentes, ¿lo sabes? ¿Está preparado para ello?
Los problemas surgen con mayor frecuencia cuando los componentes se utilizan más allá de su vida útil o después de que se encuentren vulnerabilidades. La mayoría de los componentes y bibliotecas publican parches para las vulnerabilidades de seguridad en el mismo momento en que se anuncia la vulnerabilidad o antes. Por lo tanto, cuando se descubren y anuncian vulnerabilidades en los componentes, es de suma importancia actualizarlos lo antes posible. No deje el software vulnerable en producción.
Los componentes pueden provenir de varias fuentes. A veces se compran productos de terceros que se integran directamente con el código personalizado. Estos componentes pasan a formar parte de tu código y funcionan con el mismo nivel de privilegio. Otra fuente son los proyectos de código abierto alojados en sitios como GitHub. El código abierto puede ser peligroso, ya que no todas las bibliotecas de código abierto han sido cuidadosamente examinadas o auditadas en busca de vulnerabilidades.
Los atacantes utilizan la información sobre la vulnerabilidad de los componentes en su beneficio. Como las vulnerabilidades se anuncian públicamente, los atacantes las conocen al mismo tiempo que usted. Los atacantes también tienen técnicas que pueden utilizar para averiguar qué componentes estás utilizando. Una vez que conozcan esta información, sabrán cómo atacar tu aplicación si no está parcheada.
Sepa por qué los componentes vulnerables son peligrosos
Si buscas pruebas de lo peligroso que es utilizar componentes con vulnerabilidades conocidas, no busques más que la brecha de Equifax de 2017.
En julio de 2017, Equifax, una oficina de crédito de Estados Unidos, descubrió una filtración masiva de datos que filtró la información de identificación personal de más de 147 millones de personas. El alcance y el impacto de esta violación de datos no tiene precedentes. Recientemente, han salido a la luz noticias sobre las prácticas de seguridad poco rigurosas de Equifax.
Una de esas prácticas laxas era la gestión de parches. Equifax no tenía buenas prácticas de gestión de parches, lo que significaba que sus componentes pasaban bastante tiempo sin ser parcheados. Esta fue la causa directa de la brecha.
El sitio web de Equifax utilizaba el marco web Apache Struts. Varios meses antes de que los atacantes hackearan la red, se encontró una vulnerabilidad en el marco Struts, Apache Struts CVE-2017-5638. Sin embargo, Equifax no parcheó la vulnerabilidad. Los atacantes utilizaron esta vulnerabilidad para acceder a la red de Equifax. A partir de ahí, obtuvieron acceso a un tesoro de información personal.
Muchos sitios web se basan en marcos web no escritos por la empresa. Esto es una práctica habitual, ya que construir toda la funcionalidad necesaria desde cero sería una tarea demasiado grande. Sin embargo, depender fuertemente de un marco de trabajo puede abrirle a las vulnerabilidades. No te conviertas en el próximo Equifax.
Cómo protegerse de los componentes vulnerables
No existe una fórmula mágica para protegerse del uso de componentes vulnerables. Sin embargo, hay políticas y controles que puede utilizar para mitigar el riesgo de que se utilicen componentes vulnerables para comprometer sus sistemas.
Necesitas saber qué componentes y qué versión de cada componente estás utilizando para construir tus aplicaciones. Las herramientas de gestión de dependencias, como Dependency Check de OWASP, le ayudan a saber qué dependencias está utilizando. Dependency Check también le dirá si alguno de esos componentes tiene una vulnerabilidad públicamente divulgada.
También es esencial una metodología de gestión de parches. Cuando se descubren vulnerabilidades, hay que tener un sistema para que los parches se descarguen, se prueben y se pongan en producción sin problemas. Mantener el software parcheado evita que los atacantes utilicen vulnerabilidades de hace meses.
Por último, hay que contar con políticas que regulen el uso de componentes de código abierto y de terceros. A los desarrolladores no les gusta la burocracia, y es comprensible. Sin embargo, tiene que haber un proceso de investigación para el código no escrito por su organización. No tiene que ser pesado, pero es imprescindible para evitar que se utilicen componentes desconocidos. Como mínimo, hay que mantener actualizado un inventario de los componentes utilizados.
No se deje picar por el bicho de los terceros
Los componentes tendrán vulnerabilidades. Sus aplicaciones empresariales utilizarán componentes, ya sea de un proveedor o de una biblioteca de código abierto. Esto no significa que su organización tenga que ser vulnerable a los ataques.
Aunque los atacantes saben qué vulnerabilidades existen al mismo tiempo que usted, los parches suelen estar disponibles al mismo tiempo que los anuncios públicos. Por lo tanto, asegúrese de informarse sobre lo que utiliza su aplicación. Conozca lo que es vulnerable. Mantenga sus componentes parcheados.
¿Listo para descubrir (y derrotar) a algunos componentes vulnerables? Dirígete a la arena para participar en la batalla: [Comienza aquí]

¿Qué es lo que tienen todas las aplicaciones? Los componentes, también conocidos como dependencias o bibliotecas. Hay muy poco código en el mundo que no dependa de otro código en algún momento. Incluso se empieza con una montaña de dependencias desde que se crea la aplicación!
Dado que todas las aplicaciones utilizan componentes, la mayoría de los cuales no has escrito, las vulnerabilidades dentro de los componentes que utilizas pueden convertirse en pasivos. Vamos a discutir lo que significa el uso de componentes con vulnerabilidades conocidas, lo peligroso que es, y cómo resolverlo.
Comprender el uso de componentes con vulnerabilidades conocidas
Todo software complejo tiene vulnerabilidades. Es la naturaleza de la bestia. Así que sus componentes nunca serán 100% seguros. Sin embargo, cuando se encuentran vulnerabilidades en los componentes, ¿lo sabes? ¿Está preparado para ello?
Los problemas surgen con mayor frecuencia cuando los componentes se utilizan más allá de su vida útil o después de que se encuentren vulnerabilidades. La mayoría de los componentes y bibliotecas publican parches para las vulnerabilidades de seguridad en el mismo momento en que se anuncia la vulnerabilidad o antes. Por lo tanto, cuando se descubren y anuncian vulnerabilidades en los componentes, es de suma importancia actualizarlos lo antes posible. No deje el software vulnerable en producción.
Los componentes pueden provenir de varias fuentes. A veces se compran productos de terceros que se integran directamente con el código personalizado. Estos componentes pasan a formar parte de tu código y funcionan con el mismo nivel de privilegio. Otra fuente son los proyectos de código abierto alojados en sitios como GitHub. El código abierto puede ser peligroso, ya que no todas las bibliotecas de código abierto han sido cuidadosamente examinadas o auditadas en busca de vulnerabilidades.
Los atacantes utilizan la información sobre la vulnerabilidad de los componentes en su beneficio. Como las vulnerabilidades se anuncian públicamente, los atacantes las conocen al mismo tiempo que usted. Los atacantes también tienen técnicas que pueden utilizar para averiguar qué componentes estás utilizando. Una vez que conozcan esta información, sabrán cómo atacar tu aplicación si no está parcheada.
Sepa por qué los componentes vulnerables son peligrosos
Si buscas pruebas de lo peligroso que es utilizar componentes con vulnerabilidades conocidas, no busques más que la brecha de Equifax de 2017.
En julio de 2017, Equifax, una oficina de crédito de Estados Unidos, descubrió una filtración masiva de datos que filtró la información de identificación personal de más de 147 millones de personas. El alcance y el impacto de esta violación de datos no tiene precedentes. Recientemente, han salido a la luz noticias sobre las prácticas de seguridad poco rigurosas de Equifax.
Una de esas prácticas laxas era la gestión de parches. Equifax no tenía buenas prácticas de gestión de parches, lo que significaba que sus componentes pasaban bastante tiempo sin ser parcheados. Esta fue la causa directa de la brecha.
El sitio web de Equifax utilizaba el marco web Apache Struts. Varios meses antes de que los atacantes hackearan la red, se encontró una vulnerabilidad en el marco Struts, Apache Struts CVE-2017-5638. Sin embargo, Equifax no parcheó la vulnerabilidad. Los atacantes utilizaron esta vulnerabilidad para acceder a la red de Equifax. A partir de ahí, obtuvieron acceso a un tesoro de información personal.
Muchos sitios web se basan en marcos web no escritos por la empresa. Esto es una práctica habitual, ya que construir toda la funcionalidad necesaria desde cero sería una tarea demasiado grande. Sin embargo, depender fuertemente de un marco de trabajo puede abrirle a las vulnerabilidades. No te conviertas en el próximo Equifax.
Cómo protegerse de los componentes vulnerables
No existe una fórmula mágica para protegerse del uso de componentes vulnerables. Sin embargo, hay políticas y controles que puede utilizar para mitigar el riesgo de que se utilicen componentes vulnerables para comprometer sus sistemas.
Necesitas saber qué componentes y qué versión de cada componente estás utilizando para construir tus aplicaciones. Las herramientas de gestión de dependencias, como Dependency Check de OWASP, le ayudan a saber qué dependencias está utilizando. Dependency Check también le dirá si alguno de esos componentes tiene una vulnerabilidad públicamente divulgada.
También es esencial una metodología de gestión de parches. Cuando se descubren vulnerabilidades, hay que tener un sistema para que los parches se descarguen, se prueben y se pongan en producción sin problemas. Mantener el software parcheado evita que los atacantes utilicen vulnerabilidades de hace meses.
Por último, hay que contar con políticas que regulen el uso de componentes de código abierto y de terceros. A los desarrolladores no les gusta la burocracia, y es comprensible. Sin embargo, tiene que haber un proceso de investigación para el código no escrito por su organización. No tiene que ser pesado, pero es imprescindible para evitar que se utilicen componentes desconocidos. Como mínimo, hay que mantener actualizado un inventario de los componentes utilizados.
No se deje picar por el bicho de los terceros
Los componentes tendrán vulnerabilidades. Sus aplicaciones empresariales utilizarán componentes, ya sea de un proveedor o de una biblioteca de código abierto. Esto no significa que su organización tenga que ser vulnerable a los ataques.
Aunque los atacantes saben qué vulnerabilidades existen al mismo tiempo que usted, los parches suelen estar disponibles al mismo tiempo que los anuncios públicos. Por lo tanto, asegúrese de informarse sobre lo que utiliza su aplicación. Conozca lo que es vulnerable. Mantenga sus componentes parcheados.
¿Listo para descubrir (y derrotar) a algunos componentes vulnerables? Dirígete a la arena para participar en la batalla: [Comienza aquí]

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ónJaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
¿Qué es lo que tienen todas las aplicaciones? Los componentes, también conocidos como dependencias o bibliotecas. Hay muy poco código en el mundo que no dependa de otro código en algún momento. Incluso se empieza con una montaña de dependencias desde que se crea la aplicación!
Dado que todas las aplicaciones utilizan componentes, la mayoría de los cuales no has escrito, las vulnerabilidades dentro de los componentes que utilizas pueden convertirse en pasivos. Vamos a discutir lo que significa el uso de componentes con vulnerabilidades conocidas, lo peligroso que es, y cómo resolverlo.
Comprender el uso de componentes con vulnerabilidades conocidas
Todo software complejo tiene vulnerabilidades. Es la naturaleza de la bestia. Así que sus componentes nunca serán 100% seguros. Sin embargo, cuando se encuentran vulnerabilidades en los componentes, ¿lo sabes? ¿Está preparado para ello?
Los problemas surgen con mayor frecuencia cuando los componentes se utilizan más allá de su vida útil o después de que se encuentren vulnerabilidades. La mayoría de los componentes y bibliotecas publican parches para las vulnerabilidades de seguridad en el mismo momento en que se anuncia la vulnerabilidad o antes. Por lo tanto, cuando se descubren y anuncian vulnerabilidades en los componentes, es de suma importancia actualizarlos lo antes posible. No deje el software vulnerable en producción.
Los componentes pueden provenir de varias fuentes. A veces se compran productos de terceros que se integran directamente con el código personalizado. Estos componentes pasan a formar parte de tu código y funcionan con el mismo nivel de privilegio. Otra fuente son los proyectos de código abierto alojados en sitios como GitHub. El código abierto puede ser peligroso, ya que no todas las bibliotecas de código abierto han sido cuidadosamente examinadas o auditadas en busca de vulnerabilidades.
Los atacantes utilizan la información sobre la vulnerabilidad de los componentes en su beneficio. Como las vulnerabilidades se anuncian públicamente, los atacantes las conocen al mismo tiempo que usted. Los atacantes también tienen técnicas que pueden utilizar para averiguar qué componentes estás utilizando. Una vez que conozcan esta información, sabrán cómo atacar tu aplicación si no está parcheada.
Sepa por qué los componentes vulnerables son peligrosos
Si buscas pruebas de lo peligroso que es utilizar componentes con vulnerabilidades conocidas, no busques más que la brecha de Equifax de 2017.
En julio de 2017, Equifax, una oficina de crédito de Estados Unidos, descubrió una filtración masiva de datos que filtró la información de identificación personal de más de 147 millones de personas. El alcance y el impacto de esta violación de datos no tiene precedentes. Recientemente, han salido a la luz noticias sobre las prácticas de seguridad poco rigurosas de Equifax.
Una de esas prácticas laxas era la gestión de parches. Equifax no tenía buenas prácticas de gestión de parches, lo que significaba que sus componentes pasaban bastante tiempo sin ser parcheados. Esta fue la causa directa de la brecha.
El sitio web de Equifax utilizaba el marco web Apache Struts. Varios meses antes de que los atacantes hackearan la red, se encontró una vulnerabilidad en el marco Struts, Apache Struts CVE-2017-5638. Sin embargo, Equifax no parcheó la vulnerabilidad. Los atacantes utilizaron esta vulnerabilidad para acceder a la red de Equifax. A partir de ahí, obtuvieron acceso a un tesoro de información personal.
Muchos sitios web se basan en marcos web no escritos por la empresa. Esto es una práctica habitual, ya que construir toda la funcionalidad necesaria desde cero sería una tarea demasiado grande. Sin embargo, depender fuertemente de un marco de trabajo puede abrirle a las vulnerabilidades. No te conviertas en el próximo Equifax.
Cómo protegerse de los componentes vulnerables
No existe una fórmula mágica para protegerse del uso de componentes vulnerables. Sin embargo, hay políticas y controles que puede utilizar para mitigar el riesgo de que se utilicen componentes vulnerables para comprometer sus sistemas.
Necesitas saber qué componentes y qué versión de cada componente estás utilizando para construir tus aplicaciones. Las herramientas de gestión de dependencias, como Dependency Check de OWASP, le ayudan a saber qué dependencias está utilizando. Dependency Check también le dirá si alguno de esos componentes tiene una vulnerabilidad públicamente divulgada.
También es esencial una metodología de gestión de parches. Cuando se descubren vulnerabilidades, hay que tener un sistema para que los parches se descarguen, se prueben y se pongan en producción sin problemas. Mantener el software parcheado evita que los atacantes utilicen vulnerabilidades de hace meses.
Por último, hay que contar con políticas que regulen el uso de componentes de código abierto y de terceros. A los desarrolladores no les gusta la burocracia, y es comprensible. Sin embargo, tiene que haber un proceso de investigación para el código no escrito por su organización. No tiene que ser pesado, pero es imprescindible para evitar que se utilicen componentes desconocidos. Como mínimo, hay que mantener actualizado un inventario de los componentes utilizados.
No se deje picar por el bicho de los terceros
Los componentes tendrán vulnerabilidades. Sus aplicaciones empresariales utilizarán componentes, ya sea de un proveedor o de una biblioteca de código abierto. Esto no significa que su organización tenga que ser vulnerable a los ataques.
Aunque los atacantes saben qué vulnerabilidades existen al mismo tiempo que usted, los parches suelen estar disponibles al mismo tiempo que los anuncios públicos. Por lo tanto, asegúrese de informarse sobre lo que utiliza su aplicación. Conozca lo que es vulnerable. Mantenga sus componentes parcheados.
¿Listo para descubrir (y derrotar) a algunos componentes vulnerables? Dirígete a la arena para participar en la batalla: [Comienza aquí]
Índice
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

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
Kit de motivación para el liderazgo en ingeniería
¿Necesita ayuda para conseguir la aprobación de los responsables de ingeniería para su programa SCW? Este folleto proporciona las principales ventajas que le ayudarán a comunicar la importancia de su programa de codificación segura.
La potencia de OpenText Fortify + Secure Code Warrior
OpenText Fortify y Secure Code Warrior unen sus fuerzas para ayudar a las empresas a reducir riesgos, transformar a los desarrolladores en campeones de la seguridad y fomentar la confianza de los clientes. Más información aquí.
Recursos para empezar
La Década de los Defensores: Secure Code Warrior Cumple Diez Años
Secure Code Warriorha permanecido unido, dirigiendo el barco a través de cada lección, triunfo y contratiempo durante toda una década. Estamos creciendo y listos para afrontar nuestro próximo capítulo, SCW 2.0, como líderes en gestión de riesgos para desarrolladores.
10 predicciones clave: Secure Code Warrior sobre la influencia de la IA y el diseño seguro en 2025
Las organizaciones se enfrentan a decisiones difíciles sobre el uso de la IA para apoyar la productividad a largo plazo, la sostenibilidad y el retorno de la inversión en seguridad. En los últimos años nos ha quedado claro que la IA nunca sustituirá por completo el papel del desarrollador. Desde las asociaciones entre IA y desarrolladores hasta las crecientes presiones (y confusión) en torno a las expectativas de seguridad por diseño, echemos un vistazo más de cerca a lo que podemos esperar durante el próximo año.
OWASP Top 10 para aplicaciones LLM: Novedades, cambios y cómo mantenerse seguro
Manténgase a la vanguardia de la seguridad de las aplicaciones LLM con las últimas actualizaciones del Top 10 de OWASP. Descubra qué hay de nuevo, qué ha cambiado y cómo Secure Code Warrior le equipa con recursos de aprendizaje actualizados para mitigar los riesgos en la IA Generativa.
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.