
¿Los proveedores de software se preocupan tanto por la seguridad como usted?
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.


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.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior 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.
Reserve una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.


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.

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.

Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior 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 informeReserve una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
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
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior 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.
Reserve 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.
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.
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon 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.
Facilitador 1: Criterios de éxito definidos y medibles
El habilitador 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.




%20(1).avif)
.avif)
