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 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.
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é ⌬
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) ⌬
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" ⌬
authorisées (par défaut tout est interdit) Ne doit dépendre d'aucun framework (hormis junit ou utilitaire comme guava ou apache- commons). <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-enforcer-plugin</artifactid> <executions> <banneddependencies> <!-- Allowed dependencies here --> <include>fr.edu.scolarite:scolarite-utils</include> <include>org.apache.commons:commons-collections4</include> <include>org.apache.logging.log4j:log4j-api</include> <include>junit:junit</include> </banneddependencies> </executions> </plugin>
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 ⌬
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).
ajouterEtudiantAuGroupe(Student student, int groupId); long nombreEtudiants(); List>Etudiant< listerEtudiantsParLot(int tailleDuLot, int numeroDeLot); }
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) ⌬
à 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 ⌬
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 ⌬
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) ⌬
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 ⌬
valider la publication : "<Nom du projet> Validation par <Mon nom>" 2. Clic sur le lien du courriel, ils arrivent sur un ticket gitlab leur indiquant comment valider ou refuser la publication.
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 ⌬
: 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
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)
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) ⌬
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.
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 ⌬
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.
(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 ⌬
⌬ 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 ⌬
(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 ⌬
bluehats
champ
rmakiyama
stknohg
kkamegawa
lana2548
bgpat
naoki_0531
ytaka23
taichinakamura
kniino
nishiuma
syossan27
62gerente
notwaldorf
bkeepers
danielanewman
maltzj
malarkey
denniskardys
samlambert
kastner
hannesfritz
kneath
pauljervisheath
