OSS Risk Assessment

devsecops

Définition

L'OSS Risk Assessment (évaluation des risques des composants open source) est le processus d'évaluation multidimensionnelle des risques associés à l'inclusion de composants open source dans un projet logiciel. Au-delà des vulnérabilités de sécurité couvertes par les outils SCA classiques, l'OSS Risk Assessment évalue également la santé du projet open source, les risques de licence, les risques de supply chain, et la durabilité à long terme de la bibliothèque. L'évaluation multidimensionnelle d'un composant open source couvre plusieurs axes de risque. Les risques de sécurité : vulnérabilités connues (CVEs), historique de sécurité du projet (fréquence et gravité des CVEs passées), pratiques de sécurité de la communauté (existence d'une politique de divulgation responsable, signatures des releases, SBOM publiés). Les risques de licence : type de licence (MIT/Apache 2.0 = faible risque, GPL/LGPL = risque modéré à surveiller, AGPL = risque élevé pour les services web), compatibilité avec la licence de votre projet, et risque de changement de licence (certains projets ont changé de licence vers des modèles propriétaires — HashiCorp Vault en 2023, Redis en 2024). Les risques de santé du projet sont souvent négligés mais critiques pour la durabilité : un composant non maintenu (dernier commit > 18 mois, issues non traitées, bugs de sécurité non corrigés) est un risk acutif même sans CVE actuelle. Des métriques de santé open source incluent : activité des commits (fréquence, contributeurs actifs), réactivité des mainteneurs (délai de traitement des issues et PRs), présence de tests automatisés et CI, et soutien organisationnel (projet individuel vs backing d'une fondation ou d'une entreprise). Des outils d'OSS Risk Assessment incluent : OpenSSF Scorecard (évaluation automatisée de la santé de sécurité des projets GitHub), Socket.dev (analyse des risques de supply chain des packages npm), FOSSA (gestion des licences + SCA), et la Deps.dev de Google qui consolide les métadonnées de sécurité, licences, et santé de millions de packages open source.

OpenSSF Scorecard : métriques de santé de sécurité

OpenSSF Scorecard évalue la santé de sécurité des projets open source GitHub selon 18 critères : Branch-Protection (branches protégées ?), CI-Tests (tests CI actifs ?), CII-Best-Practices (badge CII Best Practices obtenu ?), Code-Review (revues de code obligatoires ?), Contributors (maintenu activement ?), Dependency-Update-Tool (Dependabot/Renovate actif ?), Fuzzing (fuzzing intégré ?), License (licence claire ?), Pinned-Dependencies (dépendances fixées par hash ?), SAST (scan SAST actif ?), Security-Policy (SECURITY.md présent ?), Signed-Releases (releases signées ?), Token-Permissions (permissions GitHub Actions minimales ?), Vulnerabilities (CVEs ouvertes ?). Score de 0 à 10, 8+ = santé satisfaisante.

Évaluer le risque de changement de licence

Le risque de changement de licence ("bait and switch") est croissant : HashiCorp (2023), Redis Labs, Elastic, Confluent, MongoDB, et d'autres ont changé leurs licences de MIT/Apache vers des modèles Business Source License (BSL) ou Server Side Public License (SSPL) — impactant les déploiements commerciaux existants. Mitigation : monitoring des changelogs de licences des composants critiques (via GitHub alerts sur les changements de LICENSE), diversification des fournisseurs (pas de dépendance critique unique à un composant sous licence commercialisable), et privilégier les composants sous gouvernance de fondations (Apache Foundation, Linux Foundation, CNCF — moins susceptibles de changements de licence unilatéraux).

Risk score composite pour la priorisation

Un score de risque OSS composite pour prioriser les remédiation : Risk Score = (Criticité CVE × 0.4) + (Score Maintien × 0.3) + (Risque Licence × 0.2) + (Risque Supply Chain × 0.1). Les composants avec score > 7/10 font l'objet d'une revue trimestrielle et d'un plan de remplacement si nécessaire. Ce scoring permet de distinguer un composant avec une CVE moderate mais maintenu activement (score modéré) d'un composant sans CVE mais abandonné depuis 2 ans et sous licence risquée (score élevé).

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis