ACTION 24 PUBLICATION DÈS LA CONCEPTION RESTITUTION ET PERSPECTIVES JEAN COUTEAU ALEX MOREL

LES OBJECTIFS

PROBLÉMATIQUE Le CRPA demande aux organismes publics de publier les algorithmes mis en œuvre dans le cas de décisions administratives individuelles. Publier l'intégralité des codes sources des logiciels réalisés par le MEN est rédhibitoire. Notamment pour des raisons de : Vulnérabilité : on divulge les technologies d'infrastructure utilisées (et les failles de sécurité liées : Struts, Spring...) ⌬ Sécurité : divulgations de secrets (mots de passe, token...) ⌬ RGPD : on expose le nom des développeurs (balise @author ) ⌬

PREMIÈRE PUBLICATION Pour plusieurs projets (dont Affelnet 6ème et lycée) : première publication partielle (un maximum de l'algorithme métier, un minimum d'infra). Cette première publication est imparfaite : code publié non exécutable, il manque certaines parties de l'algorithme. Dans l'idéal, on aimerait pouvoir publier l'intégralité du code de l'algorithme (exécutable et avec ses tests unitaires) tel qu'il est utilisé en production.

PROBLÉMATIQUE Comment respecter l’exigence de transparence des algortihmes tout en conservant une opacité sur les composants logiciels en exploitation dans le SI du ministère ? POUR LES NOUVEAUX PROJETS 1. Prototype d'architecture Publication By Design : Un module métier, publiable en l'état sur Mim-Libre ⌬ Un module infrastructure, qui reste privé ⌬

PROBLÉMATIQUE Comment respecter l’exigence de transparence des algorithmes tout en conservant une opacité sur les composants logiciels en exploitation dans le SI du ministère ? POUR LES NOUVEAUX PROJETS 2. Mise en place d'un pipeline de publication : Intégré à la CI de la forge éducation nationale ⌬ Automatise la publication sur Mim-Libre ⌬ Avec tous les gardes-fous possibles (y-compris revue manuelle) ⌬

PROBLÉMATIQUE Comment respecter l’exigence de transparence des algorithmes tout en conservant une opacité sur les composants logiciels en exploitation dans le SI du ministère ? POUR LES PROJETS EXISTANTS 3. Stratégies de remédiation Audit de 2 applications (Affelnet 6 et lycée) ⌬ Implémentation de scripts d'analyse et refactoring ⌬ Rédaction d'un guide de remédiation "dev-friendly" ⌬

ORDRE DU JOUR 1. Prototype "Publication By Design" 2. Pipeline de publication 3. Stratégie de remédiation 4. Mise en place au sein de la forge 5. Prochaines étapes

1. PROTOTYPE 'PUBLICATION BY DESIGN'

DEUX MODULES SÉPARÉS : DOMAINE ET INFRASTRUCTURE Placés dans deux dépôts git séparés : le dépôt "domaine" doit être publiable en l'état.

MODULE "DOMAINE" On utilise maven-enforcer pour explicitement lister les dépendances authorisées (par défaut tout est interdit) Ne doit dépendre d'aucun framework (hormis junit ou utilitaire comme guava ou apache- commons). org.apache.maven.plugins maven-enforcer-plugin fr.edu.scolarite:scolarite-utils org.apache.commons:commons-collections4 org.apache.logging.log4j:log4j-api junit:junit

MODULE "DOMAINE" On réifie le modèle métier utilisé par l'algorithme (pas d'attributs liés à l'infrastructure comme le login ou la date de connexion).

MODULE "DOMAINE" Les Services doivent contenir 100% de la logique algorithmique métier. public interface ServiceRepartitionEtudiantsGroupe { Set repartirEtudiants(Set e, int capaciteMaxGroupe); }

MODULE "DOMAINE" En plus du modèle et des services métiers, le repository public inclue également : Les tests unitaires de l'algorithme (pas de base de données) ⌬ Un module "runtime" : programme standalone jouant les algorithmes avec csv en entrée et en sortie ⌬

No content

No content

No content

No content

Cette architecture permet de garder le module public 100% domaine pur. On peut imaginer certaines situations où architecturer le code des algorithmes pour ne faire aucun appel à la base de données soit compliqué et/ou coûteux en mémoire/temps d'exécution. Dans ce cas là uniquement, on peut imaginer que le domaine puisse appeler l'infrastructure (sans en dépendre).

No content

No content

No content

No content

public interface RepartitionDAO { void creerGroupe(Group group); long nombreGroupes(); void ajouterEtudiantAuGroupe(Student student, int groupId); long nombreEtudiants(); List>Etudiant< listerEtudiantsParLot(int tailleDuLot, int numeroDeLot); }

POURQUOI NOUS DÉCONSEILLONS CETTE APPROCHE : Les tests unitaires du module domain n'ont pas accès à l'infrastructure : on va devoir mettre en place des doublures de tests (fake) ⌬ Idem pour le runtime CSV ⌬ On n'a plus la garantie que 100% de la logique algorithmique est publiée (tris, conditions de filtrages... potentiellement définis dans l'infrastructure) ⌬

POUR RÉSUMER : L’architecture est très simple et donc facile à mettre en oeuvre ⌬ Le maven-enforcer évite tout ajout de dépendance ⌬ Nous préconisons fortement la version domaine pur ⌬ Principe applicable à tout langage ou framework (java, php...) ⌬ Le code des deux versions du prototype est disponible sur la forge ⌬

2. PIPELINE DE PUBLICATION

Les grands principes : Respect d'un standard de publication : processus et acteurs en responsabilité ⌬ Rapide à mettre en place sur un projet ⌬ Facile à déclencher pour les équipes de développement ⌬ Facile à utiliser pour les validateurs ⌬

MISE EN PLACE SUR UN PROJET :

No content

MISE EN PLACE SUR UN PROJET : 1. Génération de jetons d'accès Gitlab pour l'automatisation Forge Éducation Nationale ⌬ Mim-Libre ⌬

MISE EN PLACE SUR UN PROJET : 2. Utilisation de modèles CI pour ajouter des contrôles qualité : Gitleaks (détection des secrets, mots de passe, clés...) ⌬ Nettoyage (remplace les secrets détéctés dans le code par une chaine prédéfinie) ⌬ Build (compile le code à partir des sources nettoyées) ⌬ Dependency Track (vulnérabilités dans les dépendances) ⌬ Checkmarx (failles de sécurité en analyse statique) ⌬ Sonar (analyse de qualité du code et couverture de tests) ⌬

MISE EN PLACE SUR UN PROJET : 3. Configuration de la validation Liste des validateurs ⌬ Url de publication ⌬

MISE EN PLACE SUR UN PROJET : Exemple de configuration de CI : include: - project: publi-code-src/ci-templates file: gitleaks.yml - project: publi-code-src/ci-templates file: clean.yml - project: publi-code-src/ci-templates file: base/maven.yml - project: publi-code-src/ci-templates file: sonarqube.yml - project: publi-code-src/ci-templates file: dependency_track.yml - project: publi-code-src/ci-templates file: checkmarx.yml - project: publi-code-src/ci-templates file: validation.yml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 variables: 17 # Variables utilisées par plusieurs templates 18 A24_PUBLICATION_REF_NAME: main 19 A24_MAVEN_IMAGE: maven:3.9-eclipse-temurin-17 20 # Validation/publication 21 A24_PUBLIC_API_URL: https://gitlab.mim-libre.fr/api/v4 22 A24_PUBLIC_GROUP_ID: "2477" 23 A24_VALIDATOR_IDS: "4426" 24 # Sonarqube 25 variables: # Variables utilisées par plusieurs templates A24_PUBLICATION_REF_NAME: main A24_MAVEN_IMAGE: maven:3.9-eclipse-temurin-17 include: 1 - project: publi-code-src/ci-templates 2 file: gitleaks.yml 3 - project: publi-code-src/ci-templates 4 file: clean.yml 5 - project: publi-code-src/ci-templates 6 file: base/maven.yml 7 - project: publi-code-src/ci-templates 8 file: sonarqube.yml 9 - project: publi-code-src/ci-templates 10 file: dependency_track.yml 11 - project: publi-code-src/ci-templates 12 file: checkmarx.yml 13 - project: publi-code-src/ci-templates 14 file: validation.yml 15 16 17 18 19 20 # Validation/publication 21 A24_PUBLIC_API_URL: https://gitlab.mim-libre.fr/api/v4 22 A24_PUBLIC_GROUP_ID: "2477" 23 A24_VALIDATOR_IDS: "4426" 24 # Sonarqube 25 # Validation/publication A24_PUBLIC_API_URL: https://gitlab.mim-libre.fr/api/v4 A24_PUBLIC_GROUP_ID: "2477" A24_VALIDATOR_IDS: "4426" include: 1 - project: publi-code-src/ci-templates 2 file: gitleaks.yml 3 - project: publi-code-src/ci-templates 4 file: clean.yml 5 - project: publi-code-src/ci-templates 6 file: base/maven.yml 7 - project: publi-code-src/ci-templates 8 file: sonarqube.yml 9 - project: publi-code-src/ci-templates 10 file: dependency_track.yml 11 - project: publi-code-src/ci-templates 12 file: checkmarx.yml 13 - project: publi-code-src/ci-templates 14 file: validation.yml 15 16 variables: 17 # Variables utilisées par plusieurs templates 18 A24_PUBLICATION_REF_NAME: main 19 A24_MAVEN_IMAGE: maven:3.9-eclipse-temurin-17 20 21 22 23 24 # Sonarqube 25 # Sonarqube include: 1 - project: publi-code-src/ci-templates 2 file: gitleaks.yml 3 - project: publi-code-src/ci-templates 4 file: clean.yml 5 - project: publi-code-src/ci-templates 6 file: base/maven.yml 7 - project: publi-code-src/ci-templates 8 file: sonarqube.yml 9 - project: publi-code-src/ci-templates 10 file: dependency_track.yml 11 - project: publi-code-src/ci-templates 12 file: checkmarx.yml 13 - project: publi-code-src/ci-templates 14 file: validation.yml 15 16 variables: 17 # Variables utilisées par plusieurs templates 18 A24_PUBLICATION_REF_NAME: main 19 A24_MAVEN_IMAGE: maven:3.9-eclipse-temurin-17 20 # Validation/publication 21 A24_PUBLIC_API_URL: https://gitlab.mim-libre.fr/api/v4 22 A24_PUBLIC_GROUP_ID: "2477" 23 A24_VALIDATOR_IDS: "4426" 24 25 include: 1 - project: publi-code-src/ci-templates 2 file: gitleaks.yml 3 - project: publi-code-src/ci-templates 4 file: clean.yml 5 - project: publi-code-src/ci-templates 6 file: base/maven.yml 7 - project: publi-code-src/ci-templates 8 file: sonarqube.yml 9 - project: publi-code-src/ci-templates 10 file: dependency_track.yml 11 - project: publi-code-src/ci-templates 12 file: checkmarx.yml 13 - project: publi-code-src/ci-templates 14 file: validation.yml 15 16 variables: 17 # Variables utilisées par plusieurs templates 18 A24_PUBLICATION_REF_NAME: main 19 A24_MAVEN_IMAGE: maven:3.9-eclipse-temurin-17 20 # Validation/publication 21 A24_PUBLIC_API_URL: https://gitlab.mim-libre.fr/api/v4 22 A24_PUBLIC_GROUP_ID: "2477" 23 A24_VALIDATOR_IDS: "4426" 24 # Sonarqube 25

A24_SONAR_PROJECT_KEY: fr.edu.action24.nat.prototype:publication-by- design_proto-pur_public 26 SONAR_HOST_URL: https://open-sonar08.forge.education.gouv.fr 27 # Dependency-Track 28 A24_DT_API_URL: https://dependency-track-api.forge.education.gouv.fr/api/ v1 29 A24_DT_PROJECT_UUID: ffdec04a-c8b5-4f28-a827-96f622538ed2 30 # Checkmarx 31 CHECKMARX_BASE_URL: https://acopp.in.phm.education.gouv.fr 32 CX_TEAM: /CxServer/SP/MINEDUC/Centrale/socle1/publi-code-src 33 34 mvn:build: 35 extends: .maven_base 36 variables: 37 A24_MAVEN_GOALS: clean verify 38 39 mvn:deploy: 40 extends: .maven_base 41 stage: deploy 42 variables: 43 A24_MAVEN_GOALS: clean deploy 44 A24_SONAR_PROJECT_KEY: fr.edu.action24.nat.prototype:publication-by- design_proto-pur_public 26 SONAR_HOST_URL: https://open-sonar08.forge.education.gouv.fr 27 # Dependency-Track 28 A24_DT_API_URL: https://dependency-track-api.forge.education.gouv.fr/api/ v1 29 A24_DT_PROJECT_UUID: ffdec04a-c8b5-4f28-a827-96f622538ed2 30 # Checkmarx 31 CHECKMARX_BASE_URL: https://acopp.in.phm.education.gouv.fr 32 CX_TEAM: /CxServer/SP/MINEDUC/Centrale/socle1/publi-code-src 33 34 mvn:build: 35 extends: .maven_base 36 variables: 37 A24_MAVEN_GOALS: clean verify 38 39 mvn:deploy: 40 extends: .maven_base 41 stage: deploy 42 variables: 43 A24_MAVEN_GOALS: clean deploy 44 A24_SONAR_PROJECT_KEY: fr.edu.action24.nat.prototype:publication-by- design_proto-pur_public SONAR_HOST_URL: https://open-sonar08.forge.education.gouv.fr # Dependency-Track A24_DT_API_URL: https://dependency-track-api.forge.education.gouv.fr/api/ v1 A24_DT_PROJECT_UUID: ffdec04a-c8b5-4f28-a827-96f622538ed2 # Checkmarx CHECKMARX_BASE_URL: https://acopp.in.phm.education.gouv.fr CX_TEAM: /CxServer/SP/MINEDUC/Centrale/socle1/publi-code-src 26 27 28 29 30 31 32 33 34 mvn:build: 35 extends: .maven_base 36 variables: 37 A24_MAVEN_GOALS: clean verify 38 39 mvn:deploy: 40 extends: .maven_base 41 stage: deploy 42 variables: 43 A24_MAVEN_GOALS: clean deploy 44 mvn:build: extends: .maven_base variables: A24_MAVEN_GOALS: clean verify mvn:deploy: extends: .maven_base stage: deploy variables: A24_MAVEN_GOALS: clean deploy A24_SONAR_PROJECT_KEY: fr.edu.action24.nat.prototype:publication-by- design_proto-pur_public 26 SONAR_HOST_URL: https://open-sonar08.forge.education.gouv.fr 27 # Dependency-Track 28 A24_DT_API_URL: https://dependency-track-api.forge.education.gouv.fr/api/ v1 29 A24_DT_PROJECT_UUID: ffdec04a-c8b5-4f28-a827-96f622538ed2 30 # Checkmarx 31 CHECKMARX_BASE_URL: https://acopp.in.phm.education.gouv.fr 32 CX_TEAM: /CxServer/SP/MINEDUC/Centrale/socle1/publi-code-src 33 34 35 36 37 38 39 40 41 42 43 44 A24_SONAR_PROJECT_KEY: fr.edu.action24.nat.prototype:publication-by- design_proto-pur_public 26 SONAR_HOST_URL: https://open-sonar08.forge.education.gouv.fr 27 # Dependency-Track 28 A24_DT_API_URL: https://dependency-track-api.forge.education.gouv.fr/api/ v1 29 A24_DT_PROJECT_UUID: ffdec04a-c8b5-4f28-a827-96f622538ed2 30 # Checkmarx 31 CHECKMARX_BASE_URL: https://acopp.in.phm.education.gouv.fr 32 CX_TEAM: /CxServer/SP/MINEDUC/Centrale/socle1/publi-code-src 33 34 mvn:build: 35 extends: .maven_base 36 variables: 37 A24_MAVEN_GOALS: clean verify 38 39 mvn:deploy: 40 extends: .maven_base 41 stage: deploy 42 variables: 43 A24_MAVEN_GOALS: clean deploy 44

DÉVELOPPEURS : Un job manuel permet de faire une demande de publication sur n'importe quelle branche ou tag (on préconise de ne lancer que sur les releases/tags uniquement) ⌬ Ce job crée un ticket pour chaque validateur, qui doit ensuite être approuvé. Les tickets sont regroupés sous un milestone GitLab ⌬

VALIDATEURS : 1. Réception d'un courriel leur indiquant qu'il faut valider la publication : " Validation par " 2. Clic sur le lien du courriel, ils arrivent sur un ticket gitlab leur indiquant comment valider ou refuser la publication.

VALIDATEURS : 3. Ils ont accès à l'auteur, au commit, au pipeline avec les différents rapports, au lien vers l'archive nettoyée.

VALIDATEURS : 4. Ils appliquent le tag souhaité au projet (acceptation ou refus).

Publication automatique : La fréquence est configurable (nous conseillons quotidiennement en nocturne), et lançable manuellement ⌬ Vérification des milestone non fermées : ⌬ Si un seul rejet, la milestone est fermée et la publication refusée ⌬ Si tous les validateurs ont accepté, publication sur Mim-Libre ⌬ Si plus de deux semaines, la milestone est fermée et la publication refusée ⌬ Milestone validée : code pushé (sans l'historique) sur Mim-Libre ⌬

3 - STRATÉGIES DE REMÉDIATION DES PROJETS EXISTANTS

ACCÈS AU GUIDE DE REMÉDIATION Guide pratique à destination des développeurs ( README.md du repository action24-audit).

ÉTAPE 1 : GÉNÉRATION D'UN RAPPORT D'ANALYSE Une fois identifié : Les extensions des fichiers à analyser (java, xml, js, php, python...) ⌬ Les dépendances à proscrire (spring, struts, hibernate...) ⌬ Les parties du code (modules, package...) à publier ⌬ Le script generate_dependencies_report.sh génére un rapport HTML de dépendances

ÉTAPE 2 : CRÉATION D'UN MODULE PUBLIC Peut être situé dans le même repository dans un premier temps. On met en place le maven-enforcer pour contrôler ce qu'on ajoute au module.

ÉTAPE 3 : DÉPLACEMENT DES CLASSES "DOMAINE PUR" VERS LE MODULE PUBLIC Le script move_pure_domain_to_public_module.sh permet de déplacer automatiquement les classes marquées "domaine pur" dans le rapport vers le module public. Nous préconisons d'ajouter les classes et leurs tests correspondants par fonctionnalité (possible de filtrer les classes à publier via une expression régulière)

ÉTAPE 4 : TRAITEMENT DES FICHIERS NON "DOMAINE PUR" On conseille de procéder itérativement (pour publier régulièrement les progrès) : Traiter un problème de dépendance (e.g. supprimer les @Service ) ⌬ Regénérer un rapport : les classes sont maintenant domaine pur ⌬ Utiliser le script pour les déplacer dans le module public (avec leurs tests) ⌬

EXEMPLE Dépendances aux annotation @Service , @Component , @Repository : voir guide de rémédiation. Cas d'un code non traitable (faute de temps, trop complexe...) : on utilise le Design Pattern Template Method pour publier un maximum du code dans un classe abstraite du module public, avec des méthodes abstraites au nom le plus explicite possible.

POUR RÉSUMER : Un guide pratique à destination des développeurs est disponible sur le gitlab ⌬ Des scripts d'analyse / de déplacement dans le module public aident à appliquer une démarche itérative ⌬ Beaucoup des problèmes identifiés peuvent se résoudre relativement facilement ⌬ Pour les problèmes complexes, possible de faire une première publication imparfaite (classes abstraites publiques), quitte à améliorer par la suite ⌬

4 - MISE EN PLACE AU SEIN DE LA FORGE

5 - PROCHAINES ÉTAPES

MVP : DÉJÀ ATTEINT On considère qu'avec les travaux déjà réalisés sur la forge et les guides à disposition, on a déjà une base suffisante pour mettre en place l'approche "Publication By Design" sur de nouveaux projets ou remédier des projets existants.

AMÉLIORATIONS DU PIPELINE Développer un outil dédié à la validation/publication (plus user-friendly, système de relance...) ⌬ Faciliter la configuration du pipeline (choix des analyses) pour les non-techniciens ⌬ Qui ? : l'équipe Forge ou prestataire ⌬

REMÉDIATION Appliquer le guide de remédiation jusqu'au bout sur Affelnet ⌬ Améliorer les scripts (api JDK plutôt qu'analyse statique pour les dépendances transitives ?) ⌬ Sécuriser les refactoring : systématiser l'utilisation d'Archunit ⌬ Accompagner la remédiation de nouveaux projets (java, php...) ? ⌬ Qui ? : Équipe Nancy. Si prestataire, à intégrer aux équipes ⌬

PROTOTYPE "PUBLICATION BY DESIGN" À éprouver sur des nouveaux projets (appel à candidature) ⌬ Frein principal identifié : l'implémentation des convertisseurs des entités infrastructure <=> domaine ⌬ Implémenter d'un runtime web simple pour permettre aux citoyens de tester les algorithmes ⌬

ACTION 24 PUBLICATION DÈS LA CONCEPTION MERCI POUR VOTRE ATTENTION DES QUESTIONS ? JEAN COUTEAU ALEX MOREL

Speaker notes