¿Qué es Trojan Source y cómo se cuela en su código fuente?
A principios de noviembre, la Universidad de Cambridge publicó su investigación titulada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar puertas traseras utilizando caracteres de formato direccionales en el código fuente y en los comentarios. Estos pueden utilizarse para crear código cuya lógica es interpretada de forma diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma indebida en el pasado, por ejemplo, ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte del nombre del archivo. Las investigaciones más recientes han revelado que muchos compiladores ignoran los caracteres Unicode en el código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reordenar las líneas con comentarios y el código basado en ellos. Por lo tanto, puede ocurrir que el editor muestre el código y los comentarios de forma diferente y en un orden distinto al que los analiza el compilador, incluso intercambiando el código y los comentarios.
Siga leyendo para obtener más información. O si desea arremangarse y probar el hackeo simulado de Trojan Source, visite nuestra misión pública y gratuita para experimentarlo por sí mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la combinación de 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 caracteres de anulación bidireccional relevantes para el ataque. Tomemos, por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa «aislar de derecha a izquierda». Aislará el texto de su contexto (delimitado por PDI, aislamiento direccional emergente) y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las sobrescrituras bidireccionales, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccionales, analizan:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado , se utilizaban caracteres de formato direccional en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparece como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (sobrescritura de derecha a izquierda) presente, que indica el nombre real «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccionales en comentarios y cadenas de caracteres del código fuente, ya que estos no generan errores de sintaxis ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, de modo que el compilador lee algo completamente diferente a lo que lee un ser humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
Se reordena de la siguiente manera según los signos de formato direccionales.
De este modo, el código se renderiza de la siguiente manera cuando no se invocan explícitamente los caracteres para el formato direccional:
El RLO convierte el corchete de cierre en un corchete de apertura y viceversa en la última línea. El resultado de la ejecución de este código sería: «Usted es administrador». La comprobación de administrador se ha comentado, pero los caracteres de control dan la impresión de que todavía estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarte eso?
Muchos lenguajes son vulnerables a este ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se cree que hay más. Ahora bien, es posible que al desarrollador medio no le guste ver caracteres de formato direccional en el código fuente, pero un principiante podría encogerse de hombros y no darle importancia. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca se puede garantizar que se reconozcan.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente? En primer lugar, esto puede suceder cuando se utiliza código fuente de fuentes no fiables, en las que se han pasado por alto contribuciones de código malicioso. En segundo lugar, podría deberse a la simple copia y pegado de código de Internet, algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las empresas dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código y depender de él. ¿Cómo podemos buscar código fuente que contenga puertas traseras ocultas?
¿De quién es ese problema?
Por un lado, los compiladores y los procesos de compilación deberían prohibir las líneas de código fuente con más de una dirección, a menos que una dirección se limite estrictamente a cadenas de caracteres y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena de caracteres o un comentario puede prolongar un cambio de dirección hasta el final de la línea si no se muestra. En general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un signo de advertencia y un mensaje a cada línea de código que contiene texto Unicode bidireccional, aunque no resalta dónde se encuentran estos caracteres en la línea. Esto puede seguir dando lugar a que se cuelen cambios de dirección maliciosos junto con cambios de dirección inofensivos.
Es imprescindible sensibilizar a los desarrolladores y revisores de código al respecto. Por este motivo, hemos creado una solución completa que ilustra la vulnerabilidad de seguridad. Actualmente, esta solución completa está disponible para Java, C#, Python, GO y PHP.
Si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la investigación sobre las fuentes troyanas.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al 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.
A principios de noviembre, la Universidad de Cambridge publicó su investigación titulada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar puertas traseras utilizando caracteres de formato direccionales en el código fuente y en los comentarios. Estos pueden utilizarse para crear código cuya lógica es interpretada de forma diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma indebida en el pasado, por ejemplo, ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte del nombre del archivo. Las investigaciones más recientes han revelado que muchos compiladores ignoran los caracteres Unicode en el código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reordenar las líneas con comentarios y el código basado en ellos. Por lo tanto, puede ocurrir que el editor muestre el código y los comentarios de forma diferente y en un orden distinto al que los analiza el compilador, incluso intercambiando el código y los comentarios.
Siga leyendo para obtener más información. O si desea arremangarse y probar el hackeo simulado de Trojan Source, visite nuestra misión pública y gratuita para experimentarlo por sí mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la combinación de 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 caracteres de anulación bidireccional relevantes para el ataque. Tomemos, por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa «aislar de derecha a izquierda». Aislará el texto de su contexto (delimitado por PDI, aislamiento direccional emergente) y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las sobrescrituras bidireccionales, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccionales, analizan:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado , se utilizaban caracteres de formato direccional en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparece como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (sobrescritura de derecha a izquierda) presente, que indica el nombre real «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccionales en comentarios y cadenas de caracteres del código fuente, ya que estos no generan errores de sintaxis ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, de modo que el compilador lee algo completamente diferente a lo que lee un ser humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
Se reordena de la siguiente manera según los signos de formato direccionales.
De este modo, el código se renderiza de la siguiente manera cuando no se invocan explícitamente los caracteres para el formato direccional:
El RLO convierte el corchete de cierre en un corchete de apertura y viceversa en la última línea. El resultado de la ejecución de este código sería: «Usted es administrador». La comprobación de administrador se ha comentado, pero los caracteres de control dan la impresión de que todavía estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarte eso?
Muchos lenguajes son vulnerables a este ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se cree que hay más. Ahora bien, es posible que al desarrollador medio no le guste ver caracteres de formato direccional en el código fuente, pero un principiante podría encogerse de hombros y no darle importancia. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca se puede garantizar que se reconozcan.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente? En primer lugar, esto puede suceder cuando se utiliza código fuente de fuentes no fiables, en las que se han pasado por alto contribuciones de código malicioso. En segundo lugar, podría deberse a la simple copia y pegado de código de Internet, algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las empresas dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código y depender de él. ¿Cómo podemos buscar código fuente que contenga puertas traseras ocultas?
¿De quién es ese problema?
Por un lado, los compiladores y los procesos de compilación deberían prohibir las líneas de código fuente con más de una dirección, a menos que una dirección se limite estrictamente a cadenas de caracteres y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena de caracteres o un comentario puede prolongar un cambio de dirección hasta el final de la línea si no se muestra. En general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un signo de advertencia y un mensaje a cada línea de código que contiene texto Unicode bidireccional, aunque no resalta dónde se encuentran estos caracteres en la línea. Esto puede seguir dando lugar a que se cuelen cambios de dirección maliciosos junto con cambios de dirección inofensivos.
Es imprescindible sensibilizar a los desarrolladores y revisores de código al respecto. Por este motivo, hemos creado una solución completa que ilustra la vulnerabilidad de seguridad. Actualmente, esta solución completa está disponible para Java, C#, Python, GO y PHP.
Si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la investigación sobre las fuentes troyanas.
A principios de noviembre, la Universidad de Cambridge publicó su investigación titulada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar puertas traseras utilizando caracteres de formato direccionales en el código fuente y en los comentarios. Estos pueden utilizarse para crear código cuya lógica es interpretada de forma diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma indebida en el pasado, por ejemplo, ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte del nombre del archivo. Las investigaciones más recientes han revelado que muchos compiladores ignoran los caracteres Unicode en el código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reordenar las líneas con comentarios y el código basado en ellos. Por lo tanto, puede ocurrir que el editor muestre el código y los comentarios de forma diferente y en un orden distinto al que los analiza el compilador, incluso intercambiando el código y los comentarios.
Siga leyendo para obtener más información. O si desea arremangarse y probar el hackeo simulado de Trojan Source, visite nuestra misión pública y gratuita para experimentarlo por sí mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la combinación de 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 caracteres de anulación bidireccional relevantes para el ataque. Tomemos, por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa «aislar de derecha a izquierda». Aislará el texto de su contexto (delimitado por PDI, aislamiento direccional emergente) y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las sobrescrituras bidireccionales, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccionales, analizan:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado , se utilizaban caracteres de formato direccional en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparece como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (sobrescritura de derecha a izquierda) presente, que indica el nombre real «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccionales en comentarios y cadenas de caracteres del código fuente, ya que estos no generan errores de sintaxis ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, de modo que el compilador lee algo completamente diferente a lo que lee un ser humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
Se reordena de la siguiente manera según los signos de formato direccionales.
De este modo, el código se renderiza de la siguiente manera cuando no se invocan explícitamente los caracteres para el formato direccional:
El RLO convierte el corchete de cierre en un corchete de apertura y viceversa en la última línea. El resultado de la ejecución de este código sería: «Usted es administrador». La comprobación de administrador se ha comentado, pero los caracteres de control dan la impresión de que todavía estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarte eso?
Muchos lenguajes son vulnerables a este ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se cree que hay más. Ahora bien, es posible que al desarrollador medio no le guste ver caracteres de formato direccional en el código fuente, pero un principiante podría encogerse de hombros y no darle importancia. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca se puede garantizar que se reconozcan.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente? En primer lugar, esto puede suceder cuando se utiliza código fuente de fuentes no fiables, en las que se han pasado por alto contribuciones de código malicioso. En segundo lugar, podría deberse a la simple copia y pegado de código de Internet, algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las empresas dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código y depender de él. ¿Cómo podemos buscar código fuente que contenga puertas traseras ocultas?
¿De quién es ese problema?
Por un lado, los compiladores y los procesos de compilación deberían prohibir las líneas de código fuente con más de una dirección, a menos que una dirección se limite estrictamente a cadenas de caracteres y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena de caracteres o un comentario puede prolongar un cambio de dirección hasta el final de la línea si no se muestra. En general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un signo de advertencia y un mensaje a cada línea de código que contiene texto Unicode bidireccional, aunque no resalta dónde se encuentran estos caracteres en la línea. Esto puede seguir dando lugar a que se cuelen cambios de dirección maliciosos junto con cambios de dirección inofensivos.
Es imprescindible sensibilizar a los desarrolladores y revisores de código al respecto. Por este motivo, hemos creado una solución completa que ilustra la vulnerabilidad de seguridad. Actualmente, esta solución completa está disponible para Java, C#, Python, GO y PHP.
Si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la investigación sobre las fuentes troyanas.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Ver 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.
A principios de noviembre, la Universidad de Cambridge publicó su investigación titulada Trojan-Source. Esta investigación se centró en cómo se pueden ocultar puertas traseras utilizando caracteres de formato direccionales en el código fuente y en los comentarios. Estos pueden utilizarse para crear código cuya lógica es interpretada de forma diferente por el compilador que por un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma indebida en el pasado, por ejemplo, ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte del nombre del archivo. Las investigaciones más recientes han revelado que muchos compiladores ignoran los caracteres Unicode en el código fuente sin previo aviso, mientras que los editores de texto, incluidos los editores de código, pueden reordenar las líneas con comentarios y el código basado en ellos. Por lo tanto, puede ocurrir que el editor muestre el código y los comentarios de forma diferente y en un orden distinto al que los analiza el compilador, incluso intercambiando el código y los comentarios.
Siga leyendo para obtener más información. O si desea arremangarse y probar el hackeo simulado de Trojan Source, visite nuestra misión pública y gratuita para experimentarlo por sí mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la combinación de 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 caracteres de anulación bidireccional relevantes para el ataque. Tomemos, por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa «aislar de derecha a izquierda». Aislará el texto de su contexto (delimitado por PDI, aislamiento direccional emergente) y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidas las sobrescrituras bidireccionales, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccionales, analizan:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado , se utilizaban caracteres de formato direccional en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico que aparece como «myspecialexe.doc» podría parecer bastante inocente si no fuera por el carácter RLO (sobrescritura de derecha a izquierda) presente, que indica el nombre real «myspecialcod.exe».
El ataque Trojan Source inserta caracteres de formato direccionales en comentarios y cadenas de caracteres del código fuente, ya que estos no generan errores de sintaxis ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, de modo que el compilador lee algo completamente diferente a lo que lee un ser humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
Se reordena de la siguiente manera según los signos de formato direccionales.
De este modo, el código se renderiza de la siguiente manera cuando no se invocan explícitamente los caracteres para el formato direccional:
El RLO convierte el corchete de cierre en un corchete de apertura y viceversa en la última línea. El resultado de la ejecución de este código sería: «Usted es administrador». La comprobación de administrador se ha comentado, pero los caracteres de control dan la impresión de que todavía estaba presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarte eso?
Muchos lenguajes son vulnerables a este ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se cree que hay más. Ahora bien, es posible que al desarrollador medio no le guste ver caracteres de formato direccional en el código fuente, pero un principiante podría encogerse de hombros y no darle importancia. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca se puede garantizar que se reconozcan.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente? En primer lugar, esto puede suceder cuando se utiliza código fuente de fuentes no fiables, en las que se han pasado por alto contribuciones de código malicioso. En segundo lugar, podría deberse a la simple copia y pegado de código de Internet, algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las empresas dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto podemos confiar plenamente en este código y depender de él. ¿Cómo podemos buscar código fuente que contenga puertas traseras ocultas?
¿De quién es ese problema?
Por un lado, los compiladores y los procesos de compilación deberían prohibir las líneas de código fuente con más de una dirección, a menos que una dirección se limite estrictamente a cadenas de caracteres y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena de caracteres o un comentario puede prolongar un cambio de dirección hasta el final de la línea si no se muestra. En general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un signo de advertencia y un mensaje a cada línea de código que contiene texto Unicode bidireccional, aunque no resalta dónde se encuentran estos caracteres en la línea. Esto puede seguir dando lugar a que se cuelen cambios de dirección maliciosos junto con cambios de dirección inofensivos.
Es imprescindible sensibilizar a los desarrolladores y revisores de código al respecto. Por este motivo, hemos creado una solución completa que ilustra la vulnerabilidad de seguridad. Actualmente, esta solución completa está disponible para Java, C#, Python, GO y PHP.
Si quieres saber más, prueba nuestra simulación (misiones públicas) de Trojan Source y lee la investigación sobre las fuentes troyanas.
Índice
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Temas y contenidos de la formación Securecode
Nuestros contenidos líderes en el sector se desarrollan continuamente para adaptarse al cambiante panorama del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la inteligencia artificial hasta la inyección XQuery y que se ofrecen para una amplia variedad de funciones, desde arquitectos e ingenieros hasta gestores de productos y control de calidad. Eche un vistazo a nuestro catálogo de contenidos por temas y funciones.
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 ha vuelto: ¡Derrota al jefe! Las misiones KI ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Utiliza requisitos de seguridad avanzados de IA/LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Resiliencia Cibernética: qué significa para el desarrollo de software Secure by Design
Descubra qué exige la Ley de Ciberresiliencia de la UE (CRA), a quién se aplica y cómo los equipos de desarrollo pueden prepararse para ella mediante métodos seguros, la prevención de vulnerabilidades de seguridad y el desarrollo de capacidades para los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 abre nuestra serie de diez partes titulada «Facilitadores del éxito» y muestra cómo la codificación segura puede combinarse con resultados empresariales como la reducción de riesgos y la velocidad para lograr la madurez del programa a largo plazo.
