Solutions

Sachez lesquels de vos projets sont exposés, et si cela compte.

Un avis paraît. Personne ne peut dire quels services livrent la version touchée, et l'analyseur liste chaque occurrence comme si chacune était exploitable. L'équipe passe la journée sur la liste plutôt que sur le correctif.

Pourquoi cela se répète

Les analyseurs signalent une présence, pas une exposition.

Une analyse de composition logicielle liste chaque paquet vulnérable qu'elle trouve dans le graphe de dépendances. Beaucoup ne servent qu'au développement, arrivent par transitivité sans jamais être chargés, ou ont été déclarés puis oubliés. Chacun est signalé avec la même sévérité qu'un paquet que votre gestionnaire de requêtes appelle vraiment.

L'exposition est une question de versions publiées, pas de dépôts. Quelle version de quel service tourne avec le paquet touché, et était-ce la version d'avant le correctif ou celle d'après? Sans nomenclature par version publiée, la réponse se reconstruit à partir de l'historique des déploiements.

À l'échelle d'un portefeuille, les chiffres cessent de vouloir dire quelque chose. Un décompte de constats sur toutes les équipes ne dit rien sur le service à corriger en premier.

Comment nous le résolvons

Une nomenclature par version publiée, et une réponse d'exposition par projet.

Projets dans Dependably Packages conserve une nomenclature logicielle pour chaque version publiée de chaque projet, suit quels paquets chacune livre, et classe chaque avis selon que le code de première main peut atteindre ou non le paquet touché. L'atteignabilité vient d'un outil compagnon qui s'exécute dans votre CI.

Analyser le build dans la CI

sbom-reach s'exécute sur le dépôt, génère un SBOM CycloneDX, cherche les vulnérabilités dans la base OSV publique ou dans un service de vulnérabilités privé que vous lui indiquez, et annote chacune d'une atteignabilité au niveau du paquet : le code de première main importe et appelle le paquet, l'importe sans l'appeler, ou n'y fait jamais référence. L'atteignabilité couvre npm et NuGet; les projets Python obtiennent le SBOM et les vulnérabilités sans verdict.

bom.cdx.json · results.sarif

Téléverser vers la version du projet

Le SBOM est téléversé vers la version du projet, et le journal SARIF y inscrit les faits d'atteignabilité. Une version peut être promue comme la plus récente, de sorte que la version publiée courante est toujours celle pour laquelle le tableau de bord répond.

PUT /api/v1/sbom · /api/v1/sarif

Priorité selon l'atteignabilité

Chaque avis est placé dans une tranche de priorité, suivre, examiner ou agir, d'après son score CVSS, son inscription au KEV et sa probabilité EPSS, puis déplacé selon ce que l'analyse a observé : atteignable le monte d'une tranche, non observé le descend d'une tranche là où l'analyse couvrait cet écosystème et où le paquet n'a pas de script d'installation, et importé sans appel ou inconnu le laissent en place.

atteignable · non observé

Cumuler entre projets

Les projets s'imbriquent dans des collections, et la sévérité, l'état de politique et la date du dernier téléversement se cumulent le long de l'arbre, de sorte que l'exposition d'une équipe et celle d'un portefeuille sont la même requête à des profondeurs différentes. Toute version exporte son SBOM, et ses décisions de vulnérabilité en VEX.

cumul · export
Ce que vous obtenez

La liste de ce qu'il faut corriger en premier, par service.

Quand un avis paraît, quelles versions publiées le livrent et si votre code peut l'atteindre est une réponse dans le tableau de bord plutôt qu'une journée de travail.

  • Chaque version de projet porte le SBOM à partir duquel elle a été construite, donc la réponse est par version publiée, pas par dépôt.
  • Les avis que votre code peut atteindre sont en haut; ceux auxquels rien ne fait référence sont en dessous, toujours visibles.
  • L'état de politique par version dit si une version publiée passe vos règles avant sa livraison.
  • Les cumuls par collection montrent quelle équipe ou quel portefeuille porte l'exposition.
Ligne d'avis
  • avis example-parser@3.1.0 · élevée
  • atteignable src/api/upload.ts importe et appelle
  • priorité examiner → agir
  • livré dans billing-api 2.8.0 · portal 5.1.2
Où cela s'exécute

Auto-hébergé, ou hébergé par nous sur demande.

Projets fait partie de Dependably Packages, livré sous forme d'une seule image de conteneur sous Apache-2.0. sbom-reach est sous licence Apache-2.0 et se construit à partir des sources avec Node et pnpm; l'atteignabilité NuGet demande aussi le SDK .NET. Dependably Cloud fait tourner le même moteur sur un forfait payant que nous exploitons; joignez-nous pour discuter d'un déploiement hébergé.