Prácticas recomendadas para el control de versiones de software

Cinco recomendaciones para los proveedores de software sobre nombres de productos, identificadores de versión, datos del ciclo de vida y avisos de vulnerabilidad

En pocas palabras Solicitar demostración Iniciar prueba gratuita

Por qué son importantes los identificadores de versión

Un identificador de versión es mucho más que una etiqueta en una página de descarga. Es la clave que vincula un producto instalado con su fecha de lanzamiento, su periodo de soporte y sus vulnerabilidades conocidas. Si esta clave es ambigua, todos los procesos que dependen de ella pierden fiabilidad: los escáneres de vulnerabilidades detectan falsos positivos o, lo que es peor, pasan por alto vulnerabilidades reales; las advertencias end-of-life llegan demasiado tarde y las decisiones sobre la aplicación de parches se basan en conjeturas.

Un producto, cinco identidades: la versión 1.97.56 de Brave aparece con diferentes nombres de producto y versiones en las notas de la versión, en Windows, en macOS, en el paquete de Linux y en el diccionario CPE de la NVD.

Versio.io mantiene una base de datos de end-of-life y versiones de miles de productos y la compara a diario con las versiones de software detectadas en los entornos de los clientes. Al hacerlo, nos encontramos habitualmente con productos y versiones que no se pueden asignar de forma inequívoca: varias formas de escribir el mismo nombre de producto, identificadores de versión que difieren entre la página web, el instalador y el gestor de paquetes, historiales de versiones sin fechas y avisos de vulnerabilidad que solo indican «versiones anteriores».

Prueba rápida: ¿hasta qué punto es reconocible tu producto?

Marca las opciones que ya se aplican a tu producto. A continuación se explica cada punto con detalle; la flecha te lleva directamente a la recomendación correspondiente.

Tanto el producto como el proveedor tienen exactamente un nombre, que se utiliza de forma coherente en todo momento.↓El esquema de versiones sigue el sistema de versionado semántico (Semantic Versioning) o está documentado y se aplica de forma coherente.↓Cada versión se publica en línea con su identificador de versión exacto y su fecha de lanzamiento (ISO 8601).↓El historial de versiones también está disponible en un formato legible por máquina (JSON, XML o API), junto con otros metadatos importantes.↓El nombre del producto, el nombre del proveedor y la versión se pueden consultar a través del gestor de paquetes del sistema operativo o de la línea de comandos, y coinciden exactamente con los nombres y la versión publicados.↓Los avisos de vulnerabilidad enumeran con exactitud todas las versiones afectadas y las versiones corregidas, sin indicar rangos de versiones.↓

Las siguientes recomendaciones están dirigidas a los proveedores de software. Son deliberadamente sencillas, su aplicación supone un coste mínimo y ayudan a todos aquellos que utilizan o supervisan sus productos:

Clientes y operadores - pueden comprobar de un vistazo si su instalación está actualizada, sigue recibiendo soporte técnico y se ve afectada por alguna vulnerabilidad.
Escáneres de vulnerabilidades - puede asociar con precisión los CVE a las versiones instaladas sin falsos positivos ni falsos negativos.
Seguimiento al end-of-life - puede avisar con la debida antelación de que el soporte está a punto de caducar.
CMDB y gestión de activos - puede documentar las versiones de forma coherente y a prueba de auditorías.
Los propios proveedores - recibir menos solicitudes de asistencia y cumplir los requisitos de normativas como la Ley de Resiliencia Cibernética (CRA), por ejemplo, en lo que respecta a las listas de componentes de software (SBOM), los periodos de asistencia y la gestión de vulnerabilidades.

1. Definir nombres únicos para los productos y los proveedores

Antes de poder asignar una versión, debe quedar claro a qué producto pertenece. Por lo tanto, los proveedores deben definir exactamente un nombre de producto y exactamente un nombre de proveedor, y utilizarlos de forma coherente en todas partes: en la página web, en el instalador, en los metadatos del paquete, en el historial de versiones y en los avisos de vulnerabilidad.

Si un mismo producto aparece como «Brave», «Brave-Browser» y «Brave Browser», cada herramienta debe determinar si se trata de uno, dos o tres productos distintos. Lo mismo ocurre con los nombres de proveedores como «Example», «Example Ltd» y «Example Software Ltd». Cada variante genera una entrada adicional en los inventarios, las listas de componentes de software (SBOM) y las bases de datos de vulnerabilidades, lo que puede dar lugar a una posible discrepancia a la hora de cotejar versiones y CVE.

✅ - Define un nombre canónico del producto y un nombre canónico del proveedor, incluyendo la ortografía, los espacios, los guiones y las mayúsculas.
✅ - Utiliza nombres de producto diferentes solo para productos que sean realmente distintos, por ejemplo, un servidor y su cliente.
✅ - Si se cambia el nombre de un producto o proveedor, anota el nombre anterior y la fecha del cambio en el historial de versiones.
❌ - Variantes con el mismo nombre en función de la plataforma, el instalador o la página de descarga.

2. Seguir las normas de versionado semántico

Las versiones de los productos deben seguir el sistema de versionado semántico (SemVer) lo más fielmente posible: MAJOR.MINOR.PATCH, p. ej., 4.2.1. La versión MAJOR se incrementa en caso de cambios incompatibles, la versión MINOR cuando se añaden nuevas funcionalidades compatibles con versiones anteriores y la versión PATCH para correcciones de errores compatibles con versiones anteriores. Las versiones preliminares y los metadatos de compilación se añaden de la forma definida, por ejemplo, 4.3.0-rc.1 o 4.2.1+build.5821.

SemVer es un esquema muy utilizado, permite ordenar las versiones y puede ser interpretado por herramientas sin necesidad de conocimientos específicos sobre el producto. Sus reglas hacen que el impacto de una actualización quede patente en la propia versión. Si se utiliza un esquema diferente, como el sistema de numeración de versiones por calendario (p. ej., 2026.10.1), este debe documentarse y aplicarse de forma coherente en todas las versiones.

✅ - Utiliza exactamente un esquema de versiones técnicas por producto y documéntalo.
✅ - Utiliza siempre el mismo número de componentes, por ejemplo, 5.0.0, en lugar de alternar entre 5, 5.0 y 5.0.0.
✅ - Asigna a cada compilación publicada exactamente una versión y nunca reutilices una versión para una compilación diferente.
❌ - Nombres de marketing sin una versión técnica, por ejemplo, «Spring Release» o «2026 R2». Si se requieren nombres de marketing, hay que asignar cada uno de ellos de forma inequívoca a una versión técnica.
❌ - Ceros iniciales, letras como nivel de parche (p. ej., 3.1b) y separadores variables (p. ej., 3.1-2 y 3.1.2 para la misma versión).

3. Publicar el historial de versiones en línea

Los proveedores deben publicar en Internet todas las versiones de sus productos y su historial. Para cada versión, la lista debe incluir el identificador exacto de la versión —carácter por carácter, tal y como aparece en el producto— y la fecha de lanzamiento. Lo ideal es que también incluya la fecha de fin de mantenimiento (no se corrigen más errores) y la fecha de fin de soporte o de end-of-life (no se publican más actualizaciones de seguridad), un enlace a las notas de la versión y una nota sobre las vulnerabilidades que se han corregido.

Exhaustividad - Enumera todas las versiones, incluidas las versiones con parches y las correcciones urgentes. No elimines de la lista las versiones antiguas una vez que dejen de tener soporte.
Fechas inequívocas - Utiliza el formato de fecha ISO 8601 (AAAA-MM-DD) para evitar confusiones entre el 03/04/2026 y el 04/03/2026.
URL estable - Mantén estable la dirección del historial de versiones para que se pueda consultar y supervisar automáticamente.
Formato legible por máquina - Además, facilita el historial de versiones en formato JSON o XML, a ser posible a través de una API o un feed.
Mapeo de CPE - Indique el identificador CPE (Common Platform Enumeration) del producto en el historial de versiones legible por máquina, de modo que se pueda establecer una correspondencia con bases de datos de vulnerabilidades, como la Base de Datos Nacional de Vulnerabilidades (NVD), sin necesidad de hacer conjeturas.

Un historial de versiones legible por máquina permite a los clientes y a los proveedores de herramientas procesar automáticamente las nuevas versiones, en lugar de tener que consultarlas en páginas HTML. Un ejemplo sencillo:

version-history.jsonjson

{
	"product": "Example Server",
	"vendor": "Example Ltd",
	"cpe": "cpe:2.3:a:example:example_server:*:*:*:*:*:*:*:*",
	"versions": [
		{
			"version": "4.2.1",
			"releaseDate": "2026-09-15",
			"endOfMaintenance": "2027-09-30",
			"endOfSupport": "2028-03-31",
			"releaseNotes": "https://www.example.com/release-notes/4.2.1",
			"fixedVulnerabilities": [ "CVE-2026-12345" ]
		},
		{
			"version": "4.2.0",
			"releaseDate": "2026-07-01",
			"endOfMaintenance": "2027-09-30",
			"endOfSupport": "2028-03-31",
			"releaseNotes": "https://www.example.com/release-notes/4.2.0"
		}
	]
}

4. Hacer que se pueda consultar el producto y la versión instalados

Una vez instalado un producto, debe ser posible consultar su nombre, el nombre del proveedor y la versión mediante el gestor de paquetes del sistema operativo o la línea de comandos. Los valores devueltos deben coincidir exactamente con el nombre del producto, el nombre del proveedor y el identificador de versión publicados. Solo así se podrá asociar una instalación al historial de versiones y a los avisos de vulnerabilidad sin necesidad de interpretación manual.

Linux - Registra el nombre exacto del producto, el nombre del proveedor y la versión en los metadatos del paquete, por ejemplo, en los campos «Nombre», «Proveedor» y «Versión» de un paquete RPM, que se pueden consultar mediante los comandos «rpm -q» o «dpkg -s».
Windows - Introduce el nombre del producto publicado como «DisplayName», el nombre del proveedor como «Publisher» y la versión como «DisplayVersion» en la clave de registro de desinstalación y en la información de la versión del archivo, o bien facilítalos a través de Winget.
macOS - Establece los valores de «CFBundleName» y «CFBundleShortVersionString» en el archivo «Info.plist» con el nombre y la versión del producto publicado; proporciona paquetes de Homebrew con los mismos nombres y la misma versión.
Línea de comandos - Incluir una opción «--version» que muestre la versión exacta en un formato que se pueda analizar.
Electrodomésticos, containers y servicios - Facilita la versión a través de un punto final de API, un valor SNMP o una etiqueta de imagen, por ejemplo, org.opencontainers.image.version.

Línea de comandosbash

$ example-server --version
4.2.1

Una fuente habitual de errores son los identificadores de versión que varían según dónde se consulten: la página web indica la versión 24.2, el registro de Windows muestra 24.2.0.1234 y la línea de comandos muestra «build 1234». En estos casos, cada herramienta tiene que adivinar a qué número se refiere. Si se necesita un número de compilación interno, debe añadirse como metadatos de la compilación (por ejemplo, 24.2.0+1234) y no sustituir a la versión.

5. Indicar las versiones exactas en los avisos de vulnerabilidad

A la hora de publicar vulnerabilidades, es fundamental indicar con exactitud las versiones afectadas y las que ya se han corregido. Las afirmaciones imprecisas dan lugar a falsos positivos, a parches de emergencia innecesarios y, en el peor de los casos, a que se pasen por alto algunas vulnerabilidades.

Incluso los rangos de versiones como «4.0.0 a 4.2.0» dan lugar a interpretaciones: para evaluarlos, el lector tiene que deducir todas las versiones intermedias o, en el peor de los casos, conocer todas las versiones que se han publicado, incluidas las correcciones urgentes y las compilaciones que nunca aparecieron en una lista de versiones pública. Por lo tanto, lo mejor es enumerar explícitamente todas las versiones afectadas.

❌ - «Todas las versiones anteriores a la última versión», «versión 3.x», «versiones anteriores» o «ponte en contacto con el servicio de asistencia para obtener más información».
❌ - Intervalos de versiones como «4.0.0 a 4.2.0» o «< 4.2.1», que requieren conocer todas las versiones intermedias.
✅ - Enumera explícitamente todas las versiones afectadas, por ejemplo: «versiones afectadas: 4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0; corregido en: 4.2.1».
✅ - Asigna un número de versión fijo a cada línea de versiones compatible, por ejemplo, 3.8.7 y 4.2.1.
✅ - Utiliza los mismos identificadores de versión que aparecen en el historial de versiones y en el producto instalado.
✅ - Publica los avisos en formato legible por máquina, por ejemplo, como documentos CSAF con identificadores CPE o URL de paquete (purl), y enumera las versiones afectadas una por una en el registro CVE.