Blog

Coders Conquer Security: Share & Learn Series - Uso de componentes con vulnerabilidades conocidas

Jaap Karan Singh
Publicado el 25 de abril de 2019

¿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í]

Ver recurso
Ver recurso

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.

¿Quiere saber más?

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ón
Compartir en:
Autor
Jaap Karan Singh
Publicado el 25 de abril de 2019

Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Compartir en:

¿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í]

Ver recurso
Ver recurso

Rellene el siguiente formulario para descargar el informe

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.

¿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í]

Acceso a recursos

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ón
Descargar PDF
Ver recurso
Compartir en:
¿Quiere saber más?

Compartir en:
Autor
Jaap Karan Singh
Publicado el 25 de abril de 2019

Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Compartir en:

¿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

Descargar PDF
Ver recurso
¿Quiere saber más?

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ónDescargar
Compartir en:
Centro de recursos

Recursos para empezar

Más entradas
Centro de recursos

Recursos para empezar

Más entradas