Qu’est-ce que l’analyse de la composition logicielle (SCA) ?

Comme son nom l’indique, l’analyse de la composition logicielle (SCA) permet d’analyser en profondeur les packages open-source utilisés par une application. La SCA met au jour les vulnérabilités et les licences existantes dans les dépendances pour évaluer les risques et le niveau de conformité. L’analyse génère également une nomenclature des composants logiciels (SBOM) de toutes les ressources, qui peut être transmise aux acteurs internes et aux clients externes.

Qu’est-ce que l’analyse de la composition logicielle ?

L’analyse de la composition logicielle permet aux développeurs d’utiliser des packages open-source sans exposer leur entreprise à des vulnérabilités, des risques juridiques ou des problèmes de conformité.

Aujourd’hui, le développement logiciel foisonne de composants open-source, la majorité du codebase des nouvelles applications étant composés de ces packages. Et pour cause, l’open-source est synonyme de rapidité pour les développeurs, qui n’ont qu’à réutiliser le code disponible en libre accès et approuvé par la communauté. Mais cette méthode apporte aussi son lot de risques.

Composants open-source : quels sont les dangers ?

Avant de créer des images de container à partir de ces composants, les développeurs doivent connaître tout problème de sécurité lié à des vulnérabilités détectées dans les packages. Ils doivent également veiller aux exigences de conformité en matière de licences logicielles.

Si les membres de la communauté open-source détectent et corrigent régulièrement les vulnérabilités détectées, il est de la responsabilité des développeurs eux-mêmes de mettre à jour leur code. Lorsqu’une vulnérabilité est identifiée, ce n’est qu’une question de temps avant qu’un exploit public soit disponible, laissant aux attaquants même les plus inexpérimentés le loisir d’en profiter.

Et pour noircir le tableau, la plupart des vulnérabilités logicielles ne se trouvent pas dans des packages racines, mais dans des dépendances de dépendances, enfouies sous de multiples couches. Corriger le package racine utilisé ne suffit pas toujours à sécuriser les bibliothèques concernées.

L’autre problème, c’est qu’il existe des dizaines de licences open-source appliquant toutes des règles différentes. À titre d’exemple, certaines requièrent l’attribution de propriété tandis que d’autres exigent en plus la publication du code source de l’application utilisant le composant. Difficile de s’y retrouver dans toutes ces licences et leurs règles associées.

L’analyse de la composition logicielle identifie les risques dans les packages open-source

Les outils SCA détectent tous les packages open-source dans une application et toutes les vulnérabilités connues dans ces packages. Ces informations servent à alerter les développeurs sur les problèmes éventuels dans leur code pour qu’ils puissent les corriger avant que les attaquants ne les exploitent. Mais une bonne analyse de la composition logicielle ne s’arrête pas aux gestionnaires de packages. Elle examine également l’Infrastructure-as-Code (IaC) et les manifestes Kubernetes, extrayant les images pour y repérer toute vulnérabilité. .
Connectés à des modèles IaC et offrant des analyses illimitées en matière de dépendances, les outils SCA assurent la détection et la correction de toutes les vulnérabilités.

Ces solutions servent également à générer une nomenclature des composants logiciels (SBOM) incluant tous les composants open-source utilisés par une application. La nomenclature apporte des informations sur la version des packages et sur les vulnérabilités connues et les licences pour chaque composant utilisé. Par exemple, pour Python, la SBOM inclura tous les packages des instructions import, comme httplib2, ainsi que le numéro de version, les vulnérabilités détectées et les licences pour chaque package.

Les outils SCA favorisent en outre la collaboration entre les forces vives de l’entreprise : ingénierie, DevOps, sécurité et conformité. Les entreprises sont nombreuses à recourir à ces solutions pour créer des alertes et empêcher l’intégration de code à des dépôts lorsque le code en question inclut des composants open-source non conformes aux exigences de l’organisation en matière de contrôle des expositions. Pour déterminer le niveau de sévérité acceptable des vulnérabilités et les types de licences autorisés, tous les acteurs concernés doivent être impliqués.

SCA et processus de développement : mode d’emploi

Pour être efficace, une solution SCA doit s’intégrer à l’ensemble du processus de développement. Dans les environnements locaux d’abord, les développeurs doivent être en mesure de vérifier en temps réel que leur code ne présente aucune vulnérabilité et que les licences sont conformes.

Grâce à des plug-ins d’environnements de développement intégré (IDE), les outils SCA informent les développeurs en cas de vulnérabilités détectées pendant l’ajout de packages. Avant le commit du code dans un dépôt, des vérifications et des commentaires automatisés de pull requests informent les développeurs de tout problème éventuel et bloquent le code non conforme.

Ces fonctionnalités doivent s’étendre aux environnements où des logiciels associés à des niveaux prédéterminés de vulnérabilités ou certains types de licences peuvent être bloqués avant déploiement. Les équipes de sécurité doivent elles aussi bénéficier d’une visibilité globale sur la posture des composants dans leur environnement.

L’analyse de la composition logicielle s’applique du code au cloud et de l’infrastructure aux couches applicatives pour détecter les vulnérabilités tout au long du cycle de développement.

Quel que soit le domaine, les développeurs doivent connaître les risques auxquels les packages peuvent les exposer. Les vulnérabilités doivent être classées et priorisées (à partir du score CVE, du temps écoulé depuis leur signalement, etc.) selon leur criticité et leur impact sur l’infrastructure (si le package vulnérable se trouve dans un VPC privé, par exemple). Les licences, quant à elles, doivent être divisées en deux catégories : 1) les licences autorisées qui requièrent des informations complémentaires telles que l’attribution de propriété, et 2) les licences non autorisées en vertu des politiques de l’entreprise, telles que les licences dites « copyleft ».

Analyse de la composition logicielle : les avantages

Les équipes doivent bénéficier d’une visibilité totale sur la posture de leurs environnements applicatifs. En les informant de manière précoce et régulière sur la conformité des licences et la présence de vulnérabilités, la SCA permet de réduire certains des risques associés à l’utilisation de composants open-source dans les applications. Et bien que le risque zéro n’existe pas, connaître le risque et évaluer le coût des correctifs potentiels participent à l’amélioration globale de la posture de sécurité.

Pour explorer plus en détail la sécurité des processus de développement, consultez la page Qu’est-ce que le DevSecOps ?