Aller au contenu

Inventaire et licences

Inventaire

L'inventaire, c'est le parc vu du côté des paquets plutôt que du côté des cibles : quels composants vous exécutez, dans quelles versions, à combien d'endroits.

Il répond à la question qui arrive le matin où une nouvelle CVE est publiée — est-ce qu'on l'utilise, et où ? — sans rien réanalyser, parce que les SBOM sont déjà stockés.

Ce que le scanner ne voit pas, et que le build voit

Le scanner lit l'arborescence des sources. Pour Maven il lit les poms, si bien qu'une version gérée par un parent ou une BOM est listée UNKNOWN, et qu'une bibliothèque tirée transitivement n'est pas listée du tout. Quand le pipeline du dépôt envoie le SBOM que son build a produit (JSON CycloneDX, de cyclonedx-maven-plugin ou du plugin CycloneDX de Gradle — voir Importer le SBOM d'un build), l'inventaire de chaque scan est celui du scanner complété par lui : la version déclarée par le build à la place d'UNKNOWN, les bibliothèques transitives ajoutées, ce que seul le scanner voit gardé.

Chaque ligne dit qui l'a listée. Dans la recherche de composants, une version marquée build a été déclarée par le SBOM du build : survolez-la pour lire ce que le scanner avait lu à la place, ou si seul le build listait la bibliothèque. L'inventaire consolidé du projet et ses exports disent la même chose par composant (sources). Les scans plus anciens gardent leur inventaire ; les licences et les lignes de checklist lisent les lignes complétées.

Licences

La conformité des licences est évaluée contre une liste de blocage configurable, à partir de données déjà présentes dans le SBOM. Pas de scan séparé, pas d'outil séparé.

Configurez la liste sous Réglages. Ce qui doit y figurer est une décision propre à votre organisation, pas un défaut que quelqu'un d'autre pourrait fournir : l'AGPL est fatale pour un produit propriétaire distribué et sans objet pour un service interne qui n'est jamais livré.

Un composant ajouté par le SBOM du build porte la licence que le build déclare ; là où le scanner l'avait déjà listé sous UNKNOWN, l'entrée passe à la version du build, si bien qu'il est compté une fois.

Une violation de licence est un constat de plein droit. Elle compte pour la barrière, et la politique de barrière peut être réglée pour faire échouer une construction dessus.

La matrice de copyleft

Les licences sont résolues à travers une matrice de copyleft plutôt que comparées comme des chaînes de caractères : une dépendance permissive qui a acquis une transitive copyleft est visible comme telle, et non comme un nom que personne n'a reconnu.

Dérive et différentiel de SBOM

La comparaison de SBOM : la cible d'abord, puis ses propres scans proposés par date et nombre d'issues, les deux plus récents déjà sélectionnés.

Dans l'interface, la cible vient d'abord. Choisir un dépôt ou une image remplit deux listes avec les scans de cette cible — la date, la branche et le nombre d'issues de chacun — et présélectionne les deux plus récents, qui sont la comparaison que presque tout le monde cherche : ce qui a changé depuis la dernière fois. L'autre question, entre la version livrée et la précédente, est à deux clics dans les mêmes listes.

Le numéro du scan reste affiché, en fin de ligne. C'est ce que l'API prend et ce qu'on cite en support ; il n'est simplement plus la seule chose proposée. Cet écran en demandait deux, tapés à la main, qu'aucun écran n'affichait en évidence.

Une cible analysée une seule fois n'a pas de paire, et l'écran le dit plutôt que de laisser deux listes vides.

GET /api/v1/sbom/diff — et la visionneuse équivalente — compare deux SBOM et rapporte :

  • les paquets ajoutés et retirés ;
  • les migrations de licence, par exemple de permissive vers copyleft GPL ou AGPL ;
  • l'impact net en CVE entre les deux.

C'est le contrôle qu'un différentiel de fichier de verrouillage ne peut pas vous donner. Une dépendance dont la licence change entre deux versions mineures ne change rien de visible dans le différentiel de votre manifeste, et change tout à ce que vous avez le droit de livrer.

Une licence est celle que le composant déclare — dans le SBOM du build, sinon dans celui du scanner — et UNKNOWN quand il n'en déclare aucune ; elle n'est jamais devinée d'après le nom du paquet. Un scan dont le SBOM ne se lit pas n'est pas comparé : la route répond 409 de type urn:vectispire:problem:sbom-unreadable, plutôt qu'une comparaison qui se lirait comme tous les composants retirés ou comme aucun changement.

Dette de sécurité

GET /api/v1/remediation/debt convertit le backlog ouvert en heures d'ingénierie estimées et en jours-personnes, et met en avant les correctifs à plus fort impact — ceux où une seule action lève le plus de risque.

Traitez les heures comme un ordre de grandeur plutôt que comme un devis. Leur valeur est dans la comparaison de deux dépôts ou de deux trimestres, pas dans le remplissage d'un plan de projet.