Casi el 93% de las organizaciones descubren vulnerabilidades antes que los atacantes, pero muchas organizaciones siguen siendo vulnerables incluso después de la remediación, lo que marca el comienzo de una nueva era de «botware» y riesgos heredados no administrados.
Más del 60% de las infracciones empresariales ahora se deben a vulnerabilidades parcheables, lo que enfatiza las fallas de ejecución en lugar de la falta de información.
TuxCare 3ra edición anual Informe sobre el estado del código abierto 2026Un informe publicado el mes pasado confirma que este patrón persiste en los entornos empresariales, con pocos signos de mejora.
El informe también señala que el panorama del código abierto está madurando a medida que los equipos de TI se vuelven más cautelosos en la forma en que implementan, administran y escalan el software de código abierto.
Los recientes incidentes cibernéticos de alto impacto están remodelando la forma en que las organizaciones abordan el riesgo, la confianza, las pruebas y la respuesta, al tiempo que exponen brechas operativas persistentes. Al mismo tiempo, las empresas están reconsiderando cómo manejar el software al final de su vida útil (EOL), el uso prolongado y el mantenimiento a largo plazo en un entorno donde las actualizaciones no siempre son inmediatas o incluso posibles.
Artem Karasev, gerente senior de productos de TuxCare, dijo que el problema no es una falla de los sistemas de detección como las vulnerabilidades y exposiciones comunes (CVE), sino sus limitaciones cuando se usan solos.
«Los CVE siguen siendo útiles como señales, pero los CVE y los flujos de trabajo de alerta por sí solos no son suficientes para lograr la reducción de riesgos en entornos empresariales», dijo a LinuxInsider.
señal de evento en aumento
Durante el cuarto trimestre de 2025, los investigadores de TuxCare recopilaron datos de una población encuestada principalmente de carácter técnico. Los ingenieros de software representan el grupo más grande de participantes, seguidos por los directores técnicos, administradores de sistemas y profesionales de DevOps.
Entre los usuarios empresariales de código abierto que conocen el estado de los incidentes de su organización, el 47,8% informó haber experimentado un incidente de ciberseguridad en los últimos 12 meses. Los investigadores dicen que esta proporción casi uniforme sugiere que tales eventos no son ni raros ni comunes.
«Así que el verdadero problema no es que el modelo CVE esté muerto. Es que el modelo operativo de seguridad empresarial todavía está demasiado impulsado por tickets, ventanas de mantenimiento y controlado por humanos para mantenerse al día con la velocidad a la que se están perdiendo las vulnerabilidades modernas», dijo Karasev. «Te dicen lo que existe; no abordan el control de cambios, las pruebas de compatibilidad, la ambigüedad de propiedad, la tolerancia al riesgo de producción ni corrigen el rendimiento».
Los informes muestran que los incidentes cibernéticos son algo cotidiano para muchas organizaciones. Los encuestados indicaron que tales eventos ocurren con suficiente frecuencia como para ser considerados un riesgo operativo normal.
La gran mayoría (61,4%) de los incidentes reportados estuvieron relacionados con parches no aplicados pero disponibles, un ligero aumento con respecto al 60,4% del año pasado. El estrecho desacuerdo sugiere que el problema persiste en lugar de mejorar o empeorar significativamente, según el informe.
La falta de cambios materiales con respecto al año pasado sugiere que las organizaciones continúan enfrentando limitaciones similares en cuanto al tiempo, la implementación y la priorización de parches.
Siguen existiendo lagunas de reparación
Los informes muestran que el 92,6% de las organizaciones sabían que eran vulnerables antes de que ocurriera un incidente de seguridad. La mayoría de los incidentes relacionados con vulnerabilidades conocidas se originan en sistemas sin parches, lo que sugiere fricciones operativas más que falta de información.
La complejidad de la dependencia también afecta la actualización del software y la confiabilidad al final de su vida útil. El informe afirma que la mayoría de las pilas de producción (37,7%) tienen entre 25 y 99 dependencias directas, pero la confianza en la seguridad de las dependencias transitivas profundas sigue siendo baja, y solo el 22,4% de los equipos se sienten muy seguros.
Las organizaciones se están alejando de la práctica de «contratar su salida» de la deuda garantizada. En cambio, se centran en la automatización y la disciplina de procesos para cerrar la brecha entre el descubrimiento y la corrección de vulnerabilidades.
Karasev dijo que la principal fricción operativa citada por los encuestados fueron las restricciones de corte, citadas por el 43,0% de los encuestados. Después de eso, el error humano representó el 31,6% y la falta de recursos para mantenerse al día con la cantidad de vulnerabilidades/parches representó el 29,1%.
«A medida que la pila se vuelve más distribuida, la identificación oportuna de los parches aplicables se ha convertido en un importante cuello de botella arquitectónico», añadió.
Migrar a OSS administrado
El informe muestra que Linux se está volviendo cada vez menos visible a medida que los usuarios lo implementan a través de Plataforma como Servicio (PaaS) y contenedores. Karasev señaló que a medida que OSS pasó a este modelo de consumo indirecto, las responsabilidades cambiaron pero no desaparecieron.
«El proveedor asume una mayor parte del sistema operativo subyacente, los parches de la plataforma y la gestión del ciclo de vida, pero la empresa aún es propietaria de lo que implementa, cómo lo configura, en qué imágenes y tiempos de ejecución confía, y con qué rapidez absorbe las actualizaciones, desusos y componentes obsoletos impulsados por el proveedor», explicó.
Él cree que los principales riesgos están cambiando. En lugar de que las organizaciones ejecuten Linux directamente y apliquen parches ellas mismas, dependen de las opciones de otros en cuanto a imágenes base, parches, cadencia de actualización, políticas de desaprobación y transparencia.
«Esta es la nueva dependencia. Los datos muestran que es posible que muchas organizaciones no se den cuenta de esto porque Linux se usa cada vez más de manera indirecta, y el uso de Linux como Linux no es tan obvio en absoluto», dijo Karasev.
Está de acuerdo en que esto representa un cambio permanente, ya que gran parte de los entornos empresariales se ejecutan en software «zombi» al final de su vida útil.
CentOS y la realidad del ciclo de vida
La continua resistencia de los sistemas Linux heredados también oscurece estos problemas. Consideremos la situación en toda la industria con las distribuciones CentOS Linux, que se han convertido en distribuciones “zombies” o fantasmas.
Karasev se negó a calificarlo como un colapso del software de código abierto. Más bien, el análisis de TuxCare sugiere que se trata de una corrección del mercado tras un cambio importante en el ciclo de vida.
«Lo que está sucediendo es que muchas organizaciones se ven obligadas a tomar decisiones explícitas sobre el soporte, la migración y el mantenimiento a largo plazo de sistemas que antes operaban basándose en suposiciones implícitas», respondió.
Los proyectos Red Hat y CentOS acabaron efectivamente con CentOS, moviendo el sistema operativo de un clon estable a una rama de desarrollo ascendente. Karasev dijo que los datos muestran una división casi completa entre los usuarios que migran desde CentOS y los que compran soporte extendido.
«Probablemente habrá un segmento de extensión de EOL persistente en el sector inmobiliario empresarial. La delimitación casi perfecta entre migración o migración planificada y compra o compra planificada de soporte ampliado sugiere que para muchos equipos, EOL no es un límite claro sino un estado administrado», dijo Karasev.
Transición de CentOS explicada
Según el informe de 2026 y el contexto histórico, aquí hay un desglose de lo que sucedió:
CentOS ha sido una reconstrucción posterior de Red Hat Enterprise Linux (RHEL) durante casi 20 años. Esto significa que es una versión de RHEL gratuita y tolerante a errores, ideal para entornos de producción que requieren estabilidad sin el costo de una suscripción a RHEL.
En diciembre de 2020, Red Hat anunció un cambio importante que debilitó la viabilidad de sus negocios apoyados por la comunidad. Este proyecto ya no producirá clones estables de RHEL. En cambio, nació CentOS Stream. Su enfoque se desplazó desde RHEL. No es una copia de la versión actual de RHEL, sino una vista previa de versiones futuras de RHEL. Esto lo hace menos que ideal para algunos entornos de producción estables.
«El cambio de CentOS expone cuán dependientes son las empresas de la estabilidad de la capa del sistema operativo y acelera una conversación más madura sobre la propiedad del ciclo de vida», dijo Karasev.
¿Qué sigue para el OSS?
Karasev dijo que la historia de supervivencia de CentOS, impulsada por limitaciones pragmáticas, tiene implicaciones de seguridad a largo plazo para la cadena de suministro de software global. El impacto a largo plazo es un cambio hacia un modelo de soporte más diverso en torno al código abierto.
«Esto significa que los activos globales de OSS pueden incluir dependencias heredadas, sistemas fijos de compatibilidad y bases persistentes que difieren la modernización. La verdadera línea divisoria es si este uso se gestiona y parchea, o se permite que decaiga», predice.
Pero advierte que eso no significa que todo uso prolongado del sistema sea imprudente. Existen diferencias importantes entre los sistemas obsoletos y no compatibles, y los sistemas que no cuentan con el soporte de los proveedores convencionales pero que aún cuentan con el soporte de extensiones confiables.
«Las distribuciones comunitarias, los proveedores comerciales y los proveedores de ELS tienen un papel que desempeñar. La lección para el ecosistema es que la previsibilidad del ciclo de vida es tan importante como la calidad técnica, especialmente para la infraestructura», concluyó Karasev.
