SCW Icons
hero bg no divider
Blog

¿Los proveedores de software se preocupan tanto por la seguridad como usted?

Matias Madou, Ph.D.
Published Sep 11, 2023
Last updated on Mar 06, 2026

Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.

Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.

Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.

Y todo ocurrió porque las personas confiaban en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.

El cambio masivo hacia la seguridad de la cadena de suministro

Una vez que se dio la alarma, las empresas, organizaciones y agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.

Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.

Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger la nube». El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.

Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del software.

¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?

La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. ¿Qué puede hacer una organización para garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?

La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.

Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.

Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.

Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.

Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (ni una medida del éxito) en su mundo contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.

¿Próximos pasos?

Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.

Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.

Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.

Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.

Ver recurso
Ver recurso

Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno.

¿Interesado en más?

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.

learn more

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
Comparte en:
linkedin brandsSocialx logo
autor
Matias Madou, Ph.D.
Published Sep 11, 2023

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.

Comparte en:
linkedin brandsSocialx logo

Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.

Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.

Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.

Y todo ocurrió porque las personas confiaban en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.

El cambio masivo hacia la seguridad de la cadena de suministro

Una vez que se dio la alarma, las empresas, organizaciones y agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.

Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.

Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger la nube». El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.

Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del software.

¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?

La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. ¿Qué puede hacer una organización para garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?

La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.

Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.

Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.

Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.

Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (ni una medida del éxito) en su mundo contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.

¿Próximos pasos?

Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.

Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.

Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.

Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.

Ver recurso
Ver recurso

Rellene el siguiente formulario para descargar el informe

Nos gustaría recibir su permiso para enviarle información sobre nuestros productos o temas relacionados con la codificación segura. Siempre trataremos tus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
scw success icon
scw error icon
Para enviar el formulario, habilite las cookies de «análisis». No dudes en volver a desactivarlas una vez que hayas terminado.

Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.

Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.

Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.

Y todo ocurrió porque las personas confiaban en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.

El cambio masivo hacia la seguridad de la cadena de suministro

Una vez que se dio la alarma, las empresas, organizaciones y agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.

Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.

Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger la nube». El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.

Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del software.

¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?

La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. ¿Qué puede hacer una organización para garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?

La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.

Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.

Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.

Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.

Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (ni una medida del éxito) en su mundo contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.

¿Próximos pasos?

Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.

Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.

Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.

Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.

Ver seminario web
Comenzar
learn more

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
Ver recurso
Comparte en:
linkedin brandsSocialx logo
¿Interesado en más?

Comparte en:
linkedin brandsSocialx logo
autor
Matias Madou, Ph.D.
Published Sep 11, 2023

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.

Comparte en:
linkedin brandsSocialx logo

Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.

Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.

Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.

Y todo ocurrió porque las personas confiaban en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.

El cambio masivo hacia la seguridad de la cadena de suministro

Una vez que se dio la alarma, las empresas, organizaciones y agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.

Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.

Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger la nube». El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.

Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del software.

¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?

La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. ¿Qué puede hacer una organización para garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?

La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.

Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.

Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.

Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.

Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (ni una medida del éxito) en su mundo contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.

¿Próximos pasos?

Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.

Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.

Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.

Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.

Tabla de contenido

Descargar PDF
Ver recurso
¿Interesado en más?

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.

learn more

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ónDescargar
Comparte en:
linkedin brandsSocialx logo
Centro de recursos

Recursos para empezar

Más publicaciones
Centro de recursos

Recursos para empezar

Más publicaciones