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
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.
Temas y contenidos de la formación sobre código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Temas que cubren todo, desde IA a XQuery Injection, ofrecidos para una variedad de roles desde Arquitectos e Ingenieros a Product Managers y QA. Eche un vistazo a lo que ofrece nuestro catálogo de contenidos por tema y función.
Búsqueda: Aprendizaje líder en la industria para mantener a los desarrolladores por delante mitigando el riesgo.
Quests es una learning platform que ayuda a los desarrolladores a mitigar los riesgos de seguridad del software mediante la mejora de sus habilidades de codificación segura. Con rutas de aprendizaje curadas, desafíos prácticos y actividades interactivas, capacita a los desarrolladores para identificar y prevenir vulnerabilidades.
Recursos para empezar
Inyección indirecta y riesgos de seguridad de las herramientas de codificación agéntica
Cómo se engañó a un agente de codificación para que escribiera código propenso a inyecciones SQL, instalara herramientas de shell y tal vez incluso acechara a su usuario.
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.