Évaluer un composant open source
Le problème
L’article 13, paragraphe 5, impose une diligence raisonnable lors de l’intégration de composants tiers, et cette diligence doit être documentée pour être opposable. La grille qui en découle comporte neuf critères : vulnérabilités connues, activité, gouvernance, politique de sécurité amont, réactivité historique, licence, SBOM amont, signature des artefacts, profondeur.
Appliquée à la main, elle est irréprochable sur dix composants et inapplicable sur trois mille. Or c’est l’ordre de grandeur d’un graphe de dépendances réel. Une diligence qui ne s’exécute pas n’est pas une diligence.
Il faut donc rendre la grille calculable.
OpenSSF Scorecard
Scorecard est un outil ouvert de la Fondation OpenSSF qui exécute une série de contrôles automatisés sur un dépôt et produit, pour chacun, une note sur 10 assortie d’un niveau de risque qui la pondère dans une note agrégée.
Son apport n’est pas de remplacer le jugement : c’est de rendre objectif et reproductible ce qui était jusque-là une impression.
Les dix-huit contrôles
| Famille | Contrôles |
|---|---|
| Pratiques de sécurité | Vulnerabilities · Dependency-Update-Tool · Maintained · Security-Policy · License · CII-Best-Practices · CI-Tests · Fuzzing · SAST |
| Risque côté source | Binary-Artifacts · Branch-Protection · Dangerous-Workflow · Code-Review · Contributors |
| Risque côté construction | Pinned-Dependencies · Token-Permissions · Packaging · Signed-Releases |
Ce que chaque critère de la grille devient
| Votre critère | Contrôle Scorecard correspondant | Automatisable |
|---|---|---|
| Vulnérabilités connues | Vulnerabilities (via OSV) |
Oui |
| Activité du projet | Maintained |
Oui |
| Gouvernance, mainteneur unique | Contributors |
Partiellement — il compte les organisations, pas la fragilité |
| Politique de sécurité amont | Security-Policy |
Oui |
| Réactivité historique | — | Non |
| Licence | License (présence seulement) |
Partiellement |
| SBOM amont | — | Non |
| Signature des artefacts | Signed-Releases |
Oui |
| Profondeur des dépendances | — | Non, relève du SBOM |
Six critères sur neuf deviennent mesurables, et Scorecard en ajoute neuf que la grille n’avait pas — protection de branche, revue de code, permissions des jetons, épinglage des dépendances, motifs de chaîne dangereux, analyse statique, tests, fuzzing, artefacts binaires non auditables.
Ce que Scorecard ne dit pas
Point essentiel, à écrire dans la politique pour éviter le faux sentiment de sécurité :
- rien sur la compatibilité de licence avec votre contexte d’usage — voir Licences open source ;
- rien sur l’atteignabilité : un composant bien noté peut porter une vulnérabilité exploitable chez vous, et un composant mal noté peut être inoffensif ;
- rien sur la durée de support amont, qui conditionne pourtant votre période de support ;
- rien sur la qualité du code ni sur l’adéquation fonctionnelle ;
- une note élevée n’aurait écarté aucun des incidents documentés dans Incidents de référence — les projets concernés étaient actifs, revus et largement adoptés.
Scorecard mesure des signaux d’hygiène, pas l’absence de malveillance. C’est utile, borné, et il faut le dire.
S2C2F : le cadre d’ingestion
Là où Scorecard note un composant, le Secure Supply Chain Consumption Framework (S2C2F), également porté par l’OpenSSF, décrit comment consommer de l’open source : un ensemble de pratiques indépendantes des outils, assorti d’un modèle de maturité et d’une cartographie vers d’autres référentiels de chaîne d’approvisionnement.
Son principe directeur est celui que vous appliquez déjà sans le nommer : ne pas consommer directement depuis un registre public, mais passer par une ingestion contrôlée, inventoriée et vérifiée — voir Verrouiller et mettre à jour les dépendances.
Son intérêt pour vous est double : il donne un vocabulaire commun avec vos fournisseurs et vos clients, et il fournit une échelle de maturité utilisable dans le diagnostic.
La politique de seuils
Un score sans seuil n’est pas une politique. Ce qui doit être écrit :
| Situation | Règle proposée |
|---|---|
| Nouveau composant, note ≥ 7 | Adoption sans instruction supplémentaire |
| Nouveau composant, note 5 à 7 | Adoption possible, instruction documentée des contrôles en échec |
| Nouveau composant, note < 5 | Refus par défaut, ou dérogation motivée et datée |
Contrôle Signed-Releases en échec sur un composant critique |
Vérification par empreinte obligatoire |
Contrôle Maintained en échec |
Traiter comme un composant abandonné |
| Composant déjà intégré dont la note baisse | Alerte, réexamen, pas de retrait automatique |
La dernière ligne est celle qu’on oublie : la diligence n’est pas un contrôle d’entrée, c’est une surveillance. Un projet peut perdre son mainteneur trois ans après son adoption.
Où ça s’exécute
| Moment | Ce qui est fait |
|---|---|
| Demande d’adoption d’un composant | Score calculé, joint au ticket, seuil appliqué |
| Construction | Contrôle des seuils sur les dépendances directes, avertissement au-dessous |
| Périodiquement | Recalcul sur les composants critiques, alerte sur baisse |
| Revue annuelle | Réexamen de l’ensemble, avec les composants dont la note s’est dégradée |
Le calcul en continu sur l’intégralité du graphe transitif est coûteux et peu utile : limiter la surveillance périodique aux composants directs et aux transitives critiques — celles dont le remplacement prendrait des mois — donne l’essentiel du bénéfice.
La preuve à conserver
| Artefact | Pourquoi |
|---|---|
| Score horodaté par composant et par version | Montre l’état des connaissances au moment de la décision |
| Grille de diligence complétée, avec les critères non automatisables | Couvre ce que l’outil ne mesure pas |
| Politique de seuils versionnée | Montre que la décision suit une règle, pas une préférence |
| Registre des dérogations, avec expiration | Montre que les exceptions sont maîtrisées |
| Journal des réexamens | Montre que la diligence est continue |
C’est cet ensemble, et non le score seul, qui constitue la diligence documentée attendue par l’article 13, paragraphe 5.
Le piège à éviter. Un score archivé sans la décision qu’il a fondée ne démontre rien. Ce qu’une autorité examine, ce n’est pas la note : c’est le fait qu’une règle écrite ait été appliquée, et que les écarts aient été motivés.