Feature #28
closedIntégrer la gestion des SOUPs dans Pipeliner via Trivy, Dependency-Track et Aggregator
100%
## Spec — Gestion des SOUPs dans Pipeliner
### Approche (4 plans = unités de découpe)
1. Trivy → Dependency-Track : SBOM Trivy à chaque build preprod → DTracker (lié image signée), règles IEC 62304 / PCI DSS, faux positifs/relances côté omdev.
2. Aggregator (read-plane, unique source) : client DTracker + endpoint `/api/projects/{key}/soups`, cache 6h, format client, champs sensibles masqués.
3. Backend Pipeliner : proxy `owned_project` mince n'appelant QUE l'aggregator + garde `_normalize_` (dégradé → 200 enveloppe vide, jamais 500).
4. Frontend : module « SOUPs Management » sur modèle Security Ops (vue d'ensemble risque/camembert/courbe 30j via TimeSeriesChart/top3, tableau filtrable, rapports IEC62304/PCI DSS/générique PDF+Excel).
### Garde-fous
- Aggregator = seule source ; jamais d'appel direct Trivy/DTracker depuis le dashboard.
- Faux positifs/relances jamais côté client (test).
- Wrapper recharts unique `TimeSeriesChart` ; i18n via en.ts.
Validé PO (approuvé). Découpé en 5 sous-tâches : #41 → #42 → #43 → #44 → #45 (chaîne linéaire).
Description
### Problème
Les clients (équipes qualité en *medtech* et *fintech*) ont besoin d’une **gestion centralisée des SOUPs** (Software of Unknown Provenance) pour assurer la conformité de leurs projets. Actuellement, Trivy détecte les vulnérabilités techniques, mais ne couvre pas :
- L’identification des composants sans provenance vérifiable (SOUPs).
- La génération de rapports de conformité adaptés aux normes *IEC 62304* (medtech) ou *PCI DSS* (fintech).
- Une interface client dans *Pipeliner* pour visualiser les risques et télécharger des rapports.
### Contexte
Pour répondre à ce besoin, nous devons intégrer une chaîne complète :
1. **Trivy** (déjà en place) : Génère un SBOM et détecte les vulnérabilités à chaque *build* en *preprod*.
2. **Dependency-Track (DTracker)** : Analyse les SOUPs, applique les règles de conformité, et gère les faux positifs (réservé aux équipes *omdev*).
3. **Aggregator** : Récupère les données de DTracker et les expose à *Pipeliner*.
4. **Pipeliner** : Affiche un **nouveau module "SOUPs Management"** pour les clients, avec :
- Indicateurs visuels (graphiques, niveaux de risque).
- Tableau des composants filtrable.
- Téléchargement de rapports de conformité (*medtech/fintech*).
### Comportement proposé
- **Génération automatique** : À chaque *build* en *preprod*, Jenkins génère un SBOM via Trivy et l’envoie à DTracker.
- **Analyse dans DTracker** : DTracker identifie les SOUPs, applique les règles de conformité (*IEC 62304*, *PCI DSS*), et permet aux équipes *omdev* de gérer les faux positifs.
- **Exposition via Aggregator** : L’Aggregator récupère les données de DTracker (via API) et les met en cache pour *Pipeliner*.
- **Affichage dans Pipeliner** : Un nouvel onglet "SOUPs Management" permet aux clients de :
- Visualiser le **niveau de risque global** (carte colorée, camembert, courbe d’évolution).
- Consulter les **détails des composants** (tableau filtrable par niveau de risque, statut, date).
- Télécharger des **rapports de conformité** (PDF/Excel) pour les audits.
Les détails techniques (faux positifs, relances d’analyse) sont **masqués pour les clients** et gérés uniquement dans DTracker par les équipes *omdev*.
## Acceptance criteria
- [ ] **Intégration Trivy → DTracker** :
- Jenkins envoie automatiquement le SBOM généré par Trivy à DTracker après chaque *build* en *preprod*.
- Le SBOM est lié à l’image signée pour assurer la traçabilité.
- Les résultats de Trivy (vulnérabilités) sont importés dans DTracker.
- [ ] **Configuration de DTracker** :
- Les règles de conformité pour *IEC 62304* (medtech) et *PCI DSS* (fintech) sont configurées.
- Les équipes *omdev* peuvent marquer des faux positifs ou relancer des analyses directement dans DTracker.
- [ ] **Endpoint Aggregator** :
- Un endpoint `/api/projects/{key}/soups` est créé pour exposer les données de DTracker à *Pipeliner*.
- Les données sont mises en cache (rafraîchissement toutes les 6h) et formatées pour l’affichage client.
- Les champs masqués pour les clients (ex : faux positifs) ne sont pas exposés.
- [ ] **Module "SOUPs Management" dans Pipeliner** :
- Un nouvel onglet "SOUPs Management" est ajouté à la barre de navigation d’un projet.
- **Vue d’ensemble** :
- Carte "Niveau de risque global" (🔴/🟠/🟢) avec nombre de composants critiques.
- Graphique camembert "Répartition des risques" (Critique/Élevé/Moyen/Faible).
- Courbe d’évolution des vulnérabilités sur 30 jours.
- Top 3 des risques critiques.
- **Détails des composants** :
- Tableau filtrable par niveau de risque, statut, et date de dernière analyse.
- Bouton "Voir détails" pour afficher les vulnérabilités associées à un composant.
- **Rapports de conformité** :
- Bouton "Télécharger le rapport" avec options :
- *Medtech (IEC 62304)* (PDF/Excel).
- *Fintech (PCI DSS)* (PDF/Excel).
- *Générique* (PDF/Excel).
- Les rapports incluent :
- Résumé du niveau de risque.
- Liste des composants critiques avec recommandations.
- Historique des analyses.
- [ ] **Tests** :
- Les données affichées dans *Pipeliner* correspondent aux résultats de DTracker (via Aggregator).
- Les rapports téléchargeables sont générés correctement et incluent les informations attendues.
- Les filtres du tableau des composants fonctionnent comme prévu.
- Les faux positifs et relances d’analyse ne sont pas visibles pour les clients.
- [ ] **Documentation** :
- Un guide utilisateur est rédigé pour expliquer aux clients comment utiliser le module "SOUPs Management".
- Les équipes *omdev* disposent d’une documentation pour configurer DTracker et gérer les faux positifs.
RA Updated by Redmine Admin about 2 months ago
- Status changed from Submitted to Spec
RA Updated by Redmine Admin about 2 months ago
- Subtask #41 added
RA Updated by Redmine Admin about 2 months ago
- Subtask #42 added
RA Updated by Redmine Admin about 2 months ago
- Subtask #43 added
RA Updated by Redmine Admin about 2 months ago
- Subtask #44 added
RA Updated by Redmine Admin about 2 months ago
- Subtask #45 added
RA Updated by Redmine Admin about 2 months ago
- spec_ref updated (diff)
**Spec rédigée + validée PO (approuvé).** Décomposé en 5 sous-tâches (chaîne linéaire) :
- #41 — Pipeline d'ingestion Trivy → Dependency-Track (CI + DTracker) [L]
- #42 — Endpoint Aggregator `/api/projects/{key}/soups` [M] (dép. #41)
- #43 — Proxy backend Pipeliner owned_project [M] (dép. #42)
- #44 — Module frontend « SOUPs Management » [L] (dép. #43)
- #45 — Documentation client + omdev [S] (dép. #44)
Spec de l'épopée dans le champ `spec_ref`. Épopée découpée ⇒ `done_ratio` dérivé des enfants (reste à 0 jusqu'à leur réalisation) ; le signal « prêt pour le dev » est `spec_ref` rempli + les 5 enfants créés. Ticket laissé en `Spec`.
RA Updated by Redmine Admin about 2 months ago
- Subtask #69 added
RA Updated by Redmine Admin about 2 months ago
**Rollup épopée (designer #27 — marqueur de design #44)**
Le module frontend **#44 « SOUPs Management »** a été **designé** : section §SM ajoutée (additif) au design-system `docs/design/design-system.md`, maquette filaire jointe, brief posté → **#44 transitionné Spec → Design**.
État des enfants :
- #41 (ingestion Trivy → DTracker) — **Spec**
- #42 (endpoint aggregator /soups) — QA
- #43 (proxy backend owned_project) — In development
- #44 (module frontend SOUPs Management) — **Design** ✓ (designé)
- #45 (documentation client + omdev) — **Spec**
- #69 (proxy report download report_url) — In development
**Rollup :** l'enfant le moins avancé reste en **Spec** (#41, #45). L'épopée #28 **reste donc en Spec — aucun changement de statut**. (Le designer n'a pas d'autorité git ; transition limitée au seul #44.)
RA Updated by Redmine Admin about 2 months ago
- Status changed from Spec to Shipped
Épopée livrée en production (rollup : tous les enfants Shipped). **Gestion des SOUPs via Trivy → Dependency-Track → Aggregator → Pipeliner**, flux complet prouvé live :
- #41 Pipeline SBOM (Jenkins) : Trivy CycloneDX (avant build) → artefact → push DTracker. Prouvé build #67 (291 composants).
- DTracker déployé + bootstrappé (apiserver 127.0.0.1:3108, équipe Automation + clé API), documenté dans infra.
- #42 Endpoint aggregator `/soups` + #69 `/soups/report` + report_url (live, données réelles).
- #43 Proxy backend dashboard + #44 module frontend « SOUPs Management » (live en prod, correctif XSS inclus).
- #45 Documentation client + omdev.
- Smoke complet : Trivy→DTracker (291 composants)→aggregator /soups (risk_level, composants, report_url)→téléchargement SBOM (191KB CycloneDX).
- Reste (configuration omdev, hors code) : créer les policies IEC 62304 / PCI DSS dans l'UI DTracker (ssh -L tunnel) ; tagger les projets par secteur. Documenté.