¿Qué es el código fuente del caballo de Troya y cómo se infiltra en el código fuente?
A principios de noviembre, la Universidad de Cambridge publicó un estudio denominado «Trojan Horse Source». Este estudio se centró en cómo ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Estos permiten crear código que el compilador interpreta de forma diferente a como lo haría un revisor humano.
Esta vulnerabilidad es nueva. Sin embargo, Unicode se ha utilizado indebidamente en el pasado. Por ejemplo, Unicode se ha utilizado para ocultar la extensión real de un archivo de la siguiente manera. Invertir la dirección de la última parte del nombre del archivo. Investigaciones recientes han revelado que, mientras que muchos compiladores ignoran los caracteres Unicode en el código fuente sin emitir ninguna advertencia, los editores de texto, incluidos los editores de código, pueden refluir las líneas que contienen comentarios y el código basado en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios de forma diferente a como los analiza el compilador, o en un orden diferente. Lo mismo ocurre cuando se intercambian el código y los comentarios.
Para obtener más información, lea lo siguiente. O, si desea probar el simulacro de hackeo de Trojan Source, pruébelo gratis. Misión pública. Pruébelo usted mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la forma de agrupar texto con diferentes órdenes de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). El uso de caracteres con formato de dirección específica permite reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos de los caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI Iremos a c PDI
La abreviatura RLI se separa de derecha a izquierda. Separa el texto del contexto (separado por PDI). Pop Directional Isolate), se lee de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes normalmente no procesan los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si simplemente se ignoran los caracteres de formato que especifican la dirección, se analizará el contenido siguiente.
私たちはcに行きます
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. Hasta ahora, los caracteres del formato de dirección se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Aunque un archivo adjunto de correo electrónico apareciera como «myspecialexe.doc», podría parecer inofensivo si no fuera por el RLO (override de derecha a izquierda). Los caracteres revelaban que su nombre real era «myspecialcod.exe».
Los ataques de código fuente troyano no generan errores de sintaxis ni de compilación, por lo que insertan caracteres de formato direccional en los comentarios y cadenas de caracteres presentes en el código fuente. Estos caracteres de control cambian el orden de visualización de la lógica del código y hacen que el compilador lea algo completamente diferente a lo que leería un humano.
Por ejemplo, un archivo que contiene los siguientes bytes en el siguiente orden.
Los caracteres de formato de dirección se ordenan de la siguiente manera:
Si no se invoca explícitamente el carácter de especificación de dirección, el código se renderizará de la siguiente manera.
RLO cambia el corchete de cierre por un corchete de apertura en la última línea. Lo mismo ocurre a la inversa. Al ejecutar este código, el resultado es «Usted es administrador». La comprobación de administrador está comentada, pero los caracteres de control dan la impresión de que aún existe.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo le afecta esto?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
Sin embargo, ¿cómo llega esta vulnerabilidad al código fuente? En primer lugar, este problema puede surgir cuando se utiliza código fuente procedente de fuentes poco fiables, en las que se ha pasado por alto la contribución de código malicioso. En segundo lugar,es posible que la mayoría de los desarrolladores hayan copiado y pegado código encontrado en Internet, algo que han hecho anteriormente. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Por lo tanto, surge la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede examinar el código fuente para detectar puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los procesos de compilación no deben permitir líneas de código fuente con múltiples direcciones, a menos que una de ellas esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que los caracteres de formato direccional dentro de cadenas y comentarios pueden extender el cambio de dirección hasta el final de la línea, a menos que se eliminen.En general, los editores de código deben resaltar explícitamente los caracteres Unicode dudosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, no resalta dónde se encuentran estos caracteres en la línea.A pesar de ello, es posible que se produzcan cambios de dirección maliciosos junto con cambios de dirección no maliciosos.
Es esencial que los desarrolladores y los revisores de código comprendan esto. Por ello, hemos creado una guía paso a paso que explica las vulnerabilidades. Actualmente, esta guía está disponible en Java, C#, Python, GO y PHP.
Si desea saber más, pruébenos. Simulación del código fuente del troyano (misión pública)y lea la investigación sobre el código fuente del troyano.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración
Laura Verheyde es desarrolladora de software en Secure Code Warrior y se dedica a investigar vulnerabilidades y crear contenido para Mission Lab y Coding Lab.
A principios de noviembre, la Universidad de Cambridge publicó un estudio denominado «Trojan Horse Source». Este estudio se centró en cómo ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Estos permiten crear código que el compilador interpreta de forma diferente a como lo haría un revisor humano.
Esta vulnerabilidad es nueva. Sin embargo, Unicode se ha utilizado indebidamente en el pasado. Por ejemplo, Unicode se ha utilizado para ocultar la extensión real de un archivo de la siguiente manera. Invertir la dirección de la última parte del nombre del archivo. Investigaciones recientes han revelado que, mientras que muchos compiladores ignoran los caracteres Unicode en el código fuente sin emitir ninguna advertencia, los editores de texto, incluidos los editores de código, pueden refluir las líneas que contienen comentarios y el código basado en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios de forma diferente a como los analiza el compilador, o en un orden diferente. Lo mismo ocurre cuando se intercambian el código y los comentarios.
Para obtener más información, lea lo siguiente. O, si desea probar el simulacro de hackeo de Trojan Source, pruébelo gratis. Misión pública. Pruébelo usted mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la forma de agrupar texto con diferentes órdenes de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). El uso de caracteres con formato de dirección específica permite reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos de los caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI Iremos a c PDI
La abreviatura RLI se separa de derecha a izquierda. Separa el texto del contexto (separado por PDI). Pop Directional Isolate), se lee de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes normalmente no procesan los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si simplemente se ignoran los caracteres de formato que especifican la dirección, se analizará el contenido siguiente.
私たちはcに行きます
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. Hasta ahora, los caracteres del formato de dirección se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Aunque un archivo adjunto de correo electrónico apareciera como «myspecialexe.doc», podría parecer inofensivo si no fuera por el RLO (override de derecha a izquierda). Los caracteres revelaban que su nombre real era «myspecialcod.exe».
Los ataques de código fuente troyano no generan errores de sintaxis ni de compilación, por lo que insertan caracteres de formato direccional en los comentarios y cadenas de caracteres presentes en el código fuente. Estos caracteres de control cambian el orden de visualización de la lógica del código y hacen que el compilador lea algo completamente diferente a lo que leería un humano.
Por ejemplo, un archivo que contiene los siguientes bytes en el siguiente orden.
Los caracteres de formato de dirección se ordenan de la siguiente manera:
Si no se invoca explícitamente el carácter de especificación de dirección, el código se renderizará de la siguiente manera.
RLO cambia el corchete de cierre por un corchete de apertura en la última línea. Lo mismo ocurre a la inversa. Al ejecutar este código, el resultado es «Usted es administrador». La comprobación de administrador está comentada, pero los caracteres de control dan la impresión de que aún existe.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo le afecta esto?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
Sin embargo, ¿cómo llega esta vulnerabilidad al código fuente? En primer lugar, este problema puede surgir cuando se utiliza código fuente procedente de fuentes poco fiables, en las que se ha pasado por alto la contribución de código malicioso. En segundo lugar,es posible que la mayoría de los desarrolladores hayan copiado y pegado código encontrado en Internet, algo que han hecho anteriormente. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Por lo tanto, surge la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede examinar el código fuente para detectar puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los procesos de compilación no deben permitir líneas de código fuente con múltiples direcciones, a menos que una de ellas esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que los caracteres de formato direccional dentro de cadenas y comentarios pueden extender el cambio de dirección hasta el final de la línea, a menos que se eliminen.En general, los editores de código deben resaltar explícitamente los caracteres Unicode dudosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, no resalta dónde se encuentran estos caracteres en la línea.A pesar de ello, es posible que se produzcan cambios de dirección maliciosos junto con cambios de dirección no maliciosos.
Es esencial que los desarrolladores y los revisores de código comprendan esto. Por ello, hemos creado una guía paso a paso que explica las vulnerabilidades. Actualmente, esta guía está disponible en Java, C#, Python, GO y PHP.
Si desea saber más, pruébenos. Simulación del código fuente del troyano (misión pública)y lea la investigación sobre el código fuente del troyano.
A principios de noviembre, la Universidad de Cambridge publicó un estudio denominado «Trojan Horse Source». Este estudio se centró en cómo ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Estos permiten crear código que el compilador interpreta de forma diferente a como lo haría un revisor humano.
Esta vulnerabilidad es nueva. Sin embargo, Unicode se ha utilizado indebidamente en el pasado. Por ejemplo, Unicode se ha utilizado para ocultar la extensión real de un archivo de la siguiente manera. Invertir la dirección de la última parte del nombre del archivo. Investigaciones recientes han revelado que, mientras que muchos compiladores ignoran los caracteres Unicode en el código fuente sin emitir ninguna advertencia, los editores de texto, incluidos los editores de código, pueden refluir las líneas que contienen comentarios y el código basado en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios de forma diferente a como los analiza el compilador, o en un orden diferente. Lo mismo ocurre cuando se intercambian el código y los comentarios.
Para obtener más información, lea lo siguiente. O, si desea probar el simulacro de hackeo de Trojan Source, pruébelo gratis. Misión pública. Pruébelo usted mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la forma de agrupar texto con diferentes órdenes de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). El uso de caracteres con formato de dirección específica permite reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos de los caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI Iremos a c PDI
La abreviatura RLI se separa de derecha a izquierda. Separa el texto del contexto (separado por PDI). Pop Directional Isolate), se lee de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes normalmente no procesan los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si simplemente se ignoran los caracteres de formato que especifican la dirección, se analizará el contenido siguiente.
私たちはcに行きます
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. Hasta ahora, los caracteres del formato de dirección se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Aunque un archivo adjunto de correo electrónico apareciera como «myspecialexe.doc», podría parecer inofensivo si no fuera por el RLO (override de derecha a izquierda). Los caracteres revelaban que su nombre real era «myspecialcod.exe».
Los ataques de código fuente troyano no generan errores de sintaxis ni de compilación, por lo que insertan caracteres de formato direccional en los comentarios y cadenas de caracteres presentes en el código fuente. Estos caracteres de control cambian el orden de visualización de la lógica del código y hacen que el compilador lea algo completamente diferente a lo que leería un humano.
Por ejemplo, un archivo que contiene los siguientes bytes en el siguiente orden.
Los caracteres de formato de dirección se ordenan de la siguiente manera:
Si no se invoca explícitamente el carácter de especificación de dirección, el código se renderizará de la siguiente manera.
RLO cambia el corchete de cierre por un corchete de apertura en la última línea. Lo mismo ocurre a la inversa. Al ejecutar este código, el resultado es «Usted es administrador». La comprobación de administrador está comentada, pero los caracteres de control dan la impresión de que aún existe.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo le afecta esto?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
Sin embargo, ¿cómo llega esta vulnerabilidad al código fuente? En primer lugar, este problema puede surgir cuando se utiliza código fuente procedente de fuentes poco fiables, en las que se ha pasado por alto la contribución de código malicioso. En segundo lugar,es posible que la mayoría de los desarrolladores hayan copiado y pegado código encontrado en Internet, algo que han hecho anteriormente. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Por lo tanto, surge la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede examinar el código fuente para detectar puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los procesos de compilación no deben permitir líneas de código fuente con múltiples direcciones, a menos que una de ellas esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que los caracteres de formato direccional dentro de cadenas y comentarios pueden extender el cambio de dirección hasta el final de la línea, a menos que se eliminen.En general, los editores de código deben resaltar explícitamente los caracteres Unicode dudosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, no resalta dónde se encuentran estos caracteres en la línea.A pesar de ello, es posible que se produzcan cambios de dirección maliciosos junto con cambios de dirección no maliciosos.
Es esencial que los desarrolladores y los revisores de código comprendan esto. Por ello, hemos creado una guía paso a paso que explica las vulnerabilidades. Actualmente, esta guía está disponible en Java, C#, Python, GO y PHP.
Si desea saber más, pruébenos. Simulación del código fuente del troyano (misión pública)y lea la investigación sobre el código fuente del troyano.
Haga clic en el siguiente enlace para descargar el PDF de este recurso.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Mostrar informeReservar una demostración
Laura Verheyde es desarrolladora de software en Secure Code Warrior y se dedica a investigar vulnerabilidades y crear contenido para Mission Lab y Coding Lab.
A principios de noviembre, la Universidad de Cambridge publicó un estudio denominado «Trojan Horse Source». Este estudio se centró en cómo ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Estos permiten crear código que el compilador interpreta de forma diferente a como lo haría un revisor humano.
Esta vulnerabilidad es nueva. Sin embargo, Unicode se ha utilizado indebidamente en el pasado. Por ejemplo, Unicode se ha utilizado para ocultar la extensión real de un archivo de la siguiente manera. Invertir la dirección de la última parte del nombre del archivo. Investigaciones recientes han revelado que, mientras que muchos compiladores ignoran los caracteres Unicode en el código fuente sin emitir ninguna advertencia, los editores de texto, incluidos los editores de código, pueden refluir las líneas que contienen comentarios y el código basado en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios de forma diferente a como los analiza el compilador, o en un orden diferente. Lo mismo ocurre cuando se intercambian el código y los comentarios.
Para obtener más información, lea lo siguiente. O, si desea probar el simulacro de hackeo de Trojan Source, pruébelo gratis. Misión pública. Pruébelo usted mismo.
Texto bidireccional
Uno de estos ataques de código fuente troyano utiliza el algoritmo Unicode Bidi (bidireccional), que procesa la forma de agrupar texto con diferentes órdenes de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). El uso de caracteres con formato de dirección específica permite reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos de los caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI Iremos a c PDI
La abreviatura RLI se separa de derecha a izquierda. Separa el texto del contexto (separado por PDI). Pop Directional Isolate), se lee de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes normalmente no procesan los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si simplemente se ignoran los caracteres de formato que especifican la dirección, se analizará el contenido siguiente.
私たちはcに行きます
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. Hasta ahora, los caracteres del formato de dirección se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Aunque un archivo adjunto de correo electrónico apareciera como «myspecialexe.doc», podría parecer inofensivo si no fuera por el RLO (override de derecha a izquierda). Los caracteres revelaban que su nombre real era «myspecialcod.exe».
Los ataques de código fuente troyano no generan errores de sintaxis ni de compilación, por lo que insertan caracteres de formato direccional en los comentarios y cadenas de caracteres presentes en el código fuente. Estos caracteres de control cambian el orden de visualización de la lógica del código y hacen que el compilador lea algo completamente diferente a lo que leería un humano.
Por ejemplo, un archivo que contiene los siguientes bytes en el siguiente orden.
Los caracteres de formato de dirección se ordenan de la siguiente manera:
Si no se invoca explícitamente el carácter de especificación de dirección, el código se renderizará de la siguiente manera.
RLO cambia el corchete de cierre por un corchete de apertura en la última línea. Lo mismo ocurre a la inversa. Al ejecutar este código, el resultado es «Usted es administrador». La comprobación de administrador está comentada, pero los caracteres de control dan la impresión de que aún existe.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo le afecta esto?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
Sin embargo, ¿cómo llega esta vulnerabilidad al código fuente? En primer lugar, este problema puede surgir cuando se utiliza código fuente procedente de fuentes poco fiables, en las que se ha pasado por alto la contribución de código malicioso. En segundo lugar,es posible que la mayoría de los desarrolladores hayan copiado y pegado código encontrado en Internet, algo que han hecho anteriormente. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Por lo tanto, surge la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede examinar el código fuente para detectar puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los procesos de compilación no deben permitir líneas de código fuente con múltiples direcciones, a menos que una de ellas esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que los caracteres de formato direccional dentro de cadenas y comentarios pueden extender el cambio de dirección hasta el final de la línea, a menos que se eliminen.En general, los editores de código deben resaltar explícitamente los caracteres Unicode dudosos, como los homógrafos y los caracteres de formato direccional. Desde noviembre, GitHub añade un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, no resalta dónde se encuentran estos caracteres en la línea.A pesar de ello, es posible que se produzcan cambios de dirección maliciosos junto con cambios de dirección no maliciosos.
Es esencial que los desarrolladores y los revisores de código comprendan esto. Por ello, hemos creado una guía paso a paso que explica las vulnerabilidades. Actualmente, esta guía está disponible en Java, C#, Python, GO y PHP.
Si desea saber más, pruébenos. Simulación del código fuente del troyano (misión pública)y lea la investigación sobre el código fuente del troyano.
Índice
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración[Descargar]Recursos para empezar
Temas y contenidos de la formación en código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo siempre en cuenta las funciones de nuestros clientes. Abarca todo tipo de temas, desde la inteligencia artificial hasta la inyección de XQuery, y está diseñado para satisfacer las necesidades de diversos perfiles, desde arquitectos e ingenieros hasta gestores de productos y responsables de control de calidad. Echemos un vistazo al contenido que ofrece nuestro catálogo, clasificado 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: la misión de IA para derrotar al jefe ya está disponible bajo demanda.
Ahora se puede jugar a «Cybermon 2025 Beat the Boss» en SCW durante todo el año. Introduzca retos de seguridad avanzados de IA/LLM y refuerce a gran escala el desarrollo seguro de la IA.
Explicación de la Ley de Resiliencia Cibernética: su significado para el desarrollo de software seguro desde el diseño
Descubra qué exige la Ley de Resiliencia Cibernética (CRA) de la UE, a quién se aplica y cómo puede prepararse el equipo de ingeniería para las prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el desarrollo de las capacidades de los desarrolladores.
Enable 1: Criterios de éxito predefinidos y medibles
Enabler 1 es la primera parte de la serie Enablers of Success, compuesta por diez partes, y presenta cómo madurar un programa a largo plazo vinculando la codificación segura con resultados empresariales como la reducción de riesgos y la velocidad.
