Configuration des modules du scanner BoostSecurity avec votre intégration continue (CI)¶

BoostSecurity, grâce à une approche modulaire, prend en charge un grand nombre de scanners spécialisés, permettant l'automatisation de la sécurité pour plusieurs types de sécurité, tels que

Par conséquent, BoostSecurity permet d'intégrer l'automatisation de la sécurité dans les flux de développement pour de nombreux langages de programmation et écosystèmes.

Vous pouvez facilement ajouter le scanner BoostSecurity et commencer à analyser votre code source et les artefacts associés en utilisant l'un de nos plugins d'intégration continue (CI) officiellement pris en charge :

Si vous utilisez un autre système d'intégration continue (CI), vous pouvez utiliser la CLI (interface en ligne de commande) de BoostSecurity pour configurer le flux de travail, comme indiqué dans les instructions pour Jenkins.

Exigences minimales du système¶

Les exigences minimales du système pour exécuter manuellement (c.-à-d. pas via ZTP (Zero Touch Provisioning)) le scanner BoostSecurity dans un environnement CI sont les suivantes :

Les binaires suivants doivent être installés : git, find, tar et curl ou wget.
La machine qui exécute le binaire du scanner BoostSecurity doit soit ne pas disposer de glibc, soit disposer d'une version de glibc 2.28 ou plus récente.

Authentification du scanner auprès du service BoostSecurity¶

Un jeton API doit être configuré pour permettre au scanner BoostSecurity de téléverser les résultats. Pour cela, vous devez d'abord générer une clé API en visitant la page Paramètres > Clés d'application du tableau de bord BoostSecurity.

Une fois la clé API obtenue, nous vous recommandons d'utiliser le système de gestion des secrets natif de votre environnement d'intégration continue (CI). Le nom que nous suggérons est BOOST_API_TOKEN. Nous ferons référence à ce secret dans les exemples ci-dessous.

Quels pipelines sont pris en charge pour chaque application de gestion du code source¶

La compatibilité technologique de BoostSecurity, en termes de pipelines pris en charge pour chaque système de gestion de code source (SCM), diffère selon chaque système SCM.