Quatre risques opérationnels à ne pas ignorer

Les risques reconnaissables dans votre chaîne d’approvisionnement de logiciels ne peuvent pas tous être identifiés par leurs vulnérabilités connues enregistrées comme CVE. Un composant obsolète ou inactif peut présenter des risques pour votre application que personne n’a jugé bon d’étudier. Pourtant, ces composants peuvent présenter des menaces.

Les développeurs et équipes de sécurité doivent également pouvoir identifier et évaluer les risques opérationnels des composants ; des logiciels open source qui n’ont pas de CVE enregistré mais qui peuvent tout de même mettre en danger votre organisation.

Quatre facteurs de risques opérationnels

Afin de protéger entièrement votre chaîne d’approvisionnement de logiciels, vous devriez tenir compte de ces quatre facteurs de risques open source opérationnels lorsque vous utilisez ce genre de composants :

Fin de vie

Si l’auteur d’un composant a déclaré que ce dernier est en fin de vie, le risque est alors élevé et cet auteur devrait y prêter attention. 

La même règle s’applique si le composant est considéré comme obsolète. Même si le logiciel open source continue de fonctionner, une négligence intentionnelle signifie que les éventuelles vulnérabilités n’y sont plus activement surveillées. Et même si des failles de sécurité sont repérées, aucune nouvelle version en vue de les corriger ne sera publiée.

Date de la Version

Un code obsolète tend à être moins sécurisé. Si le composant est ancien, même si sa dernière version est disponible, vous ne pouvez pas profiter de toutes les dernières améliorations, et ses dépendances peuvent engendrer des problèmes de sécurité.

Plus le code est ancien, plus le risque est important. Chez JFrog, nous pensons qu’une version datant de plus de 10 mois, mais créée depuis moins de 20 mois, représente un risque faible ; à l’inverse, des versions datant de 3 ans (40 mois) sont estimées à haut risque.

Mise à Jour de la Version

Hormis quelques exceptions, vous devriez toujours essayer d’utiliser la dernière version d’un composant pour bénéficier des nouvelles améliorations. Cela vous permettra d’éviter toute vulnérabilité reconnue dès la première publication.

La première ou deuxième publication d’une version d’un composant ne comporte pas de risque réel. En revanche, le risque augmente de manière proportionnelle si ces versions deviennent obsolètes. Un composant possédant quatre versions plus récentes peut représenter un risque moyen, tandis qu’un composant en retard de six versions ou plus présente un risque élevé.

Intégrité du Projet

Un bon projet open source est issu d’une communauté saine ; d’ailleurs, le haut niveau d’activité de la part des contributeurs l’indiquera. Un composant qui n’est pas fréquemment mis à jour et qui est géré par une seule personne ne bénéficiera pas du même niveau d’amélioration, de supervision ou de vigilance. La situation est pire encore pour un projet qui a été apparemment abandonné.

Les projets de logiciels open source reposent sur une communauté engagée et active de développeurs qui cherchent à enrichir leurs connaissances et leur potentiel. Le projet Kubernetes, par exemple, compte plus de 3 100 contributeurs qui permettent de produire des trois nouvelles versions par an ainsi que des dizaines de versions de correctifs.

Voici les indicateurs clés à prendre en considération lorsque vous évaluez l’intégrité d’un projet :

• Cadence des versions : un projet à l’intégrité minimale devrait fournir au moins 2 versions en disponibilité générale (une nouvelle version ou un correctif) par an. L’intégrité d’un projet avec une seule version chaque année, voire aucune, devrait être considérée comme compromise.

• Fréquence d’engagement : un projet sain devrait comptabiliser plus de 100 engagements par an. En-deçà, ce projet devrait être considéré comme non sain.

• Contributeurs annuels : le projet devrait comptabiliser au moins cinq contributeurs différents par an afin d’être considéré en tant que projet à l’intégrité minimale. Un nombre inférieur indique que le projet n’est pas sain.

Augmentez Vos Chances

Il est important de détecter les risques opérationnels dans votre chaîne d’approvisionnement de logiciels dans vos pratiques DevSeOps. Outre l’identification des vulnérabilités connues et la conformité à la politique en matière de licence, le contrôle de ces risques opérationnels dans vos logiciels de nomenclature permet de compléter une posture de sécurité exhaustive.

L’analyse de composant logiciel (SCA) de JFrog Xray vous facilite la tâche. Outre vos politiques en matière de sécurité et de licence, vous pouvez configurer les politiques en matière de risques opérationnels afin de spécifier vos recherches.

Vous pouvez utiliser les défaillance en matière de risque minimal de JFrog afin de gérer automatiquement la gravité des facteurs de risques opérationnels ou spécifier vos seuils.

Lorsque vous assignez certaines politiques de surveillance concernant des dépôts clés, Xray détectera les composants qui ont causé une violation afin que vous puissiez prendre des mesures.

Vous voulez en savoir plus ? Demandez une démo de Xray.