3.34 Procédures-veille sécurité

3.34.1. - Projet Socle

Le projet Socle est paramétré pour fournir une liste des failles de sécurité associées à chaque dépendance Maven utilisée dans les sources.

/!\ Il est préférable de réaliser l’analyse à la suite d’une montée de version des principales librairies et des principaux framework ! (et non avant)

3.34.1.1 - Mettre à jour les dépendances Java

Les fichiers pom.xml, 2-code/front/pom.xml et 2-code/socle/pom.xml sont aménagés pour faciliter cette montée de version : en face de chaque propriété <version.xxxx> est placé le lien direct vers le site mvnrepository.com permettant de vérifier la dernière version disponible.

La montée de version consiste donc en :

• la modification de la version de chaque dépendance directe (depuis les fichiers pom.xml) pour utiliser la dernière version disponible ;
• la déconnexion de tout réseau nécessitant un proxy et leur désactivation (le téléchargement des dépendances sera plus rapide et celui de flapdoodle ne supporte pas les proxy)
• la compilation uniquement (-DskipTests -T 1C) de l’ensemble du projet (au besoin, utiliser Eclipse pour tout compiler après le premier échec et le téléchargement de la plus part des dépendances) ;
• la correction de toutes les nouveaux avertissements (notamment Deprecated)
• le build de l’ensemble du code ;
• la purge de tous les éléments du socle (logs, données de base de données et cache) avec l’outil . ./outils.sh depuis le répertoire 2-code/socle ;
• pour gagner du temps, recréer le fichier de cache du référentiel des SIRET (cf. §3.2.11)
• le démarrage de tous les composants applicatifs avec la commande . ./demarrerTout.sh depuis le répertoire 2-code/socle ;
• la vérification du bon démarrage de tous les composants applicatifs ;
• l’exécution des tests depuis UseBruno : suivre les étapes du chapitre règles de test des requêtes HTTP ;
• le démarrage des démarches compilées avec la commande npm run http-start depuis le répertoire 2-code/front ;
• l’exécution de tests manuels depuis les démarches ;
• l’arrêt de tous les composants applicatifs avec la commande . ./arreterTout.sh depuis le répertoire 2-code/socle ;
• la suppression de la précédente version de flapdoodle (.embedmongo/windows/mongodb-windows-x86_64-xxx.zip et embedmongo/Windows-B64–unknown—xxx) ;
• la mise à jour, dans le fichier 4.2quoi.md, des dates de l’actuelle et de la prochaine mise à jour des dépendances du socle ;
• la vérification des licences associées aux dépendances (cf. §3.34.5)
• le commit de la montée de version.

3.34.1.2 - Chiffrement / déchiffrement des mots de passe (ou clefs) dans les fichiers de configuration

Tout mot de passe ou clef de configuration doit être stocké(s) sous forme chiffrée. Pour cela il suffit :

• de démarrer (ou avoir déjà démarré) les services service-gateway et service-registry (nécessaires pour appeler les APIs exposées par service-config)
• de commenter, dans le fichier application-specifique.properties du projet service-config, les clefs spring.security.user.xx
• de commenter, dans le pom.xml du même projet, la dépendance à spring-boot-starter-security dans le pom.xml de service-config
• de démarrer le service service-config
• d’utiliser l’API http://localhost:xxxx/encrypt depuis l’IDE HTTP (UseBruno) pour chiffrer une valeur fournie dans le corps de la requête
• de placer cette valeur chiffrée dans le fichier de properties souhaité en la préfixant par {cipher}

A savoir :

• Pour déchiffrer une valeur, une API decrypt existe aussi.
• Pour créer le keystore, les étapes à suivre sont (ici) :
  • se placer dans un répertoire et ouvrir une ligne de commande
  • exécuter la commande keytool -genkeypair -alias clefDeTest -keyalg RSA -dname "CN=ServiceConfig,OU=Moi,O=Perso,L=Amiens,S=France,C=FR" -keystore service-config.jks -storepass MotDePasseStore
  • placer le fichier service-config.jks n’importe où et utiliser la clef cheminkeystore pour pointer sur le répertoire contenant le keystore (dans les sources, le keystore est présent dans le répertoire src/test/resources du projet service-config pour ne pas être embarqué dans le JAR exécutable)

3.34.2 - Projet Front

3.34.2.1 - Montée de version Angular

La mise à jour d’Angular est régulière car une version sort régulièrement. Elle est à réaliser de la manière suivante :

• avant la montée de version, vérifier que le projet front fonctionne en
  • exécutant un build complet npm run all-build-prod puis npm run all-postBuildProd-setOIDC
  • exécutant les tests npm run e2e vs npm run xx-start avec xx chacune des démarches
• ouvrir le site guidant chaque montée de version Angular
• si une nouvelle version majeure est disponible
  • sélectionner la version source (actuelle et donc présente dans le package.json) et la dernière version GA proposée sur le site
  • suivre les instructions fournies par le site en complément des commandes ci-dessous (potentiellement avant ou après)
    • ne pas exécuter la commande ng update ... de la procédure d’Angular (prévu plus bas)
    • en cas de besoin, le paramètre –allow-dirty de la commande ng update permet une exécution de la mise à jour sans devoir tout commiter
• dans une ligne de commande DOS, mettre @angular/cli à jour avec la commande npm install --save-dev @angular/cli
• pour réaliser la mise à jour, exécuter npm run update-angular
• vérifier que toutes les versions modifiées sont identiques entre elles sinon les harmoniser à la main (sauf @angular-builders*)
• installer les dépendances avec la commande npm install (normalement inutile)
• vérifier que le projet front fonctionne en
  • exécutant un build complet npm run all-build-prod puis npm run all-postBuildProd-setOIDC
  • exécutant les tests npm run e2e vs npm run xx-start avec xx chacune des démarches
• mettre à jour la page contenant la backlog et programmer la prochaine mise à jour pour le prochain trimestre

3.34.2.2 - Montée de version Angular compliquée

En cas de problème sur une montée de version, il est parfois nécessaire de recréer un projet de zéro pour avoir une référence et de traiter à la main les différences entre le projet de référence et le vrai projet.

Pour cela, il faut

• créer un nouveau workspace Angular avec une librairie et une application avec les commandes suivantes (source) :
  • se placer dans le répertoire /2-code et y ouvrir une ligne de commande DOS (pas gitBash car des questions sont posées et gitBash ne le supporte pas en 11/2022)
  • npm install --location=global @angular/cli@latest pour mettre à jour le CLI d’Angular (oui en NPM même si le reste du projet est en Yarn)
  • supprimer le répertoire existant /2-code/front-exemple
  • ng new front-exemple --create-application false pour créer une nouvelle application avec la dernière version disponible
  • cd front-exemple pour entrer dans le répertoire de la nouvelle application
  • ng generate library framework --skip-package-json true --skip-install true pour créer une librairie
  • ng generate application bibliotheque --routing false --skip-tests true --style scss --ssr false pour créer une application
  • npm install angular-oauth2-oidc espression ngx-logger font-awesome font-awesome-animation @gouvfr/dsfr @angular/material @angular/cdk --save pour ajouter les dépendances actuelles du projet
    • en cas de problème avec la commande à cause d’une dépendance de la librairie DSFR, essayer d’ajouter le paramètre --legacy-peer-deps
  • npm install @compodoc/compodoc @cypress/schematic cypress cypress-fail-fast cypress-html-validate html-validate ng-packagr npm-check-updates source-map-explorer @cypress/webpack-batteries-included-preprocessor @cypress/webpack-preprocessor @cypress/code-coverage http-server --save-dev pour ajouter les dépendances actuelles du projet
    • en cas de problème avec la commande à cause d’une dépendance de la librairie DSFR, essayer d’ajouter le paramètre --legacy-peer-deps
  • désinstaller le client Angular global avec la commande npm remove --location=global @angular/cli
• récupérer le contenu du projet actuel
  • supprimer le fichier README.md
  • dans le nouveau projet, supprimer les répertoires projects\framework\public, projects\bibliotheque\public, projects\framework\src et projects\bibliotheque\src
  • récupérer les 4 mêmes répertoires du projet actuel
  • récupérer aussi :
    • cypress.config.ts
    • projects\framework\cypress
    • projects\bibliotheque\cypress
• éditer le fichier angular.json pour
  • supprimer la balise architect > test et architect > extract-i18n
  • récupérer la balise architect > cypress-open
  • dans les assets du projet biliotheque, ajouter ,{"glob": "**/*","input": "projects/framework/public","output": "/public/"},{"glob": "**/*","input": "@gouvfr/dsfr/dist/favicon","output": "/dsfr/"}
  • dans les styles du projet biliotheque, ajouter ,"@gouvfr/dsfr/dist/dsfr/dsfr.min.css","@gouvfr/dsfr/dist/utility/utility.main.min.css","projects/framework/public/styles.scss"
  • dans les scripts du projet biliotheque, ajouter "@gouvfr/dsfr/dist/dsfr.module.min.js"
• éditer le fichier package.json pour
  • récupérer la balise author
  • récupérer les scripts install-1-cypress, install-2-cypress, bibliotheque-start et e2e
• tester ce projet
  • en installant Cypress avec les deux script d’installation
  • en démarrant la démarche avec la commande npm run bibliotheque-start
  • en lançant _Cypress _ et exécutant les tests avec la commande npm run e2e
• généraliser à tous les projets
  • importer le code de tous les projets
  • tester tous les projets avec les tests Cypress
  • relire les logs et vérifier les screenshots générés
• réaliser les tests spéciaux :

  • vérifier la bonne validation HTML des pages durant les tests E2E

    • en retirant la configuration spécifique du projet en commentant la partie configuration du code require('cypress-html-validate/plugin').install(on, {...}) dans le fichier cypress.config.ts
    • relançant les tests E2E sur le projet bibliotheque qui devrait échouer

  • tester les build-prod

    • exécuter un npm run all-build-prod
    • exécuter un npm run http-start
    • exécuter tous les tests E2E

  • tester la génération de la documentation

    • recopier les fichiers tsconfig.doc.json et le fichier tsconfig.doctest.json présents dans les répertoires de projet depuis l’ancienne arborescence vers la nouvelle
    • exécuter npm run all-compodoc
    • démarrer le serveur de documentation avec 1-conception\startServer.cmd
    • vérifier la présence et la qualité de la documentation depuis le site documentaire (lien dans le chapitre §3.1)

  • couverture de code avec les tests E2E

    • depuis la version Angular-18 (juillet 2024), l’instrumentation via les fonctionnalités de WebPack n’est plus possible (changement du builder Angular). Donc la couverture de code n’est plus possible pour le moment.

  • lignes de code (CLOC)

    • remettre en place les scripts cloc* dans le package.json
    • exécuter les deux commandes cloc* et en vérifier la cohérence manuellement

  • remettre Maven en place

    • à modifier :
      • récupérer le pom.xml et le répertoire assembly
    • pour tester :
      • exécuter la commande mvn clean install
      • exécuter la commande mvn clean install -P qualimetrie

  • tester le build Maven nominal /!\ retirer le fichier de conf et le bouchonAPI du ZIP généré par Maven

  • tester le build Maven nominal avec le profile qualimetrie

Pour vérifier que cela fonctionne, exécuter les commandes :

• de build de la démarche bibliotheque avec la commande npm run bibliotheque-build-prod
• d’analyse de la démarche bibliotheque avec la commande npm run bibliotheque-analyseBundle
• de génération de la documentation de la démarche bibliotheque avec la commande npm run bibliotheque-compodoc
• de démarrage de la démarche bibliotheque avec la commande npm run bibliotheque-start
• de démarrage des tests E2E de la démarche bibliotheque avec la commande npm run bibliotheque-e2e

3.34.2.3 - Montée de version Angular

_ Cette procédure est à mettre à jour depuis l’abandon de YARN_ La DINUM publie régulièrement des versions de la librairie System Design de l’état. Une montée de version est à réaliser de la manière suivante :

• dans une commande DOS et pas Git4windows, démarrer l’outil d’upgrade de Yarn avec la commande (s’il n’est pas installé, yarn plugin import interactive-tools) yarn upgrade-interactive
• attendre que toutes les libs soient chargées
• sélectionner (carré vert) la dernière version de la librairie DSFR
• taper ENTRER pour valider les sélections et lancer l’installation
• vérifier que le projet front fonctionne en
  • exécutant un build complet : npm run all-build-prod
  • exécutant les tests npm run e2e vs npm run xx-start avec xx chacune des démarches
  • exécutant les tests avec couverture de code npm run e2e vs npm run xx-startcoverage avec xx chacune des démarches

3.34.2.4 - Montée de version DSFR

_ Cette procédure est à mettre à jour depuis l’abandon de YARN_

La mise à jour de la dépendance DSFR est régulière. Elle est à réaliser de la manière suivante :

• dans une commande DOS et pas Git4windows, démarrer l’outil d’upgrade de Yarn avec la commande (s’il n’est pas installé, yarn plugin import interactive-tools) yarn upgrade-interactive
• attendre que toutes les libs soient chargées
• sélectionner (carré vert) la version à installer dans la colonne Range pour la librairie DSFR
• taper ENTRER pour valider les sélections et lancer l’installation
• vérifier que le projet front fonctionne en
  • exécutant un build complet : npm run all-build-prod
  • exécutant les tests npm run e2e vs npm run xx-start avec xx chacune des démarches
  • exécutant les tests avec couverture de code npm run e2e vs npm run xx-startcoverage avec xx chacune des démarches
• pour chaque composant HTML de la DSFR utilisé dans l’application, vérifier la structure HTML de chacun (La structure évolue. La documentation aussi. Mais aucun guide de migration n’existe) :

3.34.2.5 - Montée de version des autres dépendances Node

_ Cette procédure est à mettre à jour depuis l’abandon de YARN_

La mise à jour des dépendances autres que celles d’Angular et DSFR est régulière. Elle est à réaliser de la manière suivante :

• dans une commande DOS et pas Git4windows, démarrer l’outil d’upgrade de Yarn avec la commande (s’il n’est pas installé, yarn plugin import interactive-tools) yarn upgrade-interactive
• attendre que toutes les libs soient chargées
• sélectionner (carré vert) les versions à installer dans la colonne Range sauf la librairie DSFR
• taper ENTRER pour valider les sélections et lancer l’installation
• vérifier que le projet front fonctionne en
  • exécutant un build complet : npm run all-build-prod
  • exécutant les tests npm run e2e vs npm run xx-start avec xx chacune des démarches
  • exécutant les tests avec couverture de code npm run e2e vs npm run xx-startcoverage avec xx chacune des démarches

3.34.3 - Mise à jour des outils

3.34.3.1 - VSCode

La mise à jour de VSCode est opportuniste car elle se fait dès que l’IDE annonce la sortie d’une nouvelle version. Elle est à réaliser de la manière suivante :

• télécharger l’archive contenant l’IDE depuis Internet (site internet ou depuis l’IDE)
• dézipper l’archive dans le répertoire des outils en faisant attention à conserver le numéro de version de l’IDE dans le nom du répertoire
• modifier le raccourci vers l’IDE en y changeant le numéro de version
• mettre à jour la page contenant la backlog et programmer la prochaine mise à jour pour le prochain trimestre
• modifier la version à installer dans les chapitre 3.2

3.34.3.2 - Eclipse

La mise à jour d’Eclipse est régulière car une version sort tous les trimestres. Elle est à réaliser de la manière suivante :

• télécharger l’archive contenant la version Eclipse IDE for Java Developers de l’IDE depuis le site Internet officiel
• dézipper l’archive dans le répertoire des outils en faisant attention à conserver le numéro de version de l’IDE dans le nom du répertoire
• modifier le raccourci vers l’IDE en y changeant le numéro de version
• accepter, au démarrage, qu’Eclipse transforme le workspace pour le rendre compatible avec la nouvelle version de l’IDE (au besoin, recréer un workspace avec la procédure ci-dessous)
• après le démarrage, il est nécessaire d’installer le plugin SonarLint
• mettre à jour la page contenant la backlog et programmer la prochaine mise à jour pour le prochain trimestre
• modifier la version à installer dans les chapitre 3.2

Si, à la montée de version Eclipse, le workspace n’est plus utilisable (par exemple, raccourci cassé à la montée de version 2022-12), il faut :

• arrêter Eclipse
• renommer le répertoire du workspace existant en le suffixant de -old
• démarrer Eclipse (il va recréer un répertoire puisqu’il est en paramètre de l’exécutable dans le raccourci - cf. procédure d’installation du poste)
• configurer :
  • General > Workspace : définir l’encoding UTF8 et le délimiteur Unix pour tout nouveau fichier
  • Maven : définir l’installation externe à Eclipse
  • Maven : définir le chemin du fichier de configuration et cliquer sur le bouton Update settings
  • Java > Installed JRE : ajouter le dernier JDK en date, en faire la version par défaut et supprimer tout autre installation Java
  • Java > Code style > Formatter : importer le fichier de configuration présent dans la documentation
  • Java > Editor > Save actions : configurer chaque formulaire jusqu’à obtenir cette configuration
  • General > Keys : créer vos raccourcis si vous en paramétrer habituellement (²² pour rerun Junit test par exemple)
  • Run/Debug > console : désactiver la limite de sortie de la console
  • Run/Debug > Launching : cocher always pour la sauvegarde des fichiers en cours d’édition (première question du formulaire en version 2023-06)
  • Run/Debug > Perspective : cocher always pour l’ouverture de la prespective au lancement (première question du formulaire en version 2023-06)
  • Version control > Git > Project : décocher toutes les cases
  • SonarLint > File exclusions : ajouter une exclusion *.rdb
  • réorganiser les perspectives Java et Debug pour faire apparaitre les vues progress
• au besoin, comparer les fichiers présents dans _.metadata.plugins\org.eclipse.core.runtime.settings_
• arrêter Eclipse
• créer une archive ZIP du répertoire .metadata et la conserver dans la documentation
• supprimer le répertoire du workspace précédent suffixé par -old
• importer les projets du socle qui ne sont pas de type POM (ceux qui n’ont pas d’enfant)

3.34.3.3 - Java

La mise à jour de Java est régulière car une version sort régulièrement. Elle est à réaliser de la manière suivante :

• télécharger l’archive contenant le nouveau JDK depuis le site Internet officiel
• dézipper l’archive dans le répertoire des outils en faisant attention à conserver le numéro de version du JDK dans le nom du répertoire
• ouvrir les paramètres système pour modifier les variables d’environnement (rechercher modifier les variables d’environnement système dans le menu démarrer)
• modifier la variable d’environnement JAVA_HOME
• vérifier que JAVA_HOME fait partie de path
• fermer les fenêtres de commandes déjà ouvertes et ouvrir une nouvelle fenêtre de commandes
• vérifier que la version de Java est bien prise en compte avec la commande java -version
• vérifier que le projet socle fonctionne en exécutant un build nominal mvn clean install
• ajouter le certificat racine de l’entreprise (si nécessaire) dans le nouveau JDK avec les informations du chapitre 3.2.7
• ajouter le certificat TLS newPSL dans le nouveau JDK avec les informations du chapitre 3.2.8.1 (rechercher Importer le certificat racine)
• dans le raccourci démarrant Eclipse, changer le chemin du JDK
• modifier la version du JDK dans la description du raccourci présente au chapitre 3.2.5.2
• dans le workspace d’Eclipse, ajouter le nouveau JDK et retirer l’ancien (Window > Preferences > Java > Installed JRE)
• revoir l’intéret
  • de l’argument _-XX:+EnableDynamicAgentLoading _ dans 2-code/socle/pom.xml et dans tous les .launch qui permet de désactiver les warning s’affichant durant les tests automatisés (cf. https://github.com/mockito/mockito/issues/3037 et https://openjdk.org/jeps/451)
  • de l’argument –enable-preview non activable actuellement car Eclipse-202309 ne le supporte pas pour le JDK-21.
• mettre à jour la page contenant la backlog et programmer la prochaine mise à jour pour le prochain trimestre
• modifier la version à installer dans les chapitre 3.2

3.34.3.4 - Node

_ Cette procédure est à mettre à jour depuis l’abandon de YARN _

La mise à jour de Node/npm est régulière car une version sort régulièrement. Elle est à réaliser de la manière suivante :

• télécharger l’archive contenant la nouvelle version de Node depuis le site Internet officiel en version Windows Binary (.zip) et 64 bits
• dézipper l’archive dans le répertoire des outils en faisant attention à conserver le numéro de version de Node dans le nom du répertoire
• ouvrir les paramètres système pour modifier les variables d’environnement (rechercher modifier les variables d’environnement système dans le menu démarrer)
• modifier la variable d’environnement NODE_HOME
• vérifier que NODE_HOME fait partie de path
• redémarrer la console GIT et VSCode pour prendre en compte la modification de la variable d’environnement
• si un outil de sécurité modifie l’autorité de certification sur l’URL https://registry.npmjs.org/, il faut (source) :
  • accéder au site https://registry.npmjs.org/ avec le navigateur Chrome
  • afficher les détails du certificat
  • télécharger le certificat racine de l’outil dans un fichier au format CRT
  • exécuter la commande suivante :

set NODE_EXTRA_CA_CERTS=%JAVA_HOME%\lib\security\xxx.crt

• vérifier les versions installées avec les commandes node -v et npm -v
• dans une commande DOS (et pas git4windows), utiliser la commande yarn upgrade-interactive pour mettre à jour la dépendance @types/node à la version de l’outil Node installée
• mettre à jour le fichier 2-code/front/pom.xml pour mettre à jour la version
  • de Node avec la version affichée dans la console,
  • de Npm avec la version affichée dans la console,
• vérifier que le projet front fonctionne en exécutant
  • un npm install
  • un simple démarrage avec npm run etatcivil-start
  • un build complet via Node avec la commande npm run all-build-prod
  • un build complet via Maven avec la commande mvn clean install -P qualimetrie
• mettre à jour la page contenant la backlog et programmer la prochaine mise à jour pour le prochain trimestre
• modifier la version à installer dans les chapitre 3.2

3.34.3.5 - Maven

La mise à jour de Maven est régulière car une version sort régulièrement. Elle est à réaliser de la manière suivante :

• télécharger l’archive contenant la nouvelle version de maven depuis le site Internet officiel
• dézipper l’archive dans le répertoire des outils en faisant attention à conserver le numéro de version dans le nom du répertoire
• ouvrir les paramètres système pour modifier les variables d’environnement (rechercher modifier les variables d’environnement système dans le menu démarrer)
• modifier la variable d’environnement MAVEN_HOME
• vérifier que MAVEN_HOME fait partie de path
• remplacer le fichier MAVEN_HOME/conf/settings.xml du nouveau Maven par celui de l’ancien
• fermer toutes les fenêtres de commande et en ouvrir une nouvelle
• vérifier la version de Maven en exécutant la commande mvn -v
• vérifier que le projet socle fonctionne en exécutant un build nominal mvn clean install
• dans Eclipse, la version embarquée de Maven est utilisée. Mais il faut pointer sur le même fichier de configuration (Window > Preferences > Maven > User Settings)
• une fois le workspace du projet modifié, il est certainement nécessaire de modifier le workspace des autres projets présents sur le poste de développement
• mettre à jour la page contenant la backlog et programmer la prochaine mise à jour pour le prochain trimestre
• modifier la version à installer dans les chapitre 3.2

3.34.4 - Documentation du Socle

Depuis l’usage de DependencyTrack, les rapports HTML DependencyCheck n’ont plus de sens. La veille sécuritaire (recherche et analyses) se fait donc via l’outil DependencyTrack (cf. §3.34.5).

La documentation générée pour le Socle a néanmoins encore du sens.

3.34.4.1 - Rapports du Socle

La génération des rapports a particulièrement de sens à être exécutée après les montées de version des dépendances du Socle.

Puis il suffit d’utiliser la commande mvn clean install -P qualimetrie. Cette commande exécute l’ensemble complet de toutes les actions possibles :

• exécution des tests automatisés avec couverture
• packaging
  • des livrables
  • des sources (en jar-source)
  • des javadoc (en jar-javadoc](https://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html))
• génération de rapport
  • de couverture de code
• copie de certains éléments dans la partie documentaire du dépôt : dans la page des liens documentaires

Une fois les rapports générés, ces derniers sont consultables immédiatement dans la page des liens documentaires.

3.34.4.2 - Tests de sécurité avec OWASP ZAP

Pour installer l’outil :

• télécharger, depuis le site officiel, l’archive ZAP_2.11.1_Crossplatform.zip
• ouvrir l’archive téléchargée avec 7zip pour modifier le fichier lib/log4j-core-2.15.0.jar en log4j-core-2.15.0.abc (car certains outils de protection refusent l’écriture sur disque de ce fichier)
• extraire le contenu de l’archive dans le répertoire outils
• ouvrir l’archive xxxxxx/ZAP_2.xx.x/zap-2.xx.x.jar avec 7zip et modifier, dans le fichier META_INF/MANIFEST.MF, le nom du jar de log4j

Pour utiliser OWASP ZAP :

• démarrer l’outil via le script zap.bat
• sélectionner la session présente dans le projet documentaire (nommée _sessionOwaspZap décrite plus bas)
• dans la liste déroulante en haut à gauche, sélectionner la valeur mode standard
• dans la fenêtre principale, cliquer sur Automated scan
• saisir l’URL http://dev-psl.guillaumetalbot.com/mademarche/bibliotheque/ avec les spider ajax (avec Chrome headless) et traditionnel
• lancer l’audit (plusieurs dizaines de minutes)
• analyser les résultats

Pour information, la session créée a été paramétrée avec :

• l’exclusion des sites https://.* dans exclure du proxy, exclure du balayage et exclure du robot d’indexation
• l’inclusion, dans le contexte, des sites http://dev-psl.guillaumetalbot.com/mademarche, http://dev-psl.guillaumetalbot.com/mademarche.*, http://localhost:8080 et http://localhost:8080.*
• l’import du swagger des APIs

3.34.5 - Suivi de sécurité avec DependencyTrack

3.34.5.1 - Installation/réinstallation et préparation d’une instance locale de DependencyTrack

procédure issue de la documentation officielle

!!! ATTENTION A PREVOIR 2Go DE DISQUE ET, AU MINIMUM, 45 MINUTES DE TEMPS D’EXECUTION DE L’OUTIL POUR SON INITIALISATION (téléchargement de 1,2Go de JSON du NIST compressé en 70Mo de GZ) !!!

Pour installer DependencyTrack, exécuter les actions suivantes :

• Sortir de tout réseau nécessitant un proxy pour accéder à Internet
• Télécharger, depuis le site GitHub la dernière release nommée dependency-track-bundled.jar.
• Placer le livrable dans le répertoire 2-code\securite\dependencyTrack (écraser l’existant s’il est présent)
• Ouvrir une ligne de commande dans ce répertoire
• Démarrer l’application avec le script 2-code/socle/securite/dependencyTrack/dependencyTrack.sh ou la commande java -Xmx4G -jar dependency-track-bundled.jar -port 9999 (testé en 04/2024 avec Java-21)
• Ignorer les avertissements concernant le fichier id.system
• Ne rien arrêter tant que les logs indiquent des téléchargements et du parsing de fichier

Pour simplement mettre à jour DependencyTrack, exécuter les étapes suivantes :

• Vérifier son bon fonctionnement en cliquant sur ce lien menant à l’application démarrée localement
• Se connecter avec le compte admin et le nouveau mot de passe défini (à sauvegarder dans un KeePass)

Pour initialiser DependencyTrack la première fois, exécuter les étapes suivantes :

• Vérifier son bon fonctionnement en cliquant sur ce lien menant à l’application démarrée localement
• Se connecter avec le compte admin et le mot de passe admin
• Changer le mot de passe comme l’impose l’application
• Se reconnecter avec le compte admin et le nouveau mot de passe défini (à sauvegarder dans un KeePass)
• Accéder à la page administration > Access management > Teams
• Créer une équipe nommée AnalyseLocale
• Cliquer sur la ligne de l’équipe créée
• Mettre la clef d’API (dans la suite de la procédure, elle se nomme XXCLEFAPIXX)
• Ajouter les droits BOM_UPLOAD et VIEW_PORTFOLIO
• Accéder à la page Policy Management
• Créer les policy suivantes
  • 1 (ne semble pas fonctionnel au 11/2023) :
    • Name : Composant avec version majeure de retard
    • Operator : any
    • Violation state : Warn
    • Conditions : Version Distance > 0 1 0 0
  • 2 :
    • Name : Composant de plus d’un an
    • Operator : any
    • Violation state : Inform
    • Conditions : Age > P1Y
  • 3 (ne semble pas fonctionnel au 11/2023) :
    • Name : Composant pas à la dernière version
    • Operator : any
    • Violation state : Inform
    • Conditions : Version Distance > 0 0 0 1
  • 4 :
    • Name : Licence CopyLeft Interdite
    • Operator : any
    • Violation state : Fail
    • Conditions : Licence group is copylef
  • 5 :
    • Name : Licence NonCommeciale Interdite
    • Operator : any
    • Violation state : Fail
    • Conditions : Licence group is Nom-Commercial

3.34.5.2 - Audit des projets SOCLE et FRONT

Réaliser une analyse du socle en exécutant les étapes suivantes :

• Dans le répertoire 2-code/socle, exécuter la commande mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom
• Vérifier que DependencyTrack s’exécute
• Exécuter la commande curl -X "POST" http://localhost:9999/api/v1/bom -H 'Content-Type: multipart/form-data' -H "X-Api-Key: XXCLEFAPIXX" -F "autoCreate=xxAUTOxx" -F "projectName=newPslSocle" -F "projectVersion=xxVERSIONxx" -F bom=@target/bom.xml
  • avec xxVERSIONxx une date au format yyyyMM (par exemple 202404 pour avril 2024)
  • avec XXCLEFAPIXX la clef créée plus tôt (ou à récupérer dans DependencyTrack > Access Management > Teams > AnalyseLocale)
• Vérifier que la réponse soit au format {"token":"eef176b8-feea-4786-97e4-817e97763a2a"}
• Dans l’IHM de DependencyTrack, vérifier la présence du projet dans la page Projects

Réaliser une analyse du front en exécutant les commandes suivantes !!!!!!!NE FONCTIONNE PAS POUR LE MOMENT (04/2024) !!!!!!!!!!! :

• Dans le répertoire 2-code/front, depuis une ligne de commande DOS, exécuter les commandes suivantes :
  • Pour installer globalement l’outil d’analyse npm install --global @cyclonedx/cyclonedx-npm
  • Pour créer un package-lock.json pour les besoins de l’analyse npm install --package-lock-only --force
  • Pour générer le BOM du front cyclonedx-npm --output-format XML --output-file bom.xml
  • Supprimer le répertoire node_modules
  • Supprimer le fichier package-lock.json
• Créer le projet newPslFront avec la commande suivante (en remplaçant la clef) curl -X "POST" http://localhost:8080/api/v1/bom -H 'Content-Type: multipart/form-data' -H "X-Api-Key: XXCLEFAPIXX" -F "autoCreate=true" -F "projectName=newPslFront" -F "projectVersion=1.0.0" -F bom=@bom.xml

3.34.5.3 - Raffrachir un audit

Pour relancer (après modification d’un paramètre ou évolution du BOM) une analyse, exécuter la commande en y remplaçant la clef d’API, le nom du projet et le chemin vers le bom.xml : curl -X "POST" http://localhost:9999/api/v1/bom -H 'Content-Type: multipart/form-data' -H "X-Api-Key: XXCLEFAPIXX" -F "projectName=newPslXXXX" -F "projectVersion=1.0.0" -F bom=@target/bom.xml

3.34.5.4 - Analyse

Pour information, le code Java du Socle se base sur de nombreuses dépendances toute sous licence. Certaines de ces licences autorisent un usage en milieu professionnel mais d’autres non : elles imposent que le code dépendant soit tout aussi OpenSource que la dépendance elle-même. Ceux sont les licences Copyleft.

Etudier une analyse DependencyTrack avec les consignes suivantes :

• Dans l’IHM de DependencyTrack, accéder à la page Projects > newPslSocle
• Vérifier la présence de licence interdites (commerciale ou copyLeft) dans l’onglet Policy violations
  • Vérifier si la version est la plus récente
  • Vérifier si la licence a évolué récemment (à l’échelle du rythme des release de ce composant)
  • Vérifier si la dépendance est directe ou pas. Si elle est indirecte, peut-on s’en passer ?
  • Commenter chaque violation pour un suivi
• Vérifier la présence de vulnérabilité dans l’onglet Audit Vulnerabilities
  • Traiter les vulnérabilités par sévérité décroissantes :
    • Si la faille existe et qu’il est possible de la combler en changeant le code appelant ou en modifiant la dépendance directe (et uniquement la dépendance directe !), la correction est à faire.
    • Si la faille existe et qu’il n’est pas possible de la combler, autant savoir qu’elle existe et surveiller de près la dépendance fautive pour réaliser une mise à jour rapidement.
    • Si la faille n’existe pas, il est possible de l’ignorer dans l’outil (sans oublier de mettre un commentaire)
  • Systématiquement, commenter chaque vulnérabilité pour un suivi

Un bon référentiel des licences est disponible sur Wikipedia