¿Qué es el código fuente de Trojan y cómo se infiltra en el código fuente?
A principios de noviembre, la Universidad de Cambridge publicó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de 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 a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad 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 no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo 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 de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de 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ó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de 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 a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad 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 no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo 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 de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
A principios de noviembre, la Universidad de Cambridge publicó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de 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 a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad 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 no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo 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 de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Ver informeReserva de 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ó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de 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 a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad 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 no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo 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 de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
Índice
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de demostraciónDescargarRecursos útiles para empezar
Temas y contenidos de la formación sobre códigos de seguridad
El mejor contenido del sector evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo en cuenta el papel de los clientes. Se ofrecen temas que abarcan desde la inteligencia artificial hasta la inyección de XQuery, para diversas funciones, desde arquitectos e ingenieros hasta gestores de productos y control de calidad. Eche un vistazo al contenido que ofrece el catálogo 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 útiles para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ahora está disponible bajo demanda.
Cybermon 2025 Bit the Boss ya está disponible en SCW durante todo el año. Implemente tareas de seguridad avanzadas de IA/LLM para impulsar el desarrollo de IA de seguridad a gran escala.
Explicación de la Ley de Resiliencia Cibernética: El significado del diseño de seguridad en el desarrollo de software
Descubra los requisitos y el ámbito de aplicación de la Ley de Resiliencia Cibernética (CRA) de la UE, y cómo el equipo de ingeniería puede prepararse de forma segura mediante el diseño, las prácticas, la prevención de vulnerabilidades y la creación de un entorno de desarrollo.
Factor de éxito 1: Criterios de éxito definidos y medibles
El habilitador 1 ofrece una serie de 10 partes sobre los habilitadores del éxito, mostrando cómo la codificación segura puede mejorar los resultados empresariales, como la reducción de riesgos y costes y la aceleración de la madurez de los programas a largo plazo.
