Solution type : déploiement rapide de l’analyse statique de la sécurité des applications (SAST)

Introduction

La solution type montre comment Parabellyx utilise Jenkins/SonarQube avec Kubernetes pour déceler les vulnérabilités dans les logiciels de l’organisation en intégrant des essais de sécurité statiques (SAST) ou dynamiques (DAST) à son pipeline de développement. La solution est divisée en deux : la première partie illustre comment configurer l’analyse SAST et la seconde, comment configurer les essais dynamiques (DAST), plus complexes. L’analyse DAST automatise les essais de sécurité sur une application Web après son déploiement.

Problématique

Comme on peut le lire dans le Plan de vol, les vulnérabilités d’un logiciel peuvent rendre une infrastructure capitale inutilisable ou exposer des données confidentielles ou personnelles. En adoptant des mesures pour détecter les vulnérabilités quand débute le développement du logiciel, on atténuera les risques très coûteux associés au piratage d’une application.

Le projet Argus est un système allégé qui crée rapidement les outils permettant d’intégrer la vérification du code source au moyen d’essais statiques et les applications déjà été déployées sur le Web au moyen d’essais dynamiques. Grâce à cette solution de source ouverte, l’organisation apprendra comment intégrer l’analyse SAST/DAST à son processus de développement sans avoir à acheter une des solutions SAST/DAST proposées sur le marché. En raison de sa nature modulaire, le projet Argus laissera à l’organisation la liberté de choisir la solution SAST/DAST complète ou une partie de celle-ci.

SAST diagramme

Le schéma ci-dessous illustre la structure de la solution type.

Structure de la solution type SAST

La solution complète (analyses SAST et DAST) est déployée sur l’instance d’une machine virtuelle dans le nuage de l’ATIR. Cette instance utilise K3s, version allégée de Kubernetes, pour gérer les trois applications nécessaires au fonctionnement de la solution SAST.

  1. Traefik pour gérer les entrées.
  2. SonarQube pour vérifier si le code source dissimule des vulnérabilités ou si le codage laisse à désirer.
  3.  Jenkins pour automatiser l’extraction du code source, sa vérification et la transmission des résultats à SonarQube.

The SAST La solution SAST sera configurée pour vérifier le code source de l’application servant d’exemple, gardée dans un dépôt (p. ex., Github, GitLab ou BitBucket).

Composant

Déploiement et configuration

Pour déployer la solution type, les participants de l’ATIR n’ont qu’à suivre les étapes décrites ci-dessous.

1. Allez à https://cloud.canarie.ca/login/auth et ouvrez une séance sur le tableau de bord Morpheus en vous servant des identifiants fournis par l’équipe de l’ATIR.

2. Dans le coin supérieur droit de l’écran, où figure le nom du compte, cliquez la flèche du menu déroulant et sélectionnez SERVICE CATALOG sous PERSONA.

3. Cherchez Parabellyx-Project Argus Blueprint et cliquez ORDER.

Remplir le formulaire de configuration

1. Dans le premier champ, inscrivez le nom unique d’une instance de l’application et remplissez le reste du formulaire. Ensuite, cliquez ORDER NOW pour déployer l’application.

Le déploiement créera une nouvelle instance avant l’automatisation. Pour accéder à l’application (et voir comment progresse le déploiement), vous devrez revenir à la persona STANDARD.

2. Revenez au tableau de bord de la persona Standard en cliquant la flèche du menu déroulant à côté du nom du compte (en haut, à droite) et en sélectionnant STANDARD.

3. Cela fait, allez à Provisioning > Apps et cliquez l’application qui vient d’être déployée. Le déploiement dure sept à dix minutes, en moyenne.

4. Entre-temps, allez à la configuration des groupes de sécurité dans Infrastructure > Network > Security Groups.

Assurez-vous que les règles du groupe de sécurité retenu pour cette machine virtuelle (MV) autorise les accès par SSH (port 22), HTTP (port 80) et HTTPS (port 443) à partir de votre adresse IP externe afin que vous soyez le seul à pouvoir le faire. <lien menant à l’ajout d’une règle de sécurité >

Vérification de l’état de la MV

1. Rendez-vous à l’écran Provisioning > Instances.

2. Une fois que le serveur est opérationnel (comme l’indique la flèche verte), déterminez son adresse IP sur la liste des MV énumérées dans INSTANCES.

Ici, la MV d’Argus utilise l’adresse IP externe 3.97.188.167 (vous n’aurez pas la même; notez-la car vous en aurez besoin plus tard).

Connectez-vous à la MV d’Argus par SSH pour vous assurer que l’orchestration a bien fonctionné.

3. Après avoir ouvert une séance sur le serveur, exécutez la commande que voici :

sudo kubectl get po -A

Trois blocs devraient avoir le statut Running sous l’espace de nommage appsec.

Félicitations! Vous n’êtes plus qu’à un pas du déploiement de la solution SAST/DAST.

Configuration et lancement de l’application

Ouvrez une séance sur SonarQube pour créer un projet qui gèrera les méthodes de codage et les vulnérabilités.

Ensuite, ouvrez une séance dans Jenkins pour créer le pipeline qui établira la communication avec le gestionnaire de code source et configurera Jenkins.

Configuration de SonarQube

1. Accédez au tableau de bord de SonarQube en suivant le lien https://[adresse.ip.externe]/sonar (https://3.97.188.167/sonar dans notre exemple).

Si vous n’avez pas de certificat HTTPS valide, un avertissement signalera l’existence d’un risque sur le plan de la sécurité. Pour l’instant, vérifiez simplement que l’URL est le bon et poursuivez en vous rendant sur la page Web.
2. Saisissez « admin » et « admin » comme identifiants pour SonarQube.

3. Modifiez le mot de passe par défaut.


4. Lorsque vous aurez actualisé le mod de passe, vous verrez s’afficher une page énumérant les possibilités d’intégration pour la plateforme DevOps ou vous permettant de configurer le projet manuellement.

Nous vous conseillons maintenant de créer un autre utilisateur que l’administrateur.

5. Cliquez Administration dans le menu supérieur, puis le menu déroulant Security et sélectionnez Users.

6. Cliquez Create User dans le coin supérieur droit. Pour la solution type, nous baptiserons cet utilisateur « developer1 ».

Pour le reste, nous utiliserons le compte developer1. La configuration de Jenkins peut maintenant débuter.

Configuration de Jenkins

1. Ouvrez un nouvel onglet dans le navigateur et rendez-vous à https://[adresse.ip.externe]/jenkins (remplacez [adresse.ip.externe] par l’adresse IP externe de la MV d’Argus notée plus tôt).

2. Pour récupérer le mot de passe Admin par défaut de Jenkins, revenez à la console de la MV Argus (séance SSH) et exécutez la commande suivante :

sudo kubectl exec -it --namespace=appsec $(sudo kubectl get pods --namespace=appsec | awk '/jenkins/ {print $1}') -- cat /var/jenkins_home/secrets/initialAdminPassword

sudo kubectl exec -it --namespace=appsec $(sudo kubectl get pods --namespace=appsec | awk '/jenkins/ {print $1}') -- cat /var/jenkins_home/secrets/initialAdminPassword

Dans notre exemple, le mot de passe commence par 9954f…

3. Copiez la séquence et collez-la dans le champ du mot de passe de l’administrateur.

4. Cela fait, cliquez Install suggested plugins. Cette opération installera les modules d’extension de base de Jenkins.

5. Ensuite, créez un compte Admin.

6. Cliquez Save and Continue.

Nous préconisons d’utiliser la valeur par défaut pour configurer l’instance. Assurez-vous que l’URL de Jenkins comprend l’adresse IP externe précise de la MV.

7. Pour terminer la configuration, cliquez Start using Jenkins.

Création d’un compte utilisateur Jenkins

1. Cliquez Manage Jenkins dans le panneau de gauche, puis Manage Users sous la rubrique Security.

2. Cliquez Create User dans le panneau de gauche et remplissez les cases de saisie.

Ici, nous créerons un compte pour developer1. Par la suite, la solution type se servira de developer1 dans Jenkins.

La configuration de SonarQube et de Jenkins est terminée.

Démonstration de la technologie

Analyse SAST (essais statiques)

Cette partie montre comment fonctionnent les essais statiques (SAST) d’Argus. La solution accélère l’intégration de l’analyse statique au flux de tâches de l’équipe de développement. Parallèlement, elle s’assure que l’intégration n’entrave pas les opérations en cours et qu’on peut aisément revenir en arrière.

La solution type illustre l’application des essais statiques à un projet situé dans le dépôt de codes sources de l’organisation. Aux fins d’illustration, nous utiliserons l’application Damn Vulnerable Web Application (DVWA), une application défectueuse incluant de nombreuses vulnérabilités. Son code se trouve dans un dépôt public Github que vous devriez cloner dans votre propre dépôt Git avec la commande suivante :

git clone https://github.com/digininja/DVWA.git

Création d’un jeton d’accès personnel dans Github

Si vous avez publié le clone du dépôt DVWA comme un dépôt privé dans votre compte GitHub, Jenkins devra d’abord s’authentifier pour accéder au code. Si le dépôt DVWA a été publié dans un dépôt public de GitHub, sautez cette étape et rendez-vous directement ici

1. Créez un jeton d’accès personnel sur votre profil Github.

2. Dans Select scopes, cliquez la case à côté de repo, et parcourez la liste jusqu’en bas puis cliquez Generate token.

3. Sauvegardez le jeton en lieu sûr. Vous en aurez besoin plus tard pour la configuration.

Création d’un projet SonarQube

1. Ouvrez une séance dans SonarQube avec le compte developer1 et sélectionnez Manually pour créer un nouveau projet.

2. Saisissez un nom évocateur pour Project display name et Project key. Pour notre exemple, nous utiliserons DVWA-dev. Cliquez Set Up pour continuer.

3. Bien qu’une méthode d’intégration soit proposée pour la plupart des pipelines populaires, nous vous suggérons de choisir Locally pour garder la plus grande latitude possible et éviter les pipelines dédiés. Néanmoins, n’hésitez pas à explorer les pipelines CI, si vous le désirez.

4. Saisissez une chaîne quelconque pour produire un jeton et cliquez Generate. Lorsque vous aurez la clé, cliquez Continue.

5. DVWA étant une application PHP, sélectionnez Other pour le langage de programmation, puis Linux.

Un encadré s’affichera avec une commande sonar-scanner que l’interpréteur Linux exécutera sur le pipeline CI (Jenkins).

Attention : sauvegardez le contenu des commandes sonar-scanner dans un fichier-texte temporaire, car vous en aurez besoin plus tard.

Ceci termine la configuration du projet dans SonarQube.

Création d’un pipeline Jenkins

1. Ouvrez une séance sur l’application Web Jenkins sous le nom developer1.

2. Dans le menu principal, cliquez Create a job pour voir la page énumérant les projets. Saisissez dvwa-sast comme Item name et sélectionnez Freestyle project, puis cliquez OK.

3. Dans Source Code Management, sélectionnez Git et saisissez l’URL du dépôt.

4. Si vous utilisez un dépôt privé, Jenkins ne pourra accéder au code source sans jeton. Configurez l’accès en cliquant Add directement sous Credentials puis en sélectionnant Jenkins.

5. Sur l’écran Credentials Provider de Jenkins, sous Kind, sélectionnez Username with password dans le menu déroulant.
6. Saisissez votre identifiant GitHub et le jeton que vous avez créé plus tôt comme mot de passe. Ensuite, cliquez Add.

7. Sous Credentials, sélectionnez votre compte GitHub. Le message d’authentification du dépôt devrait disparaître.

Remarque : il se peut que Jenkins aille à l’embranchement principal (’master’) par défaut pour vérifier le pipeline. Il arrive toutefois que des organisations troquent le terme ‘master’ pour ‘main’, donc assurez-vous de choisir le bon Branch Spécifier.

8. Les Build Triggers facilitent l’automatisation du pipeline au démarrage. Pour la solution type cependant, nous lancerons le pipeline manuellement. Donc, ne cochez aucune case.

9. Pour Build Environment, mieux vaut cocher Delete workspace before build starts afin d’éliminer tous les éléments qui pourraient subsister des réalisations antérieures. Ne cochez aucune autre option.

10. Deux étapes supplémentaires sont requises avant qu’on puisse passer aux essais statiques. La première consiste à lancer Execute shell.

11. Insérez le code suivant dans le champ ‘Command’ :

# Download sonar-scanner

mkdir -p $WORKSPACE_TMP

curl -o $WORKSPACE_TMP/sonar-scanner-cli-4.6.2.2472-linux.zip https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-4.6.2.2472-linux.zip echo "9411331814c1d002bd65d37758b872918b7602e7cf3ca5b83a3e19a729b2be05 $WORKSPACE_TMP/sonar-scanner-cli-4.6.2.2472-linux.zip" | sha256sum --check unzip -o $WORKSPACE_TMP/sonar-scanner-cli-4.6.2.2472-linux.zip -d $WORKSPACE_TMP/sonar-scanner

Grâce à lui, vous téléchargerez sonar-scanner-cli et pourrez vérifier l’intégrité du fichier. sonar-scanner effectue l’analyse de sécurité et en transmet les résultats au serveur SonarQube que vous avez déployé.

12. Exécutez une deuxième fois la commande Execute shell avec la version.

Remarque : n’utilisez PAS la commande sonar-scanner qui apparaît dans l’encadré, car l’adresse IP de votre sonar.host.url et les valeurs de sonar.login ne seront pas les mêmes.

# Run scan export PATH=$WORKSPACE_TMP/sonar-scanner/sonar-scanner-4.6.2.2472-linux/bin:$PATH
# Insérez la commande sonar-scanner que vous avez sauvegardée ici…
sonar-scanner \   -Dsonar.projectKey=DVWA-dev \   -Dsonar.sources=. \   -Dsonar.host.url=http://3.97.188.167/sonar \   -Dsonar.login=ec435d2f7f35433aba183cb873a264c9e219aaa5

Attention : utilisez http, pas https, pour l’argument -Dsonar.host.url.

13. Cliquez Save. Le navigateur reviendra à l’écran du projet.

Essai statique (SAST)

Maintenant que la configuration est terminée, le moment est venu de vérifier si tout fonctionne!

1. Cliquez Build Now pour lancer le pipeline.

L’état de la version apparaîtra dans ‘Build History.’ Au début, nous avions commis une erreur de configuration dans Git qui renvoyait à un embranchement inexistant. Pour en savoir plus sur ce problème, qui a entraîné l’échec de l’application, cliquez la version numérotée à côté du x rouge.

2. Cliquez Console Output pour résoudre le problème.

Le produit « Console Output » correspond au résultat obtenu après l’exécution des lignes de programmation dans le pipeline. Ici, on constate que Git a été convoqué mais que l’embranchement principal (‘master’) n’a pu être découvert (étape n° 13). Continuez de réviser la configuration du projet quand des erreurs surviennent. Relancez le processus ‘Build now’ jusqu’à ce que tout fonctionne.

Une fois que la version fonctionne…

3. Revenez au tableau de bord SonarQube (https://[adresse.ip.externe]/sonar) et cliquez le projet. Vous devriez obtenir une liste de ce qui a été découvert (illustration ci-dessous).

4. Cliquez l’onglet Security Hotspots pour savoir comment corriger l’application.

Analyse des résultats

1. Pour l’application DVWA, développez la liste SQL Injection et choisissez la première mention afin de l’examiner.

2. Déterminez la nature et la gravité de la vulnérabilité.

3. Étudiez le fragment de code pour savoir s’il s’agit d’un vrai positif ou d’un faux négatif.

4. Dans le premier cas, SonarQube propose trois onglets d’information qui vous aideront à comprendre la vulnérabilité et à savoir comment l’atténuer ou l’éliminer.

Conclusion

Sur l’écran Provisioning > Instances, cochez la boîte à côté de Project-Argus VM et sélectionnez Delete dans le menu déroulant ACTIONS.

Quand l’ordinateur le demande, cochez les options Force Delete et Release EIP. Cliquez Delete pour supprimer la machine virtuelle.

Considérations

Autres possibilités de déploiement

Le projet Argus a été élaboré sur la plateforme Kubernetes, plus précisément K3s. Les fichiers YAML nécessaires à son déploiement se trouvent dans le dépôt Git du projet et /opt/Argus. Argus a été conçu pour n’être déployé que sur une seule MV. Les participants de l’ATIR pourront se servir des fichiers YAML pour déployer Kubernetes dans le nuage de l’ATIR ou sur leur propre ordinateur. La solution type utilise Kustomize pour faciliter l’adaptation de la solution.

Pour l’analyse dynamique (DAST), nous avons utilisé la version Windows. Le dépôt Git contient un script pour l’interpréteur Linux et un fichier Jenkins exploitable sur la plateforme Linux ou un processus CI.

Technologies de rechange

Autres pipelines CI

Les échantillons de code du pipeline ont été rédigés dans un format adapté aux interpréteurs. L’organisation qui a son propre exécuteur de pipeline pourra réutiliser les scripts de l’interpréteur. Assurez-vous d’installer un certificat HTTPS valide avec la solution type pour que sonar-scanner puis se connecter au serveur SonarQube situé dans la grappe Kubernetes.

Autres produits SAST

Nous avons examiné d’autres produits SAST proposant autant de fonctionnalités que la solution type. Bien que ces produits exigent l’hébergement du projet dans un dépôt public ou la rémunération du service, en voici quelques-uns dont on pourrait se servir sur-le-champ pour profiter de certaines fonctionnalités SAST

Bandit

Bandit analyse le code python pour détecter les problèmes de sécurité courants. On pourra l’utiliser à la place de SonarQube dans le pipeline Jenkins et le stocker grâce à la fonction « artifacts » de Jenkins. Cet outil fonctionne aussi sur les plateformes de développement quand on ne souhaite pas centraliser la solution SAST.

Flawfinder

Flawfinder vérifie le code source C/C++ et signale les erreurs éventuelles. À l’instar d’autres outils similaires, Flawfinder fonctionne sur le pipeline Jenkins et ses résultats sont enregistrés dans le répertoire « artifacts » pour examen ultérieur.

npm

Utiliser npm avec le signal « vérification » fera ressortir les paquets présentant des vulnérabilités. Les résultats de la vérification pourront ensuite être exportés et sauvegardés avec les fonctions « artifacts » de Jenkins lors des étapes suivant la réalisation de la version. Si vous préférez ne pas envoyer de code à une solution SAST centrale, vous pouvez lancer npm sur votre ordinateur.

Sécurité

Réseautique

Utiliser Zaproxy dans le nuage en prenant pour cible une adresse IP publique engendrera du trafic sortant ou externe que pourrait couvrir la tranche gratuite de l’entente conclue avec le fournisseur. Si ce n’est pas le cas, des frais pourraient s’ensuivre. Vérifiez l’emplacement de l’application Zaproxy d’après l’application Web visée. Certain dispositifs de contrôle du réseau pourraient considérer les activités de Zaproxy comme malveillantes. Les conseils usuels en matière de sécurité veulent qu’on vérifie la politique du fournisseur de services d’infonuagique pour savoir s’il autorise l’analyse des applications avant d’en effectuer une.

Évolution

La solution type utilise la MV la plus légère possible. Si on analyse de nombreux projets, la durée des essais SAST pourrait s’allonger. Commencez par une mise à l’échelle verticale en ajoutant des cœurs de processeur et de la mémoire. S’il y a engorgement, envisagez une expansion horizontale comme la définit K3s.

Une expansion horizontale de K3s suppose l’aménagement d’un nouveau nœud et sa connexion à la grappe. Modifiez les fichiers de déploiement YAML pour accroître le nombre de répliques. N’oubliez pas que chaque application a sa propre méthode de mise en grappe.

Disponibilité

Lisez la partie sur l’expansion horizontale ci-dessus. Un problème pourrait survenir si les charges sont équilibrées dans un nœud. Il se pourrait qu’on doive déplacer l’équilibreur dans un autre système.

API

Les technologies employées par la solution type renferment toutes un Webhook ou une API REST. Assurez-vous qu’un groupe de sécurité empêche les utilisateurs non autorisés d’accéder à ces API durant le déploiement.

On peut se servir des API REST pour créer un tableau de bord central qui améliorera les rapports dans l’organisation et permettra de voir tous les résultats relatifs à la sécurité des projets sur une seule page.

L’API de Zaproxy a de nombreuses fonctionnalités qui vous permettront d’effectuer la plupart des tâches de l’interface utilisateur en passant par elle. Plus d’information à ce sujet sur : https://www.zaproxy.org/docs/api/ .

Licences d’exploitation

Le tableau ci-dessous indique les licences d’exploitation des applications utilisées par la solution type.

Codes de lancement

Les fichiers YAML servant à déployer le projet Argus se trouvent dans notre dépôt GitHub : https://github.com/parabellyx/Argus-infra

On trouvera le conteneur Jenkins modifié renfermant Zaproxy ici :
https://github.com/parabellyx/docker-jenkins

Le code source de l’analyse dynamique (DAST) et ses solutions se trouvent dans le dépôt GitHub :
https://github.com/parabellyx/dast-nocode

Glossaire

Voici une liste des abréviations qu’on retrouve dans le document et leur définition.

Solution DAST

Pour en savoir plus sur l’analyse dynamique de la sécurité d’une application (DAST), lire la deuxième partie de la solution : Solution type : déploiement rapide de l’analyse dynamique de la sécurité des applications (DAST)