Intégrer de l'open source
La règle centrale
Lorsque vous intégrez un composant libre dans un produit que vous mettez sur le marché, vous en portez la responsabilité réglementaire intégrale. L’amont n’est pas responsable à votre place, et ce quelle que soit la licence.
C’est la conséquence directe de l’architecture du règlement : la responsabilité suit la mise sur le marché, pas l’écriture du code.
L’obligation de diligence
Le fabricant doit faire preuve de diligence raisonnable lorsqu’il intègre des composants provenant de tiers, y compris des composants libres, afin que ces composants ne compromettent pas la cybersécurité du produit.
Cette diligence doit être documentée, composant par composant, pour être opposable.
Grille de diligence
| Critère | Ce qu’on vérifie | Source |
|---|---|---|
| Vulnérabilités connues | Absence de vulnérabilité exploitable connue non corrigée | EUVD, OSV, NVD, avis amont |
| Activité du projet | Fréquence des publications, date du dernier commit, nombre de mainteneurs actifs | Dépôt |
| Gouvernance | Projet porté par une fondation ou un sponsor ? Mainteneur unique ? | Documentation du projet |
| Politique de sécurité amont | Existence d’un SECURITY.md, d’un canal de signalement, d’un historique d’avis |
Dépôt |
| Réactivité historique | Délai moyen entre signalement et correctif sur les vulnérabilités passées | Historique des avis |
| Licence | Identifiant SPDX, famille, compatibilité avec votre politique | Familles de licences |
| SBOM amont | Le projet publie-t-il lui-même un SBOM ? | Publications du projet |
| Signature des artefacts | Les publications sont-elles signées et vérifiables ? | Publications |
| Profondeur | Nombre et nature des dépendances transitives introduites | Analyse |
Un score composite permet de trancher entre adopter, adopter sous surveillance, ou refuser. La grille remplie est versée au dossier de diligence du produit.
Cette grille est inapplicable à la main au-delà de quelques dizaines de composants, et un graphe de dépendances réel en compte des milliers. Six de ces neuf critères se calculent automatiquement : voir Évaluer un composant open source, qui décrit l’outillage, ce qu’il couvre, ce qu’il ne dit pas, et la politique de seuils à écrire.
L’obligation de remontée à l’amont
Lorsque vous identifiez une vulnérabilité dans un composant intégré, y compris libre, vous devez :
- la signaler à la personne ou à l’entité qui fabrique ou maintient ce composant ;
- traiter et corriger la vulnérabilité dans votre produit ;
- lorsque c’est pertinent, partager avec le projet amont le correctif que vous avez développé.
C’est une obligation, pas une bonne pratique. Elle suppose un processus outillé :
- un canal identifié vers chaque projet amont critique — adresse de sécurité, procédure de signalement privé ;
- un journal des remontées : date, projet, vulnérabilité, contenu du signalement, réponse obtenue, correctif partagé ;
- une politique de contribution qui autorise vos ingénieurs à publier un correctif sous la licence du projet amont, sans passer par une validation juridique de plusieurs semaines qui rendrait l’obligation intenable.
Point de friction fréquent. Une politique de propriété intellectuelle interdisant toute publication de code par les salariés rend impossible le respect de cette obligation. Les deux politiques doivent être réconciliées explicitement, par écrit.
Les composants abandonnés
Un composant non maintenu dans un produit couvert par une période de support de cinq ans est une dette réglementaire : il n’y aura personne, en amont, pour corriger la prochaine vulnérabilité.
Quatre stratégies, à décider produit par produit et à documenter :
| Stratégie | Quand | Coût |
|---|---|---|
| Remplacer | Une alternative maintenue existe | Coût de migration, ponctuel |
| Forker et maintenir | Pas d’alternative, composant central | Coût récurrent, sur toute la période de support |
| Internaliser | Le composant est petit et son périmètre stable | Coût de reprise, puis maintenance |
| Contribuer à sa relance | Le projet est viable mais sous-doté | Coût récurrent, résultat non garanti |
La stratégie « ne rien faire et espérer » n’est pas défendable devant une autorité, puisque la fin de maintenance amont est un fait public et donc connu de vous.
Le point de vigilance de la reprise malveillante
Un composant abandonné dont le contrôle est repris par un tiers est un vecteur documenté d’attaque de chaîne d’approvisionnement. La surveillance du changement de mainteneur sur les dépendances critiques fait partie de la diligence continue — voir Risques de chaîne d’approvisionnement.