Bonnes pratiques en matière de gestion des versions logicielles

Cinq recommandations à l'intention des éditeurs de logiciels concernant les noms de produits, les identifiants de version, les données relatives au cycle de vie et les avis de vulnérabilité

En bref Request une démo Commencez un essai gratuit

Pourquoi les identifiants de version sont-ils importants ?

Un identifiant de version est bien plus qu'une simple étiquette sur une page de téléchargement. C'est la clé qui relie un produit installé à sa date de sortie, à sa période de support et à ses vulnérabilités connues. Si cette clé est ambiguë, tous les processus qui en dépendent perdent leur fiabilité : les scanners de vulnérabilités signalent des faux positifs ou, pire encore, passent à côté de véritables vulnérabilités, les avertissements end-of-life arrivent trop tard et les décisions concernant les correctifs reposent sur des suppositions.

Un produit, cinq identités : la version 1.97.56 de Brave apparaît sous différents noms de produit et différentes versions dans les notes de mise à jour, sous Windows, sous macOS, dans le paquet Linux et dans le dictionnaire CPE du NVD.

Versio.io gère une base de données répertoriant les end-of-life et les versions de milliers de produits, et la compare quotidiennement aux versions logicielles détectées dans les environnements de ses clients. Ce faisant, nous rencontrons régulièrement des produits et des versions qui ne peuvent pas être identifiés sans ambiguïté : plusieurs orthographes pour un même nom de produit, des identifiants de version qui diffèrent entre le site web, le programme d'installation et le gestionnaire de paquets, des historiques de versions sans dates et des avis de vulnérabilité qui mentionnent uniquement « les anciennes versions ».

Petit test : dans quelle mesure votre produit est-il identifiable ?

Cochez les cases correspondant à votre produit. Chaque point est expliqué en détail ci-dessous ; la flèche vous permet d'accéder directement à la recommandation correspondante.

Le produit et le fournisseur ont chacun exactement un nom, qui est utilisé de manière cohérente partout.↓Le schéma de numérotation des versions respecte les principes du « Semantic Versioning » ou est documenté et appliqué de manière cohérente.↓Chaque version est publiée en ligne avec son identifiant de version exact et sa date de publication (ISO 8601).↓L'historique des versions est également disponible dans un format lisible par machine (JSON, XML ou API), ainsi que d'autres métadonnées importantes.↓Le nom du produit, le nom du fournisseur et la version peuvent être consultés via le gestionnaire de paquets du système d'exploitation ou la ligne de commande ; ils correspondent exactement aux noms et versions publiés.↓Les avis de vulnérabilité répertorient précisément toutes les versions concernées et les versions corrigées, sans indiquer de fourchettes de versions.↓

Les recommandations suivantes s'adressent aux éditeurs de logiciels. Elles sont volontairement simples, peu coûteuses à mettre en œuvre et utiles à tous ceux qui utilisent ou surveillent vos produits :

Clients et opérateurs - peuvent voir d'un seul coup d'œil si leur installation est à jour, si elle bénéficie toujours d'un support technique et si elle est concernée par une faille de sécurité.
Scanners de vulnérabilités - permet d'associer avec précision les CVE aux versions installées, sans faux positifs ni faux négatifs.
Suivi en end-of-life - peut signaler en temps utile la fin prochaine du support.
CMDB et gestion des actifs - permet de consigner les versions de manière cohérente et conforme aux exigences d'audit.
Les vendeurs eux-mêmes - réduire le nombre de demandes d'assistance et se conformer aux exigences réglementaires telles que celles de la loi sur la cyber-résilience (CRA), notamment en matière de SBOM, de durées de prise en charge et de gestion des vulnérabilités.

1. Définir des noms uniques pour les produits et les fournisseurs

Avant de pouvoir attribuer une version, il faut déterminer clairement à quel produit elle se rapporte. Les éditeurs doivent donc définir exactement un nom de produit et exactement un nom d'éditeur, et les utiliser de manière cohérente partout : sur le site web, dans le programme d'installation, dans les métadonnées du paquet, dans l'historique des versions et dans les avis de vulnérabilité.

Si un même produit apparaît sous les noms « Brave », « Brave-Browser » et « Brave Browser », chaque outil doit déterminer s'il s'agit d'un, deux ou trois produits distincts. Il en va de même pour les noms de fournisseurs tels que « Example », « Example Ltd » et « Example Software Ltd ». Chaque variante crée une entrée supplémentaire dans les inventaires, les SBOM et les bases de données de vulnérabilités — et un écart potentiel lors de la mise en correspondance des versions et des CVE.

✅ - Définissez un nom de produit Canonical et un nom de fournisseur Canonical, en tenant compte de l'orthographe, des espaces, des tirets et de la capitalisation.
✅ - N'utilisez des noms de produits différents que pour des produits qui sont réellement distincts, par exemple un serveur et son client.
✅ - Si un produit ou un fournisseur change de nom, consignez l'ancien nom et la date du changement dans l'historique des versions.
❌ - Variantes portant le même nom selon la plateforme, le programme d'installation ou la page de téléchargement.

2. Respecter les règles de gestion des versions sémantiques

Les versions des produits doivent respecter autant que possible les règles de la notation sémantique des versions (SemVer) : MAJOR.MINOR.PATCH, par exemple 4.2.1. La version MAJOR est incrémentée en cas de modifications incompatibles, la version MINOR pour les nouvelles fonctionnalités rétrocompatibles et la version PATCH pour les corrections de bogues rétrocompatibles. Les versions préliminaires et les métadonnées de compilation sont ajoutées selon la convention définie, par exemple 4.3.0-rc.1 ou 4.2.1+build.5821.

SemVer est largement utilisé, permet le tri et peut être interprété par des outils sans aucune connaissance particulière du produit. Ses règles permettent de visualiser l'impact d'une mise à jour directement dans la version elle-même. Si un autre schéma est utilisé, tel que la numérotation calendaire (par exemple 2026.10.1), celui-ci doit être documenté et appliqué de manière cohérente pour toutes les versions.

✅ - Utilisez exactement un seul schéma de version technique par produit et consignez-le par écrit.
✅ - Utilisez toujours le même nombre de chiffres, par exemple 5.0.0, au lieu d'alterner entre 5, 5.0 et 5.0.0.
✅ - Attribuez à chaque version publiée exactement un numéro de version, et ne réutilisez jamais un numéro de version pour une autre version.
❌ - Noms marketing sans correspondance avec une version technique, par exemple « Spring Release » ou « 2026 R2 ». Si des noms marketing sont nécessaires, associez chacun d'entre eux sans ambiguïté à une version technique.
❌ - Les zéros non significatifs, les lettres indiquant le niveau de correctif (par exemple 3.1b) et les séparateurs variables (par exemple 3.1-2 et 3.1.2 pour la même version).

3. Publier l'historique des versions en ligne

Les éditeurs doivent publier en ligne toutes les versions de leurs produits ainsi que leur historique. Pour chaque version, la liste doit contenir l'identifiant exact de la version — caractère par caractère, tel qu'il apparaît dans le produit — ainsi que la date de sortie. Idéalement, elle devrait également indiquer la date de fin de maintenance (plus aucune correction de bogues) et la date d’end-of-life (plus aucune mise à jour de sécurité), un lien vers les notes de mise à jour et une mention précisant quelles vulnérabilités ont été corrigées.

Exhaustivité - Répertoriez toutes les versions, y compris les versions correctives et les correctifs d'urgence. Ne supprimez pas les anciennes versions de la liste lorsqu'elles ne sont plus prises en charge.
Dates sans ambiguïté - Utilisez le format de date ISO 8601 (AAAA-MM-JJ) pour éviter toute confusion entre le 03/04/2026 et le 04/03/2026.
URL permanente - Veillez à ce que l'adresse de l'historique des versions reste inchangée afin qu'il puisse être consulté et suivi automatiquement.
Format lisible par machine - Fournissez également l'historique des versions au format JSON ou XML, de préférence via une API ou un flux.
Cartographie du CPE - Indiquez l'identifiant CPE (Common Platform Enumeration) du produit dans l'historique des versions lisible par machine, afin que les bases de données de vulnérabilités, telles que la National Vulnerability Database (NVD), puissent être mises en correspondance sans avoir à recourir à des suppositions.

Un historique des versions lisible par machine permet aux clients et aux éditeurs d'outils de traiter automatiquement les nouvelles versions, plutôt que de les consulter sur des pages HTML. Voici un exemple simple :

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. Permettre la recherche du produit et de la version installés

Une fois un produit installé, il doit être possible de consulter son nom, le nom de son éditeur et sa version à l'aide du gestionnaire de paquets du système d'exploitation ou de la ligne de commande. Les valeurs renvoyées doivent correspondre exactement au nom du produit, au nom de l'éditeur et à l'identifiant de version publiés. Ce n'est qu'ainsi qu'une installation pourra être mise en correspondance avec l'historique des versions et les avis de vulnérabilité sans nécessiter d'interprétation manuelle.

Linux - Enregistrez le nom exact du produit, le nom du fournisseur et la version dans les métadonnées du paquet, par exemple dans les champs « Name », « Vendor » et « Version » d'un paquet RPM, accessibles via la commande « rpm -q » ou « dpkg -s ».
Windows - Saisissez le nom du produit publié dans le champ « DisplayName », le nom du fournisseur dans le champ « Publisher » et la version dans le champ « DisplayVersion » de la clé de registre de désinstallation et dans les informations de version du fichier, ou indiquez-les via Winget.
macOS - Définissez les propriétés `CFBundleName` et `CFBundleShortVersionString` dans le fichier `Info.plist` en indiquant respectivement le nom et la version du produit publié ; veillez à ce que les paquets Homebrew portent les mêmes noms et la même version.
Ligne de commande - Prendre en charge une option --version qui affiche la version exacte sous une forme analysable.
Appareils, containers et services - Indiquez la version via un point de terminaison API, une valeur SNMP ou une étiquette d'image, par exemple org.opencontainers.image.version.

Ligne de commandebash

$ example-server --version
4.2.1

Une source d'erreurs courante réside dans les identifiants de version qui varient selon l'endroit où ils sont consultés : le site web indique la version 24.2, le registre Windows affiche 24.2.0.1234 et la ligne de commande affiche « build 1234 ». Dans de tels cas, chaque outil doit deviner de quel numéro il s'agit. Si un numéro de build interne est nécessaire, il doit être ajouté sous forme de métadonnées de build (par exemple 24.2.0+1234) et ne doit pas remplacer la version.

5. Indiquer les versions exactes dans les avis de vulnérabilité

Lors de la publication d'informations sur des vulnérabilités, il est essentiel de préciser exactement les versions concernées et celles pour lesquelles un correctif a été apporté. Des déclarations vagues peuvent entraîner des faux positifs, la publication de correctifs d'urgence inutiles et, dans le pire des cas, la négligence de certaines vulnérabilités.

Même les plages de versions telles que « de 4.0.0 à 4.2.0 » laissent place à l'interprétation : pour les évaluer, le lecteur doit déduire toutes les versions intermédiaires — ou, dans le pire des cas, connaître toutes les versions jamais publiées, y compris les correctifs et les versions qui ne sont jamais apparues dans une liste de versions publique. Il est donc préférable d'énumérer explicitement toutes les versions concernées.

❌ - « Toutes les versions antérieures à la dernière version », « version 3.x », « versions antérieures » ou « contactez le service d'assistance pour plus de détails ».
❌ - Les plages de versions telles que « 4.0.0 à 4.2.0 » ou « < 4.2.1 », qui nécessitent de connaître toutes les versions intermédiaires.
✅ - Énumérez explicitement toutes les versions concernées, par exemple : « versions concernées : 4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0 ; corrigé dans la version : 4.2.1 ».
✅ - Attribuez un numéro de version fixe à chaque branche de version prise en charge, par exemple 3.8.7 et 4.2.1.
✅ - Utilisez les mêmes identifiants de version que ceux figurant dans l'historique des versions et dans le produit installé.
✅ - Publiez les avis de sécurité sous un format lisible par machine, par exemple sous forme de documents CSAF comportant des identifiants CPE ou des identifiants d'URL de paquet (purl), et répertoriez individuellement les versions concernées dans la fiche CVE.