Résumé

  • OpenSSF Scorecard calcule des résultats automatisés par contrôle et une moyenne pondérée; ses propres documents décrivent des heuristiques, avec faux positifs et faux négatifs.
  • Le projet refuse explicitement d’être un rapport définitif ou une exigence universelle. Un même agrégat peut cacher des situations de contrôle très différentes.
  • La décision de dépendre d’une version donnée appartient au consommateur: elle exige un périmètre, un responsable, des preuves complémentaires et une réponse, que le score ne fournit pas.

Le raccourci honnête d’un outil borné

Le README de Scorecard présente l’outil comme une lecture automatisée de plusieurs heuristiques liées aux bonnes pratiques de sécurité. Chaque contrôle reçoit une note de zéro à dix; la note globale est une moyenne pondérée par niveau de risque. Cet objet est précieux pour orienter l’attention d’un mainteneur ou d’un utilisateur de logiciel libre.

Il serait moins utile s’il prétendait résoudre tous les cas. Scorecard explique au contraire que la sélection des contrôles, leur importance et leur calcul incorporent des choix. Les heuristiques peuvent rater un dispositif réel ou signaler un cas qui n’est pas préoccupant. Le projet dit aussi qu’il n’a pas vocation à constituer une exigence définitive, valable pour tous. Une moyenne ne dit pas quelles pratiques ont produit le chiffre, et son sens peut évoluer lorsque les contrôles changent.

Cette limite n’est pas une excuse. C’est la condition qui permet de lire une mesure comme une mesure. Le score décrit une observation définie d’un dépôt à un instant; il ne décrit pas automatiquement le composant exact qu’une autre organisation va livrer, exécuter ou supporter.

Une moyenne ne porte pas les choix qu’elle masque

Un chiffre unique voyage facilement: tableau de bord, badge, liste de fournisseurs, feuille de conformité. Cette portabilité invite à un seuil mécanique. Pourtant, les contrôles n’ont ni le même poids ni le même objet. Deux projets peuvent atteindre une moyenne identique avec des résultats individuels inverses. L’un peut répondre au risque qui importe dans un environnement précis, l’autre non.

La documentation des contrôles donne plusieurs exemples de cette prudence. Le contrôle Maintained s’appuie sur une activité observable durant une période définie, tout en rappelant qu’un logiciel peu actif n’est pas nécessairement dangereux. Le contrôle SBOM cherche l’existence d’un inventaire à certains endroits. Sa présence est un renseignement utile; elle ne prouve ni l’exhaustivité de l’inventaire, ni sa correspondance avec un binaire déployé, ni la pertinence des décisions qui en seront tirées.

Les surfaces de collecte comptent aussi. Une analyse hebdomadaire publique, une réponse d’API et une exécution avec un accès différent ne sont pas forcément la même observation. Certains résultats d’API omettent des contrôles pour des raisons de coût; certains contrôles peuvent être indéterminés. La référence analysée, l’heure, la version de l’outil, les données accessibles et le détail du résultat doivent accompagner le nombre si l’on veut pouvoir le comprendre plus tard.

Un résultat faible n’est pas un verdict, une annotation n’est pas une preuve indépendante

Scorecard avertit plusieurs fois qu’une pratique peut exister sans être détectée. Un faible résultat ne démontre donc pas, à lui seul, un risque réel, une faute, une compromission ou l’absence de remédiation. Il indique qu’un contrôle défini n’a pas obtenu le signal attendu: c’est une question à examiner, non un jugement sur un projet.

Le mécanisme d’annotations de mainteneur rend cette distinction visible. Des mentions comme test-data, remediated, not-applicable, not-supported et not-detected peuvent ajouter du contexte à un résultat. Elles sont utiles car elles évitent de faire passer l’heuristique pour une vue complète. Elles restent toutefois des explications fournies par le mainteneur. Elles ne constituent ni audit indépendant ni instruction de confiance pour chaque consommateur.

Il faut donc conserver trois objets séparés: le relevé de l’outil, l’explication éventuelle du mainteneur, et la décision de l’organisation qui utilisera le composant. Confondre ces objets revient à faire passer une mesure pour une délégation d’autorité.

La décision commence après l’observation

Une équipe ne dépend pas d’un dépôt abstrait. Elle dépend d’une version, d’un paquet, d’un commit, d’un miroir interne ou d’un artefact issu de sa propre chaîne de construction. Elle connaît ses privilèges, ses données, ses contraintes de continuité, ses mesures compensatoires, ses alternatives et le coût d’un retrait. Ces faits ne sont pas présents dans la moyenne Scorecard, car ils relèvent du consommateur.

La réponse non plus n’est pas produite par un score. Une équipe peut accepter avec une exception datée, demander d’autres preuves, isoler le composant, surveiller une condition, choisir une solution de rechange ou refuser l’usage. Pour chacune de ces options, il faut un responsable, une raison et un prochain point de révision.

Un dossier de décision utile relie donc l’identifiant du dépôt et la référence résolue à la version de Scorecard, à l’heure d’analyse, aux limites d’accès, au score global et aux contrôles réellement pertinents. Il conserve les détails et annotations. Puis il ajoute, séparément, le composant précis, le contexte d’emploi, les éléments indépendants, le décideur, la règle ou l’exception, l’action retenue et la date d’expiration.

Ce petit dispositif ne transforme pas Scorecard en régime de certification. Il rend seulement impossible le glissement silencieux d’une observation publique vers une approbation locale sans propriétaire.

Sources

  1. OpenSSF Scorecard README
  2. Documentation des contrôles Scorecard
  3. Annotations de mainteneur Scorecard