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
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
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.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.