Maintenance des SBOM au fil des versions produit
Sytance · Mis à jour
Une SBOM doit rester associée à la version logicielle qu’elle décrit. Une mise à jour logicielle peut modifier les composants, tandis qu’une correction de la SBOM peut simplement rectifier des informations relatives à une version inchangée. Le fait d’enregistrer les deux versions permet de savoir ce que les clients ont reçu et quel inventaire décrit correctement ce logiciel.
Le logiciel décrit par chaque inventaire
Choisissez un point reproductible du processus de compilation ou de publication pour générer la SBOM. Conservez la révision du code source, les dépendances résolues, la configuration de compilation et l’identité de l’artefact final nécessaires pour reproduire ou examiner l’inventaire.
Le guide CycloneDX distingue les inventaires générés à partir du code source, pendant une compilation et en exploitation. Ces étapes peuvent couvrir des logiciels différents. Indiquer l’étape permet au destinataire de savoir si la SBOM décrit les dépendances déclarées, le résultat d’une compilation ou le logiciel déployé.
Pour une passerelle, regroupez les informations issues de la compilation de l’application, de l’image de base et des composants de micrologiciel fournis. Conservez le lien avec chaque SBOM de fournisseur. Un service cloud utilisé par la passerelle peut nécessiter un inventaire distinct, avec son propre rythme de publication.
Modifications des composants entre les versions
La comparaison des versions indique les composants ajoutés, supprimés, mis à niveau ou reconstruits, ainsi que les modifications des chemins de dépendance. Le seul décompte des composants peut masquer un remplacement : une bibliothèque peut être supprimée et une autre ajoutée sans changement du total.
Utilisez des identités normalisées pour la comparaison tout en conservant les versions et identifiants d’origine. Si un outil commence à reconnaître des paquets auparavant inconnus, distinguez une meilleure visibilité d’un changement réel du logiciel.
- Composants ajoutés ou supprimés et chemins de dépendance de leurs composants parents.
- Changements de version, correctifs en aval et empreintes de hachage d’artefacts modifiées.
- Modifications des déclarations de licence ou des producteurs de composants.
- Nouvelles lacunes, identifiants corrigés et révisions des SBOM fournisseurs.
Vérifications avant publication
Validez le fichier au regard de la version du format, puis examinez sa signification. Vérifiez que chaque référence peut être résolue, que le produit racine correspond à la version prévue et que le destinataire peut accéder à toutes les SBOM de composants associées.
Lancez les vérifications des vulnérabilités et des licences sur la version candidate, puis consignez les résultats pour cette version. Tout nouveau problème prioritaire nécessite une décision de traitement. Il convient de réexaminer une ancienne exception si la version du composant ou les hypothèses d’exploitation ont changé.
Archivez ensemble l’artefact accepté, la SBOM, les références de compilation et le résultat de l’examen. Si une signature est utilisée, vérifiez-la et confirmez qu’elle provient de l’émetteur attendu.
Corrections apportées à une SBOM existante
Les orientations conjointes de 2026 sur les SBOM préconisent une SBOM pour chaque version ou mise à jour logicielle, ainsi qu’une SBOM révisée lorsque des erreurs sont corrigées ou que de nouvelles informations sur les composants deviennent disponibles. Elles distinguent également les informations inconnues de celles qui sont volontairement retenues.
Par exemple, un fournisseur corrige le nom du producteur d’un composant alors que les octets du micrologiciel restent inchangés. Conservez l’identité du micrologiciel, publiez une nouvelle révision de la SBOM, expliquez la correction et gardez le document précédent. Les destinataires peuvent ainsi distinguer une correction de données d’une mise à jour logicielle.
Publiez une mise à jour par le canal de distribution convenu. Une page d’accès stable peut pointer vers la révision actuelle, tandis que des fichiers immuables conservent l’historique. Vérifiez que les destinataires peuvent déterminer quelle révision remplace une version antérieure.
Nouvelles vulnérabilités dans les versions prises en charge
À la réception d’un avis, recherchez les identités des composants dans toutes les versions prises en charge. Examinez les compilations réelles et l’utilisation du produit avant d’attribuer un impact. Séparez l’inventaire des composants de l’évaluation des vulnérabilités afin de pouvoir réévaluer la même SBOM lorsque de nouvelles informations apparaissent.
Si la version 1.0 de la passerelle contient une bibliothèque concernée et que la version 1.1 la supprime, cette nouvelle version ne change pas la composition des appareils version 1.0 déjà installés. L’équipe doit tout de même prévoir une réponse pour ces appareils et consigner avec exactitude les versions couvertes par un avis ou une déclaration VEX.
Définissez qui gère les mises à jour des fournisseurs, qui évalue l’impact, qui approuve une réponse et qui la communique. Fixez le calendrier d’examen en fonction des obligations de support du produit et de la gravité des nouvelles informations, plutôt que d’attendre uniquement la prochaine publication planifiée.
Conservation des dossiers et transfert
À la fin de la période de support, conservez la correspondance entre les versions et les SBOM ainsi que les décisions nécessaires pour expliquer les livraisons antérieures. Limitez l’accès aux dossiers sensibles de façon appropriée tout en permettant aux destinataires autorisés d’obtenir les informations qui leur ont été promises.
Lors d’un transfert, le nouveau responsable de la maintenance doit pouvoir trouver l’inventaire d’une version du produit, localiser un composant et consulter la dernière évaluation de son impact. Le parcours d’une version prise en charge permet de repérer les dossiers ou droits d’accès manquants.