Los programadores conquistan la infraestructura de seguridad como series de códigos, utilizando componentes de fuentes no confiables
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
El comportamiento que induce la vulnerabilidad en el que nos vamos a centrar aquí es el uso de código de fuentes que no son de confianza, una práctica aparentemente benigna que está causando grandes problemas.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior está 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.
Reserva una demostración
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está 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 informeReserva una demostración
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Tabla de contenido
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior está 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.
Reserva 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.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
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.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 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.
