¿Qué es Trojan Source y cómo se cuela en tu código fuente?
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Sigue leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional se insertaban en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (anulación de derecha a izquierda) presente que revela que el nombre real es «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación no deberían permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la Investigación de fuentes troyanas.
Secure Code Warrior aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserve 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.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Sigue leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional se insertaban en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (anulación de derecha a izquierda) presente que revela que el nombre real es «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación no deberían permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la Investigación de fuentes troyanas.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Sigue leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional se insertaban en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (anulación de derecha a izquierda) presente que revela que el nombre real es «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación no deberían permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la Investigación de fuentes troyanas.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserve 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.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar las puertas traseras en el código fuente y los comentarios, utilizando caracteres de formato direccional. Se pueden usar para crear código cuya lógica sea interpretada de manera diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de manera nefasta en el pasado, por ejemplo, al ocultar la verdadera extensión del nombre de archivo de un archivo al invertir la dirección de la última parte de un nombre de archivo. La investigación reciente reveló que muchos compiladores ignoran los caracteres Unicode del código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reorganizar las líneas que contienen comentarios y código basado en ellos. Por lo tanto, es posible que el editor muestre el código y los comentarios de forma diferente y en un orden diferente al que los analizará el compilador, incluso intercambiando código y comentarios.
Sigue leyendo para obtener más información. O si quieres ponerte manos a la obra y probar el hackeo simulado de Trojan Source, entra en nuestra página gratuita y misión pública para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de Trojan-Source utiliza el algoritmo Unicode Bidi (bidireccional), que se encarga de cómo juntar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional se pueden utilizar para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los personajes anulados de Bidi relacionados con el ataque. Tomemos, por ejemplo,
RLI e d a c PDI
La abreviatura RLI significa Aislar de derecha a izquierda. Aislará el texto de su contexto (delimitado por PDI, Aislamiento direccional pop), y lo leerá de derecha a izquierda. Dando como resultado:
c a d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las anulaciones de Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, analizarán:
e d a c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, los caracteres de formato direccional se insertaban en los nombres de los archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparezca como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (anulación de derecha a izquierda) presente que revela que el nombre real es «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que no generarán ningún error de sintaxis o compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente al que leería un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera según los caracteres de formato direccional
haciendo que el código se represente de la siguiente manera si los caracteres de formato direccional no se invocan explícitamente:
El RLO convierte el corsé de cierre en un corsé de apertura y viceversa en la última línea. El resultado de ejecutar este código sería: «Eres un administrador». La comprobación de administración estaba comentada, pero los caracteres de control dan la impresión de que aún estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría desaprobar el hecho de ver caracteres de formato direccional en el código fuente, pero un novato también podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca hay garantía de que vayan a ser detectados.
Pero, ¿cómo pudo esta vulnerabilidad colarse en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables, en las que las contribuciones de código malintencionado han pasado desapercibidas. En segundo lugar, podría ocurrir simplemente copiando y pegando código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones confían en componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y las canalizaciones de compilación no deberían permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Ten en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no aparece, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deben representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglíficos y los caracteres de formato direccional. Desde noviembre, GitHub ahora agrega una señal y un mensaje de advertencia a cada línea de código que contenga texto Unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto aún puede permitir que se introduzcan cambios de dirección maliciosos junto con cambios de dirección benignos.
Es esencial que los desarrolladores y revisores de código estén concienciados, por eso hemos creado un tutorial que ilustra la vulnerabilidad. Actualmente, este tutorial está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la Investigación de fuentes troyanas.
Tabla de contenido
Secure Code Warrior aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserve una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El habilitador 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
