SolarWinds: ¿Debería la seguridad estar en InfoSec o en DevOps?

El ciberataque a SolarWinds, descubierto en diciembre de 2020, sigue siendo una de las brechas de seguridad más importantes en la cadena de suministro de software de la historia. Los atacantes insertaron una puerta trasera maliciosa en el pipeline de compilación de software Orion de SolarWinds, que posteriormente fue firmada por la infraestructura de firma de código de SolarWinds y distribuida como una actualización legítima a aproximadamente 18,000 clientes, incluidas importantes agencias gubernamentales de EE. UU. El ataque influyó directamente en la Orden Ejecutiva 14028, el Marco de Desarrollo de Software Seguro (SSDF) del NIST y la iniciativa Secure by Design de CISA, transformando la manera en que las organizaciones conciben la seguridad del pipeline de compilación, los controles de firma de código y la visibilidad de la cadena de suministro de software. El incidente también intensificó el debate sobre dónde debería residir la responsabilidad de la seguridad: en una función de InfoSec independiente, en los equipos de DevOps o en un modelo DevSecOps integrado. La acción recomendada: el ataque a SolarWinds no fue un fallo de InfoSec ni un fallo de DevOps aislado; fue un fallo de integridad del pipeline de compilación que requirió tanto experiencia en seguridad (para definir los controles) como operaciones de desarrollo (para implementarlos). La respuesta es DevSecOps, donde InfoSec se encarga de las políticas y la arquitectura, y los equipos de desarrollo se encargan de la implementación de dichas políticas en el proceso. Para el marco de desarrollo de software seguro que surgió directamente de este incidente, consulte Marco de desarrollo de software seguro para garantizar la corrección del código . Para controles de firma de código que protegen la integridad del proceso de compilación, consulte CodeSign Secure.

Respuesta rápida: ¿Dónde debería ubicarse la seguridad después de SolarWinds?

El ataque a SolarWinds demostró que la disyuntiva entre InfoSec y DevOps es una falsa elección. El ataque explotó una brecha que ni un modelo InfoSec tradicional ni un modelo DevOps sin integración de seguridad habrían podido cerrar: los equipos de InfoSec no suelen monitorizar los procesos de la canalización de compilación en tiempo real, y los equipos de DevOps sin controles de seguridad no implementan la monitorización de la integridad de la compilación por defecto. La solución reside en un modelo DevSecOps donde InfoSec define la política de seguridad, los estándares de arquitectura y los requisitos de cumplimiento; DevOps implementa dichos requisitos mediante puertas de seguridad automatizadas en la canalización de CI/CD; y ambos equipos comparten la responsabilidad de la integridad de la cadena de suministro de software. La firma de código con claves protegidas por HSM y la monitorización de la integridad del entorno de compilación son los dos controles más directamente vulnerables al patrón de ataque de SolarWinds.

El ataque a SolarWinds: ¿Qué sucedió?

Descubierto en diciembre de 2020, el ciberataque a SolarWinds consistió en que los atacantes comprometieron el sistema de compilación del software Orion de SolarWinds e insertaron una sofisticada puerta trasera llamada SUNBURST en el mecanismo de actualización del software. El proceso de compilación compiló y empaquetó el código malicioso con normalidad, y la infraestructura de firma de código de SolarWinds firmó la actualización resultante con certificados válidos de SolarWinds, lo que hizo que la actualización comprometida fuera indistinguible de una versión legítima. La actualización se distribuyó a aproximadamente 18 000 clientes de SolarWinds, incluidos el Departamento de Seguridad Nacional de EE. UU., el Departamento del Tesoro y numerosas otras agencias gubernamentales y empresas privadas.

El ataque a SolarWinds fue un ataque a la cadena de suministro : los atacantes se dirigieron a un proveedor de software externo en lugar de a las propias organizaciones, utilizando el canal de distribución de confianza de dicho proveedor para distribuir software malicioso a sus clientes. Este vector de ataque es particularmente efectivo porque los clientes no tienen motivos para desconfiar de las actualizaciones de software que cuentan con una firma válida de un proveedor de confianza. El ataque puso de manifiesto la importancia crítica de la seguridad en la cadena de suministro de software y, específicamente, de los controles de integridad del proceso de compilación que impiden que código no autorizado se firme y distribuya como software legítimo.

Seguridad de la información y DevOps: ¿Qué son?

Antes de abordar la cuestión de dónde debe residir la seguridad, es importante comprender qué son InfoSec y DevOps y para qué está optimizado cada modelo.

La seguridad de la información (InfoSec) implica proteger los sistemas de información, las redes y los datos contra el acceso, uso, divulgación, interrupción, modificación o destrucción no autorizados. Los equipos de InfoSec identifican vulnerabilidades, desarrollan políticas de seguridad y capacitan a los usuarios sobre las mejores prácticas. Generalmente, se estructuran como una función que proporciona supervisión, auditoría y gobernanza de políticas en toda la organización, independientemente de cualquier equipo de desarrollo o proyecto individual.

DevOps es un enfoque de desarrollo de software que enfatiza la colaboración y la comunicación entre los equipos de desarrollo y operaciones. Su objetivo es optimizar el proceso de desarrollo mediante la automatización de tareas, las pruebas continuas del código y la integración de flujos de trabajo para lograr lanzamientos de software más rápidos y confiables. Los equipos de DevOps son directamente responsables del proceso de producción y entrega de software, lo que los convierte en los responsables lógicos de cualquier control de seguridad integrado en dicho proceso.

¿Dónde debería residir la seguridad: en InfoSec o en DevOps?

El ataque a SolarWinds plantea la cuestión de si la seguridad debe residir en InfoSec o en DevOps. Algunos argumentan que la seguridad debe ser responsabilidad de los equipos de InfoSec, mientras que otros defienden su integración en el proceso de DevOps. Ambos argumentos son válidos, y la realidad es que ninguno de los dos modelos por sí solo habría evitado el ataque a SolarWinds.

Argumentos a favor de InfoSec

• Centrarse en la gestión de riesgos

  Los equipos de seguridad de la información están capacitados para centrarse en la gestión de riesgos y la mitigación de amenazas. Poseen un profundo conocimiento de las vulnerabilidades y amenazas potenciales, y están preparados para desarrollar e implementar las políticas y los procedimientos que protegen contra dichas amenazas. En el caso de ataques a la cadena de suministro, los equipos de seguridad de la información aportan su experiencia en modelado de amenazas para reconocer que la integridad del proceso de compilación representa un problema de seguridad y para definir los controles necesarios para abordarlo.

• Independencia

  Los equipos de seguridad informática son independientes del proceso de desarrollo, lo que les permite ofrecer una perspectiva imparcial sobre los problemas de seguridad. No están sujetos a la presión de cumplir con los plazos de entrega y pueden priorizar las cuestiones de seguridad sin comprometer el proceso de desarrollo. Esta independencia resulta valiosa cuando los requisitos de seguridad entran en conflicto con la velocidad de entrega.

Argumentos a favor de DevOps

• Seguridad como código

  Los equipos de DevOps son responsables de la creación y el despliegue de código, por lo que están en la mejor posición para integrar la seguridad en el proceso de desarrollo. Al incorporar controles de seguridad en el pipeline de CI/CD como código, los equipos de DevOps pueden garantizar que la seguridad esté integrada en el software desde el principio, en lugar de añadirse posteriormente. La monitorización de la integridad del pipeline de compilación, SAST, SCA y el escaneo de secretos son prácticas que los equipos de DevOps implementan habitualmente.

• Tiempos de respuesta más rápidos

  Los equipos de DevOps implementan código de forma rápida y eficiente. Al integrar la seguridad en el proceso de desarrollo, pueden responder con mayor rapidez a los problemas y vulnerabilidades de seguridad. Cuando se publica una vulnerabilidad CVE en una dependencia, un equipo de DevOps con SCA en su canalización puede detectarla y solucionarla en cuestión de horas; el mismo proceso, a través de un panel de control de seguridad de la información independiente, puede tardar semanas.

Factores de decisión: Elección del modelo de propiedad de valores adecuado

• Cultura organizacional

  Dependiendo de si la organización prioriza la seguridad y el cumplimiento normativo o la innovación y la agilidad, la gestión de la seguridad de la información (InfoSec) o la de DevOps pueden ser más adecuadas como modelo principal. Las organizaciones con estrictos requisitos de cumplimiento en los sectores financiero y sanitario suelen mantener una función de InfoSec dedicada; las organizaciones con ciclos de lanzamiento rápidos en SaaS suelen integrar la seguridad en DevOps mediante la automatización.

• Metodología de desarrollo

  En una metodología de desarrollo en cascada, puede ser más apropiado contar con un equipo de seguridad de la información independiente que realice revisiones en cada etapa del proceso. Con las metodologías Agile o DevOps, integrar medidas de seguridad en el flujo de desarrollo mediante la automatización es más factible y eficaz que las revisiones periódicas en cada etapa.

• Cumplimiento normativo

  Si la organización debe cumplir con requisitos normativos estrictos como HIPAA, PCI DSS o DORA, generalmente se requiere una función de seguridad de la información independiente con políticas documentadas para cumplir con los requisitos de auditoría. Un modelo basado únicamente en DevOps puede carecer de la documentación formal y el registro de auditoría independiente que exigen los reguladores.

• Conjunto de habilidades y recursos

  Las organizaciones con un equipo de seguridad de la información amplio y experimentado se benefician al aprovechar esa experiencia para la gobernanza de políticas y la revisión de la arquitectura. Si el equipo de seguridad de la información es pequeño o si las necesidades de seguridad evolucionan rápidamente (como ocurre con los requisitos de seguridad de la cadena de suministro tras SolarWinds), integrar la seguridad en DevOps mediante la automatización puede ser más práctico que aumentar la plantilla de seguridad de la información para que coincida con las necesidades.

Controles de seguridad de la cadena de suministro que SolarWinds hizo obligatorios

El ataque a SolarWinds demostró los controles específicos que se necesitan para proteger el proceso de compilación de software, independientemente de si pertenecen a InfoSec, DevOps o a un modelo compartido:

• Monitoreo del aislamiento e integridad del entorno de compilación: El entorno de compilación debe estar aislado de las redes de uso general y ser monitoreado para detectar la ejecución no autorizada de procesos o la modificación de archivos que podrían indicar una vulneración del proceso de compilación.
• Firma de código con claves protegidas por HSM y doble autorización: Las claves privadas de firma de código deben almacenarse en HSM validados según FIPS 140-3 con controles de doble autorización que requieren múltiples aprobaciones antes de que se pueda usar una clave; esto limita la capacidad de un sistema de compilación comprometido para producir firmas confiables sin ser detectado. Ver CodeSign seguro para la implementación
• Generación de la lista de materiales de software (SBOM): Cada lanzamiento de software debe incluir una lista de materiales de software (SBOM) que documente todos los componentes y su procedencia, lo que permitirá la identificación rápida de componentes comprometidos después de una brecha en la cadena de suministro.
• Compilaciones reproducibles: Los procesos de compilación deben ser deterministas para que el resultado compilado pueda verificarse de forma independiente y coincidir con el código fuente firmado.
• Escaneo de secretos en CI/CD: Las credenciales, las claves API y el material de clave privada deben escanearse desde los repositorios y los entornos de compilación para evitar su exposición accidental a través de los artefactos de compilación.
• Cumplimiento del SSDF: El Marco de Desarrollo de Software Seguro del NIST, publicado en respuesta directa a SolarWinds, proporciona el marco de prácticas completo para abordar todos estos controles. Véase Marco de desarrollo de software seguro para garantizar la corrección del código

Registro de actualización

Fecha	Evento / Actualización
de diciembre de 2020.	Se ha descubierto una vulnerabilidad en la cadena de suministro de SolarWinds Orion; se ha identificado una puerta trasera SUNBURST en una actualización firmada distribuida a aproximadamente 18,000 clientes.
2021 de mayo	Se firmó la Orden Ejecutiva 14028, que ordena a las agencias federales mejorar la seguridad de la cadena de suministro de software y exige a los proveedores de software que certifiquen el cumplimiento de la SSDF.
2022 de febrero	El NIST publica la norma SP 800-218 (SSDF), el Marco de Desarrollo de Software Seguro, que aborda directamente la integridad del proceso de compilación y la procedencia de los componentes de software.
2023 de mayo	Publicación original en el blog que analiza la cuestión de la responsabilidad de la seguridad en InfoSec frente a DevOps en el contexto de SolarWinds.
Septiembre de 2026 (esta actualización)	Contenido actualizado con información técnica detallada sobre el mecanismo de ataque SUNBURST, controles de seguridad de la cadena de suministro, tabla de decisiones InfoSec vs. DevOps, contexto de SSDF, registro de actualizaciones y sección de preguntas frecuentes.

Conclusión

La cuestión de dónde debe residir la seguridad, en InfoSec o en DevOps, no es sencilla. Ambos enfoques tienen sus ventajas, y el mejor depende de la organización y su contexto específico. El ataque a SolarWinds demostró de forma concluyente que ni un modelo tradicional de control de InfoSec ni una canalización de DevOps sin integración de seguridad lo habrían evitado. InfoSec no supervisaba la canalización de compilación en tiempo real; DevOps no contaba con controles para detectar la inyección de código no autorizado antes de la firma. El modelo más eficaz integra ambos: los equipos de InfoSec son responsables de la política de seguridad, los estándares de arquitectura y la supervisión del cumplimiento; los equipos de DevOps implementan esos estándares mediante puertas de seguridad automatizadas en la canalización de CI/CD. Esto es DevSecOps, y es el modelo que proporciona tanto la profundidad de la experiencia en seguridad como la velocidad operativa necesarias para proteger las cadenas de suministro de software modernas. Para el marco del NIST que codifica directamente estas lecciones, consulte Marco de desarrollo de software seguro para garantizar la corrección del código . Para la firma de código y los controles de integridad de los artefactos de compilación, consulte CodeSign Secure.

Preguntas frecuentes

¿Qué fue el ciberataque a SolarWinds y cómo funcionó?

El ataque a SolarWinds, descubierto en diciembre de 2020, fue un ataque a la cadena de suministro en el que los atacantes comprometieron el sistema de compilación Orion de SolarWinds e insertaron una puerta trasera (SUNBURST) en el mecanismo de actualización. La puerta trasera se compiló normalmente y fue firmada por la propia infraestructura de firma de código de SolarWinds, lo que hizo que la actualización comprometida fuera indistinguible de una versión legítima. Se distribuyó a aproximadamente 18 000 clientes, incluidas importantes agencias gubernamentales de EE. UU., lo que otorgó a los atacantes acceso persistente a las redes de las víctimas.

¿Cuál es la diferencia entre InfoSec y DevOps como modelos para gestionar la seguridad?

Los equipos de InfoSec se especializan en políticas de seguridad, evaluación de riesgos, cumplimiento normativo y monitorización de la seguridad. Ofrecen un profundo conocimiento y autonomía respecto a la presión de la entrega, pero operan fuera del proceso de desarrollo donde se toman las decisiones sobre el código. Los equipos de DevOps gestionan el proceso de entrega de software y están en posición de integrar la automatización de la seguridad en él, pero suelen carecer de una amplia experiencia en seguridad. DevSecOps integra ambos enfoques: InfoSec define las políticas y la arquitectura, y DevOps las implementa mediante controles de seguridad automatizados en el proceso.

¿Qué medidas de seguridad específicas habrían reducido el riesgo en la cadena de suministro al estilo SolarWinds?

Los controles que abordan directamente el riesgo de la cadena de suministro al estilo SolarWinds incluyen: monitoreo de la integridad del entorno de compilación para detectar la inyección de código no autorizado antes de la firma; firma de código con claves protegidas por HSM y controles de doble autorización; generación de SBOM para el seguimiento de la procedencia de los componentes; compilaciones reproducibles para la verificación independiente; segmentación de red del entorno de compilación; y monitoreo del comportamiento de los artefactos de compilación. El NIST SSDF (SP 800-218) proporciona el marco de buenas prácticas que aborda todos estos controles.

¿Cómo cambió el ataque a SolarWinds las prácticas de seguridad en la cadena de suministro de software?

SolarWinds informó directamente sobre la Orden Ejecutiva 14028 (mayo de 2021), la norma NIST SP 800-218 SSDF (febrero de 2022) y la iniciativa Secure by Design de CISA. La Orden Ejecutiva 14028 exigía a los proveedores de software certificar el cumplimiento de SSDF para las contrataciones federales y establecía requisitos obligatorios para la lista de materiales de software (SBOM). Este ataque se ha convertido en el caso de referencia por excelencia para demostrar por qué la integridad del proceso de compilación, los controles de firma de código y la visibilidad de la cadena de suministro son elementos esenciales de los programas de seguridad empresarial.

¿Qué es el modelo DevSecOps y en qué se diferencia de los modelos de seguridad tradicionales de InfoSec o DevOps?

DevSecOps integra la seguridad en el flujo de trabajo de DevOps, en lugar de tratarla como una función de control independiente. El equipo de InfoSec se encarga de las políticas, la arquitectura, el modelado de amenazas y la supervisión del cumplimiento; los equipos de desarrollo se encargan de la implementación y la corrección; las pruebas de seguridad automatizadas (SAST, DAST, SCA, escaneo de secretos) funcionan como un control de calidad de CI/CD con retroalimentación inmediata. La seguridad se vuelve continua en lugar de episódica, y tanto el equipo de InfoSec como el de DevOps comparten responsabilidades de seguridad definidas.