Aller au contenu
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.

Un décompte de constats par dépôt ne dit pas quelle équipe possède le service ni lequel 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 se sert du fait que le code de première main peut atteindre ou non le paquet touché pour classer chaque avis. 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 le paquet ou n'y fait jamais référence, et, avec un manifeste de symboles, les fonctions vulnérables sont appelées ou non. L'atteignabilité couvre npm, NuGet et Python. Un paquet Python dont le nom d'importation doit être deviné est signalé inconnu plutôt que non observé.

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, et le tableau de bord répond pour la version promue.

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. Une inscription au KEV le place dans agir, quoi que dise l'analyse. Sinon, il est 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.

  • Chaque version de projet porte le SBOM à partir duquel elle a été construite, donc la réponse est par version publiée.
  • 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 l'importe
  • 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é.