Intégrer l’analyse de sécurité C/C++ de Snyk Open Source aux pipelines CI
Michal Brutvan
8 septembre 2022
0 minutes de lectureSnyk Open Source prend en charge l’analyse des dépendances open source intégrées au code en C et C++ via l’interface CLI — et nous sommes heureux d’annoncer que cette fonctionnalité est désormais disponible via nos plugins CI également. Ce guide vous explique comment intégrer l’analyse de sécurité C/C++ à vos pipelines afin de transmettre directement aux développeurs des informations sur les vulnérabilités et des conseils de correction. Notez que dans ce guide, nous désignerons simplement le « C/C++ » par « C++ ».
Option 1 : utiliser des plugins CI
Snyk s’intègre à de nombreuses plateformes CI/CD, notamment Jenkins, Azure DevOps et GitHub Actions. Tous ces plugins ont un point commun : ils encapsulent la CLI Snyk et d’autres outils pour simplifier la configuration et l’utilisation. Cela signifie aussi que leur configuration est identique et qu’ils permettent tous de spécifier un argument de ligne de commande supplémentaire à transmettre à la CLI Snyk.
Pour analyser un projet C++, il vous suffit d’ajouter --unmanaged comme argument supplémentaire. Voici un exemple de configuration du plugin Snyk Security pour Jenkins :

Une fois la compilation terminée, un élément Snyk Security Report sera disponible sur la page des détails de la compilation :

Le rapport de sécurité répertorie les vulnérabilités détectées dans les dépendances open source identifiées. Pour chaque vulnérabilité, il indique sa gravité, la dépendance concernée et la version du projet open source qui la corrige.

Option 2 : utiliser un script
Les deux commandes CLI utilisées pour analyser les projets C++ sont snyk test et snyk monitor, toutes deux avec l’option de ligne de commande --unmanaged. Elles recherchent toutes deux dans le code les dépendances open source et leurs vulnérabilités, mais ont des objectifs différents.
snyk test
La commande snyk test --unmanaged est la commande de base pour générer la liste des vulnérabilités. Elle identifie les dépendances open source dans votre code, puis interroge la Snyk Vulnerability Database pour rechercher les vulnérabilités connues. Conçue pour fonctionner dans les pipelines CI (avec prise en charge de la sortie JSON), elle renvoie un code de sortie différent de zéro lorsqu’un problème est détecté. Si vous stockez vos dépendances open source sous forme d’archives, la CLI Snyk peut également les analyser.
snyk monitor
Contrairement à la commande précédente, la commande snyk monitor --unmanaged délègue le signalement des problèmes à l’interface Snyk. Elle crée un instantané des dépendances et des vulnérabilités actuellement identifiées, puis les importe dans votre tableau de bord Snyk. Les dépendances identifiées y sont ensuite surveillées afin de détecter de nouvelles vulnérabilités, et vous recevez une alerte lorsqu’une nouvelle vulnérabilité est ajoutée à la Snyk Vulnerability Database. Cette commande ne renvoie pas de code de sortie lorsqu’un problème est détecté.
Il est important de noter que cette commande crée réellement un instantané des dépendances détectées à ce moment précis. Snyk ne conserve les signatures sur ses serveurs que pendant une courte période, à des fins de dépannage. Notre base de données open source évoluant, Snyk peut être en mesure de détecter de nouvelles bibliothèques et leurs vulnérabilités. Il est donc recommandé d’exécuter régulièrement la commande snyk monitor --unmanaged.
snyk-to-html
snyk-to-html est un outil autonome qui convertit la sortie JSON de snyk test --json en un document HTML lisible. Voici un exemple d’utilisation classique avec la commande snyk test en mode unmanaged :
Pour tout combiner
Une surveillance régulière est essentielle pour maintenir votre niveau de sécurité. Pour sécuriser votre code, la meilleure approche consiste à importer dans le tableau de bord Snyk un instantané des dépendances identifiées, puis à laisser la surveillance nocturne vous alerter en cas de nouvelles vulnérabilités. Exécuter régulièrement snyk monitor --unmanaged garantit que l’instantané des dépendances est à jour avec les dernières données sur les vulnérabilités, et vous permet de recevoir des alertes dès l’apparition de nouvelles failles dans notre base de données.
Pour tester des commits ou des branches individuels et faire échouer le pipeline en cas de vulnérabilités, exécutez uniquement la commande snyk test --unmanaged. Enchaîner la commande test avec snyk monitor --unmanaged importera également immédiatement les résultats dans votre tableau de bord. L’instantané des dépendances ne sera mis à jour que si le test réussit :
Vous pouvez également utiliser d’autres options, comme severity-threshold=high, pour que Snyk n’interrompe la compilation que si vous introduisez des vulnérabilités de gravité high ou supérieure. Pour consulter la liste complète des options de ligne de commande prises en charge, reportez-vous à notre documentation Snyk pour C/C++.
Exemple de définition de pipeline Gitlab CI/CD
Corriger les problèmes
Pour corriger un problème, vous devez remplacer le code source du package open source contenant la vulnérabilité détectée par la version plus récente recommandée. Consultez les recommandations disponibles à l’URL du problème pour connaître la version dans laquelle la faille de sécurité de votre dépendance est corrigée.

Après la mise à jour du code source, deux cas de figure sont possibles :
Le problème disparaît : c’est terminé.
Le problème est toujours détecté, car la dépendance open source n’a pas été correctement identifiée.
Concernant le deuxième cas, cela s’explique par le fait que nous mettons à jour notre base de données open source avec les nouvelles versions chaque mois. Il est donc possible que la dernière version du package que vous venez d’ajouter à votre code n’y figure pas encore. Pour vérifier si Snyk a correctement identifié la dépendance et sa version, exécutez la commande test avec l’option --print-deps :
Notez que la métrique confidence mesure le degré de certitude de Snyk quant à la correspondance.
Quel niveau de confiance est satisfaisant ?
La réponse est : cela dépend. Le niveau de confiance correspond au ratio entre le nombre de fichiers locaux qui correspondent à une version publiée du projet open source et le nombre total de fichiers de cette version. Par exemple, si une version donnée d’un projet open source (le package contenant le code source) comprend 1 000 fichiers et que votre projet local en contient 900, tandis que les autres ne correspondent pas parce qu’ils ont été modifiés, le niveau de confiance est de 900/1 000 = 0,9. Cependant, le niveau de confiance est identique pour un projet open source comprenant 10 fichiers et dont 9 correspondent aux fichiers locaux, ce qui est très différent du premier exemple. À vous de décider quel niveau de confiance est suffisant et quelles identifications de dépendances vous souhaitez ignorer.
Si l’identification est incorrecte, vous pouvez utiliser la commande snyk ignore pour ignorer temporairement la dépendance :
L’avenir de l’analyse de sécurité C/C++
Nous travaillons à améliorer la précision de nos analyses en consacrant davantage d’efforts à la sélection des projets open source et en perfectionnant nos algorithmes de correspondance, afin de prendre en compte les projets dont le code a été légèrement modifié (ou dont les tests et la documentation ont été supprimés). Nous prévoyons notamment de mettre à jour plus fréquemment notre base de données de code source et d’ajouter des projets qui ne disposent pas de versions publiées.
En complément de la détection des composants C++ en mode unmanaged (basée sur les signatures), nous développons une API qui vous permettra d’interroger directement notre base de données des vulnérabilités. Vous avez des commentaires ou souhaitez en savoir plus sur cette nouvelle API ? Contactez-nous à l’adresse ccpp@snyk.io.
Lancez-vous dans les compétitions Capture The Flag
Apprenez à résoudre des défis de capture du drapeau en regardant à la demande notre atelier virtuel d’initiation.
