En una época en la que las organizaciones se enfrentan a dificultades con entornos digitales complejos, la gestión de la superficie de ataque (ASM) se está convirtiendo en un componente clave de las estrategias modernas de ciberseguridad. En esencia, la ASM es la actividad continua de descubrir, registrar, clasificar y supervisar todos los activos digitales que pueden ser objeto de abuso por parte de los actores maliciosos. Estos pueden ser aplicaciones web de acceso público, redes internas, recursos de nube pública y, lo que es más importante, componentes de código abierto integrados o compilados en la pila tecnológica de la organización.
Cuando las empresas recurren a bibliotecas, marcos y herramientas de código abierto para acelerar el desarrollo y reducir los gastos, también deben hacer frente a los riesgos de seguridad asociados a esas dependencias. La gestión de la superficie de ataque de código abierto es una preocupación más importante que nunca tras el antiguo incidente de SolarWinds y el más reciente de Log4j, en los que se encontraron vulnerabilidades en un componente de código abierto, lo que provocó un ataque generalizado a varias empresas.
¿Qué es la gestión de la superficie de ataque de código abierto?
La gestión de la superficie de ataque de código abierto se refiere a la práctica de identificar, supervisar y mitigar los riesgos debidos a los componentes de código abierto dentro de la infraestructura tecnológica de cualquier organización.
Mientras que la ASM tradicional se centra en el perímetro y los activos visibles desde el exterior, la ASM de código abierto profundiza en la cadena de suministro de software y examina las bibliotecas, los marcos y los paquetes que constituyen los componentes básicos de las aplicaciones modernas. Esta constatación reconoce que las vulnerabilidades no son exclusivas del código propio de una organización, sino que son inherentes a todo el extenso ecosistema de dependencias de código abierto de terceros del que dependen las aplicaciones.
El ASM tradicional se centra normalmente en descubrir y supervisar los puntos finales de la red, los dominios, las direcciones IP y otros activos expuestos externamente. El ASM de código abierto amplía esta visión hacia el interior, analizando la composición de las propias aplicaciones. Implica crear y actualizar una lista completa de materiales de software (SBOM), recopilar información sobre las versiones y las vulnerabilidades conocidas en las dependencias, así como comprender la red de relaciones entre los componentes de software.
¿Por qué es importante el ASM de código abierto?
El software de código abierto es la columna vertebral de las pilas tecnológicas empresariales modernas. Según algunas estimaciones, más del 90 % de las aplicaciones comerciales contienen componentes de código abierto, y la aplicación media contiene cientos de bibliotecas de código abierto. Esta adopción masiva ha generado eficiencias y ha impulsado la innovación, pero también ha ampliado significativamente la superficie de ataque que las organizaciones deben proteger.
La superficie de ataque en expansión
Las dependencias de código abierto tienen graves implicaciones en términos de seguridad. La vulnerabilidad identificada como Log4j (CVE-2021-44228) sirvió de llamada de atención para muchas organizaciones, ya que afectó a millones de dispositivos y provocó una campaña masiva de aplicación de parches a nivel mundial. De manera correlativa, incidentes como el compromiso del paquete npm event-stream muestran cómo los actores con intenciones maliciosas pueden utilizar la popularidad de las bibliotecas de código abierto como vector para ataques a la cadena de suministro contra los usuarios finales.
El reto de la visibilidad
La mayoría de las organizaciones no tienen una amplia visibilidad del impacto del código abierto. A menudo, los equipos de desarrollo introducen nuevas dependencias sin revisar la seguridad, lo que conduce a la creación de las llamadas "dependencias ocultas" sin que el equipo de seguridad sea consciente de ello. Esta escasa visibilidad da lugar a que las vulnerabilidades no se aborden mucho tiempo después de que se hayan publicado las correcciones, lo que expone a las organizaciones a ataques fácilmente evitables.
Presiones normativas y de cumplimiento
Los marcos normativos exigen a las organizaciones que mantengan cada vez más inventarios precisos de los componentes de software y que corrijan rápidamente las vulnerabilidades conocidas. Desde el RGPD hasta normativas específicas de cada sector, como la PCI DSS, el cumplimiento normativo requiere prácticas de gestión de código abierto saludables que se ajusten perfectamente a los principios de la gestión de la superficie de ataque de código abierto (ASM).
Componentes clave de la gestión de la superficie de ataque del código abierto
Se requiere un enfoque estructurado para una ASM de código abierto eficaz que utilice tecnología y procesos y los infunda en la organización. Los componentes clave permiten a las organizaciones trabajar de forma inteligente para descubrir, priorizar y remediar los riesgos derivados de las dependencias de código abierto.
Inventario de software
La gestión de la superficie de ataque de código abierto comienza con una lista potencialmente completa y precisa de todos los activos de software. Esto implica mantener listas detalladas de materiales de software (SBOM), que detallan cada componente de código abierto empleado, su versión, información de licencia y procedencia. Los formatos estandarizados, como CycloneDX y SPDX, permiten a los desarrolladores describir estas dependencias de forma independiente, lo que las hace más visibles, más fáciles de analizar y más fáciles de compartir con otras partes.
Supervisión continua de vulnerabilidades
Escanear regularmente las bases de código y compararlas con bases de datos de vulnerabilidades como la Base de Datos Nacional de Vulnerabilidades (NVD), los Avisos de Seguridad de GitHub y las fuentes de vulnerabilidades específicas de cada lenguaje. La supervisión de las CVE es insuficiente, ya que debe correlacionar las vulnerabilidades con el uso real que hace una organización de los sistemas para determinar qué es realmente explotable.
Marco de priorización basado en el riesgo
Conscientes de que no todas las vulnerabilidades son iguales, es necesario priorizarlas para asignar los recursos de forma eficaz. La priorización debe basarse en muchos aspectos, como el grado de vulnerabilidad (puntuaciones CVSS), la explotabilidad en el entorno, la accesibilidad del componente vulnerable, el impacto general en el negocio o las medidas de mitigación disponibles.
Integración perfecta con los procesos de desarrollo
La integración de ASM de código abierto en el proceso de CI/CD transforma ASM de una actividad manual periódica a un proceso automatizado y continuo. La comprobación de dependencias vulnerables con ganchos previos al compromiso, los análisis durante el tiempo de compilación automatizada y el análisis de imágenes de contenedores evitan que las dependencias defectuosas lleguen a la producción.
Estrategias de corrección y mitigación
Los flujos de trabajo de corrección claramente definidos también forman parte de un ecosistema para tratar las vulnerabilidades detectadas. Las estrategias de corrección consistirían en actualizar a versiones parcheadas, aplicar soluciones de parcheo virtual (WAF o RASP), utilizar componentes alternativos o aplicar controles compensatorios cuando no se dispone de un parche.
Amenazas comunes abordadas por ASM de código abierto
La gestión de la superficie de ataque de código abierto evalúa las amenazas en una amplia gama de vulnerabilidades de seguridad que se dirigen o aprovechan los componentes de código abierto. Al comprender estas amenazas, las organizaciones estarán en mejores condiciones de implementar contramedidas.
Explotación de vulnerabilidades conocidas
Como vía de menor resistencia para acceder a sistemas que, por lo demás, están bien protegidos, los atacantes suelen aprovechar las vulnerabilidades conocidas de los componentes de código abierto más populares. El riesgo continuo se puso de manifiesto en la violación de Equifax en 2017, en la que los atacantes aprovecharon una vulnerabilidad conocida pero sin parchear en Apache Struts que llevaba meses parcheada, pero que no se había implementado en los sistemas de Equifax. El mismo patrón se repite en todos los sectores, ya que las vulnerabilidades comunes de código abierto, como Log4j, Spring4Shell y OpenSSL, se convierten en objetivos principales para los atacantes debido a su escala de implementación.
Compromisos de la cadena de suministro
La cadena de suministro de software es uno de los principales objetivos de los atacantes sofisticados, ya que pueden afectar a múltiples víctimas con un solo vector de ataque. Los incidentes de SolarWinds demostraron el daño que pueden causar estos ataques, mientras que incidentes menores, como la manipulación del paquete npm event-stream, demostraron que los atacantes están empezando a centrarse en los paquetes de código abierto utilizados por sus víctimas. Otros tipos de ataques de este tipo se basan en la inyección de código en paquetes o repositorios legítimos, el compromiso de servidores de compilación o el secuestro de cuentas de desarrolladores.
Ataques de confusión de dependencias
La confusión de dependencias es un tipo de ataque a la cadena de suministro que aprovecha el comportamiento de los gestores de paquetes cuando se encuentran con colisiones de nombres entre repositorios públicos y privados. Los atacantes pueden registrar paquetes públicos con nombres idénticos a los paquetes internos de una organización, y los sistemas de compilación extraerán automáticamente la versión pública, que es la versión maliciosa. Este vector de ataque comenzó a llamar la atención en 2021, cuando el investigador Alex Birsan demostró su eficacia contra múltiples organizaciones de gran volumen.
Riesgos de los paquetes abandonados
A medida que crecen los proyectos de código abierto, algunos paquetes dejan de ser mantenidos o quedan obsoletos por parte de sus desarrolladores originales. Estas dependencias "muertas" suponen un gran riesgo para la seguridad, ya que dejan de recibir actualizaciones de seguridad o correcciones de errores, por lo que cualquier vulnerabilidad recién descubierta deja a las organizaciones expuestas a ataques. En algunos casos, los delincuentes se han apoderado de paquetes abandonados para inyectar malware.
Infracciones del cumplimiento de licencias
Los problemas de cumplimiento de licencias no son exactamente amenazas para la seguridad, pero pueden representar importantes amenazas legales y financieras para los usuarios de software de código abierto. Algunas licencias incluyen requisitos que pueden contradecir el modelo de beneficios o la estrategia de propiedad intelectual de una organización. Desgraciadamente, la inclusión involuntaria de código empaquetado bajo una licencia incompatible puede exponer a una empresa a reclamaciones por infracción de derechos de autor, a la divulgación obligatoria del código en su cadena de software de producción y a costosas medidas correctivas.
Retos del ASM de código abierto
El ASM de código abierto plantea muchos retos a las organizaciones que lo implementan. Con la aceleración continua del uso de componentes de código abierto, los equipos de seguridad deben encontrar una forma de abordar estos retos para proteger a su organización de vulnerabilidades que pueden dar lugar a violaciones de datos y una interrupción de los servicios que puede provocar pérdidas económicas o multas reglamentarias.
Complejidad de las dependencias
Las aplicaciones modernas tienen estructuras de dependencia profundamente anidadas, en las que una sola aplicación puede depender de cientos o miles de dependencias directas y transitivas. Esto crea un "conjunto de dependencias" en el que los equipos de seguridad ya no pueden saber de qué está compuesto su software. Estas capas crean una compleja red de relaciones, y resulta muy difícil comprender con precisión las implicaciones de las vulnerabilidades en toda una organización; una vulnerabilidad crítica en una dependencia hiper-técnica de tercer o cuarto nivel podría propagarse por muchos sistemas de la organización.
Visibilidad general limitada
La mayoría de las organizaciones no disponen de una lista completa de materiales de software (SBOM), por lo que no es posible identificar todos los componentes de código abierto que se utilizan en su entorno. La falta de visibilidad no hace más que aumentar debido a las prácticas de desarrollo descentralizadas, shadow IT y la tendencia de DevOps a aumentar el ritmo de implementación de software. Los componentes se pueden añadir desde diversas fuentes, gestores de paquetes, imágenes de contenedores, copiados desde una página web o software proporcionado por proveedores, lo que da lugar a puntos ciegos en la supervisión de la seguridad.
Falta de recursos y limitaciones técnicas
La implementación de un ASM de código abierto eficaz requiere herramientas especializadas y personal cualificado, ambos escasos. Muchas organizaciones carecen de recursos dedicados a la gestión de la seguridad de código abierto y, en su lugar, distribuyen la responsabilidad entre equipos de desarrollo y seguridad que ya están sobrecargados. Los retos técnicos que plantean el análisis de aplicaciones en contenedores, las funciones sin servidor y el código compilado dinámicamente complican aún más las tareas de detección.
Integración con los flujos de trabajo de desarrollo
La adaptación de las prácticas de seguridad a los flujos de trabajo de desarrollo establecidos crea fricciones que pueden impedir la adopción de ASM de código abierto. Los desarrolladores centrados en la entrega de funciones pueden resistirse a las barreras de seguridad adicionales que ralentizan sus ciclos de lanzamiento o requieren una reelaboración de las implementaciones existentes. Las herramientas de seguridad tradicionales suelen generar grandes volúmenes de hallazgos sin contexto, lo que provoca fatiga por alertas y disminuye la eficacia.
Las mejores herramientas de código abierto para la gestión de la superficie de ataque
La gestión de la superficie de ataque de código abierto se sustenta en una gran cantidad de herramientas que ayudan a las organizaciones a descubrir, supervisar y abordar las vulnerabilidades de sus componentes de código abierto.
CrowdStrike Falcon
CrowdStrike Falcon va más allá de sus capacidades básicas de protección de endpoints para ofrecer funciones robustas para gestionar los riesgos de seguridad de código abierto. El módulo de seguridad de aplicaciones de la plataforma proporciona un escaneo continuo de los entornos de desarrollo para identificar componentes de código abierto vulnerables en una fase temprana del ciclo de vida del desarrollo.
RiskIQ
RiskIQ, que ahora forma parte de Microsoft, ofrece potentes capacidades de detección de superficies de ataque que ayudan a las organizaciones a identificar sus activos externos, incluidos aquellos que dependen de componentes de código abierto vulnerables. El gráfico de inteligencia de Internet de la plataforma mapea la infraestructura expuesta a Internet de una organización, detectando sistemas obsoletos, servicios mal configurados y aplicaciones que ejecutan componentes vulnerables conocidos. RiskIQ destaca en la detección de TI en la sombra y activos olvidados que a menudo escapan a los inventarios internos, pero que siguen siendo accesibles para los atacantes.
Palo Alto Xpanse
Xpanse proporciona una gestión integral de la superficie de ataque externa con capacidades especializadas para la detección de vulnerabilidades de código abierto. La plataforma supervisa continuamente los activos expuestos a Internet para identificar los sistemas que ejecutan software de código abierto vulnerable, desde servidores web y aplicaciones hasta servicios de red y dispositivos IoT. La fortaleza de Xpanse radica en su capacidad para descubrir activos desconocidos u olvidados en proveedores de nube, filiales y empresas recientemente adquiridas, lugares donde a menudo se ocultan componentes de código abierto vulnerables.
Nuclei Cloud
Nuclei Cloud aprovecha el popular escáner de vulnerabilidades de código abierto Nuclei para proporcionar una supervisión continua de la superficie de ataque externa de una organización en busca de componentes de código abierto vulnerables. La plataforma utiliza un escaneo basado en plantillas para detectar patrones de vulnerabilidad específicos en aplicaciones web, API y componentes de infraestructura. Lo que hace que Nuclei sea especialmente valioso para el ASM de código abierto es su amplia biblioteca de plantillas, que incluye comprobaciones de vulnerabilidades comunes de código abierto, y su enfoque impulsado por la comunidad, que garantiza una rápida cobertura de los problemas recién descubiertos.
Prácticas recomendadas para el ASM de código abierto
Las mejores prácticas que se enumeran a continuación ayudarán a las organizaciones a crear un programa ASM de código abierto sólido que equilibre la reducción de riesgos con la innovación.
Clasificar en función del riesgo
Vaya más allá de las puntuaciones CVSS brutas creando un enfoque estándar para la priorización de vulnerabilidades. Tenga en cuenta aspectos como: ¿Se utiliza realmente la funcionalidad vulnerable? ¿El componente es directamente accesible para usuarios externos? ¿Los datos procesados por el componente son confidenciales? ¿Existen controles compensatorios? Cree documentación para este marco y aplique una aplicación similar en todos los equipos. La buena noticia es que las herramientas automatizadas pueden enriquecer automáticamente los datos de vulnerabilidad con información de riesgo específica del contexto.
Incorpore la seguridad en los procesos de desarrollo
Integre ASM de código abierto en las herramientas y prácticas actuales de los desarrolladores para que la seguridad sea una extensión natural del proceso de desarrollo. Puede hacerlo de varias maneras, por ejemplo, creando complementos IDE que informen a los desarrolladores sobre los componentes vulnerables mientras escriben el código. Utilice sistemas de compilación para comprobar automáticamente las dependencias antes de empaquetar las aplicaciones. Formule directrices de corrección concisas que permitan a los desarrolladores solucionarlas rápidamente sin necesidad de ser especialistas en seguridad.
Políticas y normas de gobernanza
Establezca políticas formales de uso de código abierto que asignen tolerancias de riesgo a licencias aceptables y requisitos mínimos de mantenimiento para las dependencias. Aplique estas políticas para automatizar las comprobaciones en el proceso de CI/CD mediante controles técnicos. Forme un comité de gobernanza que incluya a representantes de seguridad, legales y de desarrollo, y que gestione las excepciones y la evolución de las políticas. Estos marcos de gobernanza permiten un enfoque común de gestión de riesgos en toda la organización, al tiempo que otorgan flexibilidad a las aplicaciones críticas para el negocio a través de un proceso de excepciones bien documentado.
Invertir en la automatización de la corrección de vulnerabilidades
Minimice la participación humana en el proceso de corrección para agilizar la respuesta a las debilidades detectadas. Cuando sea posible, las herramientas pueden crear solicitudes de extracción que actualicen de forma reactiva las dependencias vulnerables con alternativas seguras. Disponga de plantillas para patrones de corrección comunes que permitan a los desarrolladores encontrar la solución más rápida para diferentes tipos de vulnerabilidades. Implemente pruebas automatizadas para garantizar que los nuevos cambios no afecten a las funciones existentes.
Realice un seguimiento de la cadena de suministro de dependencias
Adopte una visión más amplia para evaluar la postura de seguridad de su cadena de suministro de código abierto. Evalúe sus dependencias por paquete en función de la actividad del mantenedor, la calidad del código, la seguridad del código y el apoyo de la comunidad. Manténgase alerta ante cualquier actividad extraña en los repositorios de dependencias, como la incorporación de nuevos mantenedores, patrones de confirmación inusuales o cambios inesperados en los permisos que podrían revelar un compromiso. Descargue los paquetes de forma segura, verificando su integridad mediante sumas de comprobación o firmas.
Conclusión
La gestión de la superficie de ataque del código abierto es un avance significativo en la adopción de prácticas de seguridad por parte de las organizaciones modernas. Dado que las empresas dependen cada vez más de los componentes de código abierto para acelerar la innovación y reducir los tiempos de desarrollo, también deben hacer frente a los retos de seguridad únicos que plantean esas dependencias. Una gestión adecuada de la superficie de ataque del código abierto, con capacidades de visibilidad, supervisión y corrección, permite equilibrar la velocidad de desarrollo con la necesidad de gestionar estos riesgos.
La saga de amenazas de la gestión de la superficie de ataque de código abierto, desde la explotación de vulnerabilidades conocidas hasta los ataques a la cadena de suministro, ilustra por qué esta disciplina se ha convertido en algo imprescindible para garantizar programas de seguridad maduros. Sin embargo, las organizaciones que adoptan prácticas sólidas de gestión de la superficie de ataque de código abierto reducen drásticamente su superficie de ataque y el tiempo de exposición a nuevas vulnerabilidades, y crean más oportunidades para la resiliencia frente a nuevas amenazas.
"Preguntas frecuentes sobre la gestión de la superficie de ataque de código abierto (ASM)
La gestión de la superficie de ataque de código abierto (ASM) es una disciplina de seguridad especializada centrada en identificar, supervisar y mitigar los riesgos asociados a los componentes de código abierto dentro del ecosistema de software de una organización. Amplía el ASM tradicional al profundizar en la composición de las aplicaciones para examinar las bibliotecas, los marcos y los paquetes que forman los componentes básicos de las aplicaciones modernas, creando visibilidad sobre las dependencias que podrían introducir vulnerabilidades o problemas de cumplimiento.
El uso de herramientas de código abierto para la gestión de la superficie de ataque ofrece varias ventajas: rentabilidad en comparación con las soluciones comerciales, flexibilidad para personalizar las herramientas según las necesidades específicas de la organización, acceso a innovaciones impulsadas por la comunidad que a menudo responden rápidamente a las amenazas emergentes, transparencia que permite a los equipos de seguridad verificar cómo funcionan las herramientas y compatibilidad con las prácticas de DevOps a través de integraciones impulsadas por API.
Las soluciones ASM de código abierto y comerciales tienen ventajas distintas. Las herramientas de código abierto suelen ofrecer una mayor personalización, soporte de la comunidad y ahorro de costes, pero pueden requerir más conocimientos técnicos para su implementación y mantenimiento. Las soluciones comerciales como SentinelOne proporcionan plataformas integradas con soporte profesional, automatización más sofisticada y escalabilidad de nivel empresarial, y a menudo incluyen capacidades adicionales como protección en tiempo de ejecución.
Entre las herramientas populares para la gestión de la superficie de ataque se incluyen CrowdStrike Falcon, Cycode ASPM, RiskIQ, Palo Alto Xpanse y Nuclei Cloud. Cada una de ellas ofrece capacidades especializadas para detectar componentes de código abierto vulnerables, desde la protección en tiempo de ejecución hasta la detección de superficies de ataque externas y la supervisión continua.