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.
Traefik pour gérer les entrées.
SonarQube pour vérifier si le code source dissimule des vulnérabilités ou si le codage laisse à désirer.
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
Composant
Description
Plateforme en nuage de l’ATIR
Elle sert d’interface Web aux participants, en leur permettant d’accéder aux ressources gardées dans le nuage et de les gérer.
K3s
Version allégée de Kubernetes proposée par la Cloud Native Computing Foundation (CNCF). K3s a les mêmes fonctionnalités que Kubernetes, mais se prête mieux aux systèmes dont les ressources sont limitées.
Gestionnaire de code source (GCS)
Logiciel employé par les développeurs pour suivre les modifications apportées au code source. Subversion et Git en sont des exemples populaires.
Jenkins
Outil d’automatisation de source ouverte dont l’organisation pourra se servir pour configurer l’intégration et le déploiement de ses logiciels en continu.
SonarQube
Outil de source ouverte vérifiant le code source dans différents langages de programmation afin d’en déceler les vulnérabilités et d’aider l’organisation à améliorer ses méthodes de développement.
Zaproxy
Produit DAST de source ouverte abondamment employé pour détecter les vulnérabilités des applications Web en fonction des vulnérabilités les plus fréquentes recensées par l’Open Web Application Security Project (OWASP).
Ce que vous devriez avoir fait avant de déployer la solution type
Avoir créé une règle de groupe de sécurité vous permettant d’accéder aux machines virtuelles (MV) du Nuage de l’ATIR à partir de l’adresse IP utilisée, par le protocole SSH (port 22 du protocole TCP).
Avoir créé la paire de clés SSH (biclé) avec laquelle vous vous connecterez à vos MV de l’ATIR.
Pour déployer la solution type, les participants de l’ATIR n’ont qu’à suivre les étapes décrites ci-dessous.
Pour déployer la solution type, les participants de l’ATIR n’ont qu’à suivre les étapes décrites ci-dessous.
Connectez-vous à votre compte AWS de l’ATIR en suivant les instructions que vous a fournies l’équipe de l’ATIR.
Ouvrez une autre fenêtre dans le navigateur et rendez-vous sur la page du Catalogue des Propulseurs de l’ATIR puis à la section de Parabelllyx (Analyse statique et dynamique automatisée de la sécurité des applications) et cliquez DÉPLOYER pour lancer le Propulseur avec la pile AWS Cloudformation.
Remplir le formulaire de configuration
Cliquez Suivant pour passer à la deuxième étape de Cloudformation et remplissez le formulaire de configuration. Dans le champ InstanceName, donnez un nom unique à l’instance de votre serveur d’application, puis complétez le formulaire avec les menus déroulants.
Veuillez noter que certains paramètres comme ApplicationImage et InstanceType sont déjà configurés et ne peuvent être modifiés.
Cliquez SUIVANT pour passer à la troisième étape de CloudFormation. Cette partie concerne la configuration d’options avancées ou supplémentaires, inutiles dans le cas qui nous intéresse. Cliquez simplement Suivant au bas de la page pour sauter cette étape et passer à la quatrième et dernière de CloudFormation.
La dernière partie vous permet de vérifier la configuration actuelle du Propulseur et d’y apporter des modifications avec le bouton Modifier, si vous le désirez. Une fois que la configuration vous convient, cliquez Soumettre, au bas de la page, pour déployer le Propulseur.
Le déploiement commence par la création d’une nouvelle instance. Le reste est automatique. Suivre le développement de l’instance AWS n’est possible qu’avec les onglets Événements et Ressources de la console CloudFormation. Pour vérifier l’avancement du déploiement, vous devrez donc vous connecter au serveur de l’application.
Notez l’adresse IP qui apparaît sur l’onglet Sorties de la page CloudFormation du Propulseur. Il s’agit de l’adresse IP externe de l’instance qui vient d’être créée. Vous en aurez besoin pour accéder à l’interface web de l’application ou vous connecter au serveur par le protocole SSH.
Connectez-vous au serveur de l’application à partir d’une coquille ou d’un terminal utilisant le protocole SSH avec la commande suivante :
ssh -i key_file.pem ubuntu@IP
Remplacez « key_file » par la clé privée de la biclé SSH choisie sur le formulaire des paramètres de configuration de la console CloudFormation et remplacez « IP » par l’adresse IP fournie, que vous avez précédemment notée.
Une fois la connexion avec le serveur de l’application établie, vous pourrez suivre le déploiement du script d’automatisation avec les commandes que voici :
source /etc/profile.d/boosterpack.sh
tail -f /var/log/boosterpack.log
Le déploiement dure en moyenne sept à dix minutes.
Pendant ce temps…
Allez à la page de configuration des groupes de sécurité dans AWS afin d’ajouter des règles entrantes au groupe de sécurité par défaut sélectionné lors du paramétrage de la console CloudFormation.
Assurez-vous que le groupe de sécurité choisi pour cette MV comprend des règles entrantes qui donneront accès au port 22 (SSH), au port 80 (HTTP) et au port 443 (HTTPS) à partir de votre adresse IP externe, afin que vous seul puissiez accéder à la MV.
Pour vérifier si l’orchestration s’est bien déroulée, exécutez la commande qui suit pendant que vous êtes connecté au serveur de l’application :
sudo kubectl get po -A
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 :
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’ :
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.
Pour cela, copiez les deux premières lignes ci-dessous.
Ensuite, collez la commande sonar-scanner (que vous avez sauvegardée dans un fichier-texte à la partie « Création d’un projet SonarQube ») directement en-dessous, de la façon indiquée plus bas.
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…
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é
On devrait limiter l’accès à une plage d’adresses IP précise. Songez à créer un groupe de sécurité <lien vers la vidéo > qui s’appliquera à cette solution. Ne devrait s’y trouver que les adresses IP approuvées.
Assurez-vous que les mots de passe employés avec SonarQube, Jenkins et Keycloak respectent les pratiques exemplaires les plus récentes de la profession. Ils devraient compter plus de 14 caractères et comprendre des majuscules, des caractères spéciaux et des chiffres.
Les données des conteneurs PersistentVolumeClaims (PVC) de Kubernetes sont installés sur /var/lib/rancher/K3s/storage/<dynamic-value>/. Des données non chiffrées pourraient se retrouver le long de ce chemin, selon la méthode employée par l’application ou le conteneur. Appliquez la bonne liste ACL aux utilisateurs qui auront accès au compte afin que les fichiers du PVC ne puissent être consultés accidentellement. Utilisez toujours les fonctionnalités de chiffrement de l’application, s’il y en a.
Le certificat HTTPS par défaut fourni par Traefik dans la solution type entraînera l’affichage d’un avertissement du genre « la connexion n’est pas privée » sur la majorité des navigateurs quand vous essayerez d’accéder aux applications hébergées sur l’instance de l’ATIR (à savoir, Jenkins). Sur une plateforme de production, vous devriez d’abord obtenir et installer un certificat HTTPS valide pour l’application Web.
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.
