Introduction

Aujourd’hui dans ce billet, je vais vous présenter des outils Opensource d’analyse SCA et SAST, qu’on peut intégrer dans son environnement de développement et sa chaîne d’intégration continue.

Pour rappel, SCA est l’acronyme de Software Component Analysis, et englobe les outils qui permettent d’analyser et de détecter les failles de sécurité dans les dépendances utilisées par notre application. Pour cela, ces outils vont se référer à une base de données CVE (Common Vulnerabilities and Exposures), mise à jour régulièrement, afin d’identifier les composants opensource compromis ou vulnérables.

SAST est l’acronyme de Static Application Security Testing, et comprend les outils et les technologies conçues pour vérifier la présence de failles et de vulnérabilités dans le code source de l’application. On y trouve par exemple des possibilités d’injection SQL ou des dépassements de mémoire tampon, que des acteurs malveillants peuvent exploiter.

À noter que certains de ces outils permettent d’analyser plusieurs langages, alors que d’autres vont se focaliser sur un seul type. De plus, il est intéressant de cumuler plusieurs outils SCA/SAST, pour identifier des failles de sécurité qui ne seraient par couvert par un seul outil.

SCA

En moyenne, 80% du code source provient des librairies qu’on intègre dans notre application.

Ces librairies sont susceptibles de contenir des failles de sécurité si elles ne sont pas mises à jour régulièrement. Utilisé dans un environnement de développement, et au début d’une chaîne d’intégration continue, un outil de type SCA va permettre d’analyser ce code afin de nous remonter ces failles de sécurité avant que l’application ne soit mise en production.

De plus, on va retrouver la même problématique concernant les images Docker, qui contiennent également des librairies pouvant contenir des failles de sécurité. Il est donc important de se doter d’outils qui vont pouvoir scanner ces images avant le déploiement de l’application.

Plateforme Gitlab/Github

Dans une plateforme telle que Gitlab ou Github, il est déjà possible d’intégrer directement des outils SCA sur un repository.

Pour Gitlab, la fonctionnalité Gitlab Dependency Scanning est disponible dans la version ultimate, ce qui implique un coût financier : https://docs.gitlab.com/ee/user/application_security/dependency_scanning/

Concernant Github, la fonctionnalité Github Dependency Track est gratuite, et le scan des dépendances est déjà activée sur les dépôts publics : https://github.com/DependencyTrack/dependency-track

Lorsqu’une faille de sécurité a été détectée dans les dépendances, l’utilisateur est notifié par un mail, ce qui permet d’identifier rapidement la librairie à mettre à jour dans son application.

Il existe d’autres solutions à intégrer sur ces plateformes, telles que Renovate, qui peut être une alternative à Gitlab Dependency Scanning : https://www.npmjs.com/package/renovate

Pour des petits projets, on pourra également utiliser l’outil Snyk Open Source, limité à 200 tests de projets OpenSource par mois, qui est un acteur majeur des outils de sécurité : https://snyk.io/plans/

Cet outil peut être intégré directement dans une plateforme comme Gitlab.

Voir un exemple

Solutions multi-langages

Il existe différentes solutions Opensource sur le marché qui permette de scanner plusieurs langages dans le code source de notre application. Les plus connus étant :

OpenSCA
OSS Review Toolkit (ORT)
OWASP Patton

On pourrait aussi utiliser la plateforme Dependancy Track, qui permet de visualiser les rapports dans un tableau de bord, et d’être alerté sur des plateformes de notification telles que Teams ou Slack : https://github.com/DependencyTrack/dependency-track

On pourra en parallèle rechercher les librairies impactées par ces failles de sécurité sur la plateforme : https://libraries.io/

Solutions mono-langage

Pour chaque langage de programmation, on va retrouver également des outils de scan de failles de sécurité, qu’on pourra cumuler avec les outils mentionnés au-dessus. Ces outils sont soit déjà fournis avec le framework, soit mis à disposition par la communauté.

Ci-dessous une liste des outils SCA, catégorisés par langage de programmation.

OutilLangageSource
DependencyCheckJAVAhttps://github.com/jeremylong/DependencyCheck
PHP Security CheckerPHPhttps://github.com/fabpot/local-php-security-checker
SafetyPythonhttps://github.com/pyupio/safety
NPM AuditJavascript/Typescripthttps://docs.npmjs.com/cli/v8/commands/npm-audit
Retire.jsJavascript/Typescripthttps://github.com/retirejs/retire.js/
yarn auditJavascript/Typescripthttps://classic.yarnpkg.com/lang/en/docs/cli/audit
bundler-auditRubyhttps://github.com/rubysec/bundler-audit
govulncheckGohttps://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
dotnet CLI.NEThttps://devblogs.microsoft.com/nuget/how-to-scan-nuget-packages-for-security-vulnerabilities/
docker-scan-pluginDockerhttps://docs.docker.com/engine/scan

SAST

Tout comme les librairies, il est devenu indispensable d’analyser le code source d’une application avant le déploiement en production. Que ce soit dans un IDE ou dans une chaîne d’intégration continue, cela permet d’identifier en amont de potentielles failles de sécurité qui pourrait être exploité par un attaquant.

Les outils SAST vont analyser l’application en la transformant dans un format AST (Abstract Syntax Tree). Pour en savoir plus, vous pouvez consulter cet article du blog de Conserto.

Lire l’article

Plateforme Gitlab

À partir de la version 13.3, Gitlab fournit gratuitement un template de sécurité (GitLab SAST) qu’on peut utiliser dans le .gitlab-ci.yml de son projet. En fonction du langage de l’application, le template utilise l’outil d’analyse qui correspond à celui-ci.

Voir la documentation

Exemple de fichier gitlab-ci.yml :

sast:
  stage: test
include:
  - template: Security/SAST.gitlab-ci.yml

Exemple de rapport généré :

Plateforme Github

Sur la plateforme Github, l’analyse du code source est effectué automatiquement sur les projets publics, avec CodeQL.

Pour les projets privés, cette action est à faire manuellement, cette documentation décrit la procédure à suivre pour intégrer CodeQL à son projet :

Voir la documentation

À noter qu’il est possible d’intégrer d’autres outils d’analyse, procédure décrite dans la documentation ci-dessus.

Exemple de rapport généré par la plateforme GitHub :

SonarQube

SonarQube, outil d’analyse du code source utilisée dans une chaîne d’intégration continue, dispose aussi de fonctionnalités SAST gratuites dans la version Community : https://www.sonarqube.org/features/security/

Cet outil est un bon complément avec les outils fournis par les plateformes Gitlab et Github, et dispose de plugins qu’on peut intégrer dans son IDE.

Snyk code

Dans sa version gratuite, limitée à 200 tests de projets OpenSource par mois, Snyk Code est également un bon complétement, et est intégrable dans une chaîne d’intégration continue.

Tout comme SonarQube, cet outil dispose par ailleurs de plugins à intégrer dans son IDE (Jetbrains, VS Code, Eclipse, Visual Studio) : https://snyk.io/product/snyk-code/

Outils SAST-IACS

Pour des projets de type Infrastructure As Code (IAC), il existe aussi des outils d’analyse OpenSource pour identifier des vulnérabilités dans le code.

KICS

Outil utilisé par Gitlab dans son template SAST-IaC.gitlab-ci.yml, KICS permet d’identifier des failles de sécurité sur ces produits :

  • Ansible
  • AWS CloudFormation
  • Azure Resource Manager
  • Dockerfile
  • Google Deployment Manager
  • Kubernetes
  • OpenAPI
  • Terraform

À partir de la version 1.6, il est même possible d’identifier ces failles dans les ressources déployées d’un cluster Kubernetes : https://kics.io/

Kubesec

Comme son nom l’indique, Kubesec permet d’identifier des failles de sécurité de ressources Kubernetes en scannant les fichiers yml d’un projet.
Cet outil permet aussi de scanner des charts Helm, celui-ci contenant des ressources Kubernetes.

Checkov

Outil Python OpenSource, Checkov permet de scanner ces types de projet IAC :

  • Terraform
  • AWS Cloudformation
  • AWS SAM
  • Kubernetes
  • Helm charts
  • Kustomize
  • Dockerfile
  • Serverless
  • Bicep
  • OpenAPI
  • Azure Resource Manager

https://github.com/bridgecrewio/checkov

Snyk infrastructure-as-code

Snyk infrastructure-as-code dispose également de fonctionnalités IACS dans sa version gratuite, pour ces types de projet :

  • Terraform
  • AWS Cloudformation
  • Kubernetes
  • Azure Resource Manager

https://docs.snyk.io/products/snyk-infrastructure-as-code

CVE Database

Ci-dessous, une liste non exhaustive de base de données CVE (Common Vulnerabilities and Exposures).

Conclusion

Nous avons vu dans cet article les principaux outils OpenSource permettant d’analyser le code source de notre application à la recherche de failles de sécurité, avant sa mise en production.

Je ne peux que recommander d’intégrer ces outils dès le début du développement d’un projet, que ce soit dans son IDE ou la chaîne d’intégration continue. Cela permet de corriger les failles de vulnérabilités avant sa mise en production, ainsi que d’éviter de cumuler trop de correctifs à appliquer, ce qui pourrait être long et fastidieux à réaliser lorsque le développement est arrivé à un certain niveau de mûrissement.

De plus, je conseillerais de bloquer la CI dès lors qu’un warning est remonté, car ces failles ne seront peut-être jamais corrigées, dès lors qu’on considère que ce n’est pas bloquant pour la mise en production de l’application.

Conclusion, plus le niveau de granularité est élevé dans la CI sur ces outils, moins il existe de risques qu’un acteur malveillant exploite des failles de vulnérabilité dans notre application.

Sources

SCA

SAST

IAST

Vous avez besoin d’être accompagnés ?

Nos équipes sont à l’écoute !

Contactez-nous