Pipeliner Client

### Problème
Actuellement, lorsqu’un scan de sécurité (Trivy ou Semgrep) détecte une vulnérabilité dans un projet, aucun processus automatisé n’existe pour créer un ticket Redmine. Cela entraîne une perte de temps pour les équipes qui doivent manuellement suivre et reporter ces vulnérabilités, avec un risque d’oubli ou de doublons.

### Contexte
Le client utilise **Trivy** (pour les vulnérabilités de dépendances et conteneurs) et **Semgrep** (pour les vulnérabilités de code statique). Les résultats de ces scans doivent être automatiquement transformés en tickets Redmine avec les caractéristiques suivantes :
- **Déclencheur** : Webhook écoutant les rapports des scans.
- **Format des tickets** : Titre et description standardisés, tag `Sécurité`, statut `Soumis`.
- **Anti-doublons** : Logique pour éviter la création de tickets en double pour la même vulnérabilité.
- **Régressions** : Création d’un nouveau ticket si la vulnérabilité réapparaît après correction.

### Comportement proposé
1. **Réception des scans** : L’app écoute un endpoint dédié (`POST /scan-results`) pour recevoir les rapports de Trivy et Semgrep.
2. **Création du ticket** : Pour chaque vulnérabilité détectée, un ticket Redmine est créé avec :
- Un **titre** formaté selon l’outil (ex. `[Sécurité] Dépendance vulnérable : lodash@4.17.20 (CVE-2021-23337)` pour Trivy).
- Une **description** incluant toutes les informations disponibles dans le rapport du scan (description, sévérité, extrait de code, lien vers la CVE, recommandations, etc.).
- Un **tag** `Sécurité`.
- Un **statut** `Soumis`.
3. **Anti-doublons** : Utilisation d’une clé unique pour éviter les doublons (ex. `CVE-{id}` pour Trivy, `{fichier}:{ligne}_{rule-id}` pour Semgrep).
4. **Régressions** : Création d’un nouveau ticket si la vulnérabilité réapparaît après correction.

### Exemple de payload attendu
```json
{
"tool": "trivy", // ou "semgrep"
"project_key": "mon-projet", // clé du projet dans l'app
"vulnerability": {
"id": "CVE-2021-23337", // pour Trivy
"package": "lodash",
"version": "4.17.20",
"severity": "High",
"description": "Vulnérabilité permettant une exécution de code arbitraire...",
"report_url": "https://lien-vers-le-rapport.com"
}
}
```

## Acceptance criteria
- [ ] **Intégration du webhook** : L’app expose un endpoint `POST /scan-results` qui accepte les rapports de Trivy et Semgrep et déclenche la création d’un ticket.
- [ ] **Format des tickets** :
- Le **titre** est généré selon le format spécifié pour Trivy et Semgrep.
- La **description** inclut toutes les informations disponibles dans le rapport du scan.
- Le **tag** `Sécurité` est ajouté.
- Le **statut** est `Soumis`.
- [ ] **Anti-doublons** :
- Pour Trivy, la clé unique est `CVE-{id}` (ou `{nom_paquet}@{version}_CVE-{id}` si la CVE n’est pas disponible).
- Pour Semgrep, la clé unique est `{fichier}:{ligne}_{rule-id}`.
- Si un ticket existe déjà avec la même clé, aucun nouveau ticket n’est créé.
- [ ] **Régressions** : Un nouveau ticket est créé si la vulnérabilité réapparaît après correction.
- [ ] **Tests contractuels** :
- Mock des requêtes HTTP vers Redmine pour valider le format des tickets créés.
- Mock des payloads de Trivy et Semgrep pour tester la logique de création et d’anti-doublons.
- [ ] **Tests d’intégration (optionnels)** :
- Test en environnement réel avec `REDMINE_BASE_URL` et `REDMINE_API_KEY` configurés (si `RUN_REDMINE_LIVE=1`).
- Création d’un projet temporaire, d’un ticket, vérification des champs, puis suppression du projet.
- [ ] **Sécurité** :
- Validation des payloads reçus via le webhook pour éviter les injections ou abus.
- Vérification des permissions pour s’assurer que seul le projet concerné peut créer des tickets.
- [ ] **Documentation** :
- Documentation du format attendu pour les payloads du webhook.
- Documentation de la logique d’anti-doublons et de gestion des régressions.