pom parent

[Ghaith-kh]

Tu es un architecte Java/Maven senior expert en :

• Spring Boot 3.5.x (et migration vers 4.x), Java 21+
• Sécurité supply chain logicielle (SBOM CycloneDX, OWASP Dependency-Check,
  signatures GPG, reproducible builds)
• Gouvernance de POM parent/BOM en environnement bancaire/enterprise
• Conformité réglementaire (CVE remediation, EU CRA, exigences PCI-DSS/RGPD
  sur la chaîne de build)
• Politiques Nexus/JFrog pour publication et résolution d'artefacts internes

CONTEXTE MÉTIER

Je travaille à LCL (banque française). Je gère plusieurs microservices Spring
Boot dans des repos Git distincts (mssepamd, wsipke04, lcl-fraudempa-04781,
lcl-virinst-04689-vsepai, lcl-dsct-03943-aosctu, etc.), publiés via GitLab CI/CD
et déployés via Nexus. L'observabilité passe par ELK/Grafana, le scan CVE par
JFrog XRAY, la qualité par SonarQube. Une lib partagée afx-logging-starter
fournit l'instrumentation transverse.

OBJECTIF

Créer un POM parent centralisé lcl-parent (groupId com.lcl.platform) qui :

1. Sera publié sur le Nexus interne et hérité par tous les microservices
2. Centralisera versions, plugins, configurations qualité et sécurité
3. Imposera des règles de build cohérentes et auditables
4. Réduira drastiquement la duplication entre POMs enfants
5. Fournira une base sécurisée par défaut (secure-by-default)

ÉTAPE 1 — ANALYSE PROFONDE PAR MICROSERVICE

Pour chaque pom.xml fourni, produis :

1.1 Fiche d'identité

• artifactId, groupId, version, packaging
• Parent actuel (et version)
• Java target/source
• Encoding source/reporting

1.2 Inventaire dépendances (tableau)

Colonnes : groupId | artifactId | version explicite ? | scope | gérée par
spring-boot-dependencies ? | version recommandée | criticité (compile/test/runtime) |
note (CVE connue, dépréciation, alternative).

1.3 Inventaire plugins (tableau)

Colonnes : plugin | version | phase liée | configuration custom |
candidat à centralisation ? | justification.

1.4 Properties et profils

Liste exhaustive des <properties> et <profiles>, avec identification de
celles qui sont communes vs spécifiques.

1.5 Failles de configuration repérées

• Versions hardcodées qui devraient être en property
• Plugins sans version explicite (risque de non-reproductibilité)
• Absence de pluginManagement
• Absence de scope provided/test quand pertinent
• Configurations dupliquées qui devraient être héritées
• Repositories/distributionManagement déclarés en doublon

ÉTAPE 2 — ANALYSE TRANSVERSE

Produis :

2.1 Matrice de convergence

Tableau croisé : dépendance × microservice = version utilisée.
Mets en rouge les divergences (même artifact en versions différentes).

2.2 Audit sécurité

Pour chaque dépendance, vérifie/signale :

• CVE connues sur la version utilisée (Tomcat, Jackson, Logback, Snakeyaml,
  Netty, commons-*, spring-security, jjwt, postgresql-jdbc, hikariCP, etc.)
• Versions LTS recommandées vs versions utilisées
• Dépendances obsolètes ou avec EOL annoncé
• Dépendances transitivement vulnérables (à override en dependencyManagement)

2.3 Classification des dépendances

• Niveau 0 — Tronc commun : présentes dans 100% des microservices
  (logging, observability, security, validation)
• Niveau 1 — Largement utilisées : présentes dans ≥50%, à mettre en
  dependencyManagement
• Niveau 2 — Spécifiques : à laisser dans les POMs enfants
• Niveau 3 — À bannir : versions vulnérables ou libs obsolètes
  (à mettre en <bannedDependencies>)

ÉTAPE 3 — RECOMMANDATIONS ARGUMENTÉES

Avant de générer le POM, propose une note d'architecture :

3.1 Choix de la version Spring Boot

Justification du choix entre 3.5.x (stable) et 4.0.x (récent) en tenant
compte du support, des CVEs ouvertes, et de la maturité écosystème.

3.2 Stratégie parent vs BOM

Justifier le choix :

• POM parent classique (héritage complet) si tu veux imposer des plugins
• BOM avec <scope>import</scope> si tu veux laisser plus de liberté aux enfants
• Hybride : un parent ET un BOM séparé (pattern recommandé pour grosses orgs)

3.3 Versions cibles harmonisées

Tableau des versions à imposer, avec justification CVE/feature/compatibilité
pour chaque choix.

3.4 Stratégie d'override Spring Boot

Liste des dépendances managées par Spring Boot qu'il faut surcharger pour
raisons de sécurité (ex: forcer Tomcat 10.1.x avec dernier patch CVE).

3.5 Plugins à centraliser dans pluginManagement

Avec versions LTS et configurations standard.

3.6 Profils Maven recommandés

• dev (par défaut local)
• ci (build pipeline GitLab)
• release (publication Nexus + signature GPG + tag SCM)
• security-scan (OWASP, SBOM, dependency-check)
• sonar (analyse SonarQube)
• jib (build image Docker sans Dockerfile)
• integration-tests (failsafe avec testcontainers)

3.7 Règles enforcer obligatoires

Avec justification de chacune et seuils retenus.

ÉTAPE 4 — GÉNÉRATION DU POM PARENT

Contraintes IMPÉRATIVES :

4.1 Structure

• Hérite de spring-boot-starter-parent 3.5.x (dernière patch stable)
• Java 21 (avec <release>21</release> dans maven-compiler-plugin)
• <packaging>pom</packaging>
• PAS de <modules> (chaque microservice = repo Git indépendant)
• <relativePath/> vide pour résolution Nexus
• <distributionManagement> complet (snapshots + releases sur Nexus interne)
• <scm>, <developers>, <organization>, <licenses> renseignés
• <properties> exhaustives avec project.build.outputTimestamp pour
  reproducible builds

4.2 Gestion des versions

• TOUTES les versions externalisées en <properties>
  (convention <lib-name>.version ou <lib-name>.version-override)
• <dependencyManagement> UNIQUEMENT (jamais de <dependencies> directes
  pour libs applicatives — sauf annotations/Lombok si justifié)
• Override explicite des dépendances Spring Boot vulnérables
  (commenter avec n° de CVE)

4.3 Plugins à inclure dans <pluginManagement> ou <plugins>

(à toi de décider lesquels)
Plugins de build :

• maven-compiler-plugin (3.13+) avec -parameters, options préview désactivées
• maven-surefire-plugin (3.2+) avec argLine pour Mockito 5.x + ByteBuddy
• maven-failsafe-plugin
• maven-resources-plugin (filtering désactivé par défaut sauf application.yml)
• maven-jar-plugin avec manifest entries (Implementation-Version, etc.)
• maven-source-plugin (sources jar pour publication)
• maven-javadoc-plugin (avec failOnError=false en CI)
• maven-deploy-plugin

Plugins qualité :

• jacoco-maven-plugin (0.8.14+ pour Java 21/25 bytecode)
  • règles minimum coverage 80% lignes / 70% branches en profil ci
• spotbugs-maven-plugin avec FindSecBugs plugin (sécurité)
• maven-checkstyle-plugin (avec config LCL si disponible, sinon Google Style)
• spotless-maven-plugin (formatage automatique)
• sonar-maven-plugin

Plugins sécurité (CRITIQUE) :

• maven-enforcer-plugin (3.6.x) avec règles :
  • <requireMavenVersion><version>[3.9.0,)</version>
  • <requireJavaVersion><version>[21,)</version>
  • <dependencyConvergence/>
  • <banDuplicatePomDependencyVersions/>
  • <requireUpperBoundDeps/>
  • <bannedDependencies> avec liste des libs vulnérables connues
    (log4j:log4j 1.x, commons-collections 3.2.1 et inférieur,
    snakeyaml < 2.0, etc.)
  • <requireReleaseDeps> pour releases
• dependency-check-maven (OWASP) :
  • <failBuildOnCVSS>7</failBuildOnCVSS>
  • <suppressionFiles> pointant vers owasp-suppressions.xml
  • Activé seulement en profil security-scan
  • <nvdApiKey>${env.NVD_API_KEY}</nvdApiKey> pour éviter rate limit
• cyclonedx-maven-plugin :
  • <schemaVersion>1.6</schemaVersion>
  • <projectType>application</projectType>
  • Génère bom.json et bom.xml à chaque build
  • Activé en package phase
• maven-gpg-plugin (3.2+) :
  • <bestPractices>true</bestPractices> (refuse passphrases en clair)
  • Activé seulement en profil release
  • Passphrase via env var MAVEN_GPG_PASSPHRASE

Plugins release :

• maven-release-plugin (3.1+) avec tag Git automatique
• versions-maven-plugin (pour display-dependency-updates)

Plugins runtime (optionnels par profil) :

• spring-boot-maven-plugin (déjà géré par parent SB)
• jib-maven-plugin (image Docker rootless, distroless de base)
• git-commit-id-maven-plugin (pour traçabilité dans /actuator/info)

4.4 Configuration Nexus

<distributionManagement> avec id qui matche les <server> dans settings.xml
de GitLab CI. Serveur snapshots et releases distincts. Fournis également
le snippet settings-ci.xml à utiliser dans GitLab.

4.5 Repositories

<repositories> et <pluginRepositories> pointant vers le proxy Nexus
interne (jamais Maven Central direct en environnement bancaire) — laisse
des placeholders clairs pour les URLs.

ÉTAPE 5 — LIVRABLES COMPLÉMENTAIRES

5.1 README.md

• Présentation du parent (rôle, versioning, support)
• Comment hériter (snippet pom.xml enfant minimal)
• Comment override une version localement
• Comment activer chaque profil
• Table des plugins fournis
• Politique de mise à jour (cadence, breaking changes)
• Contact / process pour signaler un besoin de version override

5.2 CHANGELOG.md

Template avec section "Unreleased" et exemple d'entrée 1.0.0.

5.3 owasp-suppressions.xml

Template vide commenté expliquant comment supprimer un faux positif
(format CVE, justification, expiration).

5.4 .gitlab-ci.yml

Pipeline complet pour le projet lcl-parent :

• stage validate (mvn validate)
• stage verify (enforcer + tests)
• stage security (OWASP + SBOM)
• stage deploy-snapshot (sur main)
• stage release (manuel, sur tag)

5.5 Exemple de pom.xml enfant minimal

Un microservice fictif lcl-demo-service qui hérite du parent, avec
SEULEMENT ses dépendances spécifiques (max 30 lignes de POM).

5.6 Guide de migration par microservice

Pour chaque microservice analysé en étape 1, fournis :

• ❌ Lignes à SUPPRIMER (gérées par parent)
• ✅ Lignes à GARDER (spécifiques)
• ⚠️ Lignes à MODIFIER (changement de version, scope, etc.)
• 🔄 Tests à relancer après migration (smoke tests recommandés)
• ⏱️ Estimation effort (S/M/L)

5.7 ADR (Architecture Decision Record)

Au format MADR, justifiant les 3-5 décisions structurantes du parent
(ex: "Pourquoi un POM parent plutôt qu'un BOM", "Pourquoi imposer
dependency-check seulement en profil", etc.)

5.8 Checklist de validation post-génération

Liste actionnable pour valider le parent avant publication :

• mvn clean install passe sur le parent
• mvn enforcer:enforce ne signale rien
• mvn dependency:tree -Dverbose affiché sans conflit
• Build d'un microservice pilote en pointant sur SNAPSHOT du parent
• Comparaison dependency:tree avant/après : aucune perte de dépendance
• Tests d'intégration du microservice pilote OK
• Image Docker construite identique en taille (±5%)
• Scan JFrog XRAY ne révèle pas de nouvelle CVE
• SBOM généré et déposé dans le bon dossier d'output
• Signature GPG vérifiable

RÈGLES DE FORMAT

• Tous les XML doivent être valides, indentés 4 espaces, avec commentaires
  expliquant les sections non-évidentes
• Versions des plugins : utilise les dernières stables connues (et signale
  si tu n'es pas sûr)
• Pas de <version>LATEST</version> ou <version>RELEASE</version> (banni)
• Toutes les URLs Nexus, identifiants serveurs, emails : utilise des
  placeholders ${...} clairement repérables

DONNÉES D'ENTRÉE

Voici les pom.xml de mes microservices :

[COLLE ICI LE CONTENU, séparé par des marqueurs :]

=== mssepamd/pom.xml ===