Estimado CNA del kernel de Linux, ¿qué has hecho?
Rol y significado de los CVE
- Varios comentarios subrayan que los CVE se concibieron principalmente como identificadores únicos para que la gente hablara del mismo problema, no como una lista completa o autoritativa de errores de seguridad “reales”.
- Otros responden que, en la práctica, los reguladores, las empresas y las herramientas han llegado a tratar “tener un CVE” como sinónimo de “vulnerabilidad de seguridad conocida”, independientemente de que ese fuera o no el diseño original.
- Este desajuste entre el uso previsto y el uso en el mundo real se considera la tensión central.
Enfoque del kernel de Linux de “todo bug es un bug de seguridad”
- La postura mantenida desde hace tiempo por la comunidad del kernel: a menudo es imposible separar de forma fiable los errores “de seguridad” de los “no de seguridad”, así que hay que asumir que todos los bugs pueden ser relevantes para la seguridad.
- Convertirse en un CNA y emitir CVE para prácticamente todas las correcciones de errores es visto por algunos como una extensión lógica de esa postura; por otros, como una maniobra deliberada para “quemar el sistema” y poner de manifiesto fallos del proceso de CVE.
Regulación, cumplimiento y carga para los de downstream
- Muchos temen que una avalancha de CVE del kernel provoque dolor de cumplimiento: más triaje, más ciclos de parcheo obligatorios y posibles riesgos de seguridad o estabilidad en sistemas regulados o de larga vida útil.
- Algunos sostienen que las normas (PCI-DSS, ISO, SOC2, CRA) exigen sobre todo procesos para descubrir y gestionar vulnerabilidades explotables, no aplicar ciegamente parches a todos los CVE. Un comentarista afirma que CRA excluye explícitamente el OSS upstream y se centra en la explotabilidad.
- Una idea recurrente: las grandes empresas que se benefician de Linux deberían financiar su propio triaje en lugar de esperar que los desarrolladores del kernel, sin remuneración, clasifiquen los bugs por ellas.
Resultados de seguridad y perspectiva del atacante
- Quienes lo apoyan creen que más CVE mejoran la transparencia y empujan a los rezagados hacia actualizaciones continuas, que es la única forma realista de mantener seguros los kernels.
- Quienes lo critican afirman que los CVE vagos, sin puntuación y publicados a posteriori —además de la ausencia de CVE para bugs no corregidos— pueden prolongar la vida útil de los exploits y complicar la defensa, especialmente en sistemas heredados que no pueden actualizarse por completo.
Problemas de calidad, puntuación y herramientas
- Muchos ven la puntuación CVSS como subjetiva, manipulable y a menudo engañosa, aunque reconocen que las herramientas y la regulación se han construido en torno a CVE+CVSS.
- Preocupa que los muchos CVE de Linux, descritos de forma mínima y sin puntuación, rompan o devalúen la automatización existente y los procesos de “seguridad de lista de verificación”.
Respuestas y mitigaciones propuestas
- Entre las sugerencias están:
- Tratar los CVE solo como entradas para el triaje, no como requisitos rígidos.
- Pagar a los proveedores para que entreguen “feeds limpios” curados y actualizaciones probadas.
- Reducir la exposición deshabilitando componentes del kernel que no se usen y automatizando la integración de versiones menores.
- Algunos sostienen que las organizaciones que hacen un cumplimiento ingenuo CVE por CVE “solo tienen a ellas mismas a quien culpar” y deben evolucionar sus procesos.