5 min lecture • Guide 512 of 877
Comment Gérer les Projets de Sécurité avec les Sprints de Développement
Le travail de sécurité est souvent en concurrence avec la livraison de fonctionnalités pour la capacité sprint, créant une tension entre protection et progrès. GitScrum aide les équipes à intégrer les tâches de sécurité dans les sprints réguliers, suivre la remédiation des vulnérabilités et maintenir la visibilité sur la posture de sécurité sans dérailler le développement de fonctionnalités.
Catégories de Travail de Sécurité
| Catégorie | Priorité | Traitement Sprint |
|---|---|---|
| Vulnérabilité critique | P0 - Immédiat | Tout abandonner |
| Problème haut risque | P1 - Ce sprint | Capacité réservée |
| Amélioration proactive | P2 - Planifié | Priorisation normale |
| Dette technique sécurité | P3 - Backlog | Quand capacité permet |
| Exigence conformité | Basé sur deadline | Jalon planifié |
Sécurité dans la Planification Sprint
ALLOCATION CAPACITÉ SPRINT
┌─────────────────────────────────────────────────┐
│ RÉPARTITION SPRINT TYPIQUE │
│ │
│ Développement Fonctionnalités: 60-70% │
│ ├── Nouvelles fonctionnalités │
│ └── Améliorations fonctionnalités │
│ │
│ Travail Sécurité: 15-25% │
│ ├── Corrections vulnérabilités │
│ ├── Améliorations sécurité │
│ ├── Mises à jour dépendances │
│ └── Tests de sécurité │
│ │
│ Autre: 10-15% │
│ ├── Corrections bugs │
│ ├── Dette technique │
│ └── Améliorations processus │
└─────────────────────────────────────────────────┘
BUFFER SÉCURITÉ SPRINT:
┌─────────────────────────────────────────────────┐
│ Réservez 20% de la capacité sécurité pour: │
│ • Vulnérabilités critiques découvertes mi-sprint│
│ • MAJ dépendances urgentes │
│ • Incidents sécurité │
│ │
│ Si inutilisé: piocher du backlog sécurité │
└─────────────────────────────────────────────────┘
Structure Backlog Sécurité
ORGANISATION BACKLOG SÉCURITÉ
Labels:
├── [security-critical] - Exploitable, fix immédiat
├── [security-high] - Risque significatif
├── [security-medium] - Risque modéré
├── [security-low] - Problèmes mineurs
├── [security-proactive] - Améliorations
└── [security-compliance] - Réglementaire
Catégories de Tâches:
┌─────────────────────────────────────────────────┐
│ 1. REMÉDIATION VULNÉRABILITÉS │
│ Tâches des scans sécurité, pen tests │
│ Sévérité claire et deadline remédiation │
│ │
│ 2. FONCTIONNALITÉS SÉCURITÉ │
│ Nouvelles capacités sécurité │
│ MFA, chiffrement, logs audit │
│ │
│ 3. DURCISSEMENT │
│ Améliorations sécurité proactives │
│ Config headers, CSP, etc. │
│ │
│ 4. MISES À JOUR DÉPENDANCES │
│ Patches sécurité dans dépendances │
│ Cycle MAJ régulier │
│ │
│ 5. CONFORMITÉ │
│ Exigences réglementaires │
│ Travail basé sur deadline │
└─────────────────────────────────────────────────┘
Sécurité dans Definition of Done
CRITÈRES D'ACCEPTATION SÉCURITÉ
POUR TOUTES LES FONCTIONNALITÉS:
┌─────────────────────────────────────────────────┐
│ ☐ Pas de nouvelles vulnérabilités introduites │
│ ☐ Tests sécurité passent │
│ ☐ Scan dépendances propre │
│ ☐ Gestion données sensibles revue │
└─────────────────────────────────────────────────┘
POUR FONCTIONNALITÉS AUTHENTIFICATION/AUTORISATION:
┌─────────────────────────────────────────────────┐
│ ☐ Revue sécurité complétée │
│ ☐ Modèle de menaces mis à jour │
│ ☐ Logging audit implémenté │
│ ☐ Rate limiting en place │
│ ☐ Gestion sessions vérifiée │
└─────────────────────────────────────────────────┘
POUR FONCTIONNALITÉS GESTION DONNÉES:
┌─────────────────────────────────────────────────┐
│ ☐ Classification données confirmée │
│ ☐ Exigences chiffrement satisfaites │
│ ☐ Contrôles accès implémentés │
│ ☐ Politique rétention données appliquée │
│ ☐ Exigences privacy satisfaites │
└─────────────────────────────────────────────────┘
Dashboard Métriques Sécurité
MÉTRIQUES SANTÉ SÉCURITÉ
GESTION VULNÉRABILITÉS:
┌─────────────────────────────────────────────────┐
│ Vulnérabilités Ouvertes: │
│ Critique: 0 (cible: 0, SLA: 24h) ✓ │
│ Haute: 3 (cible: <5, SLA: 7 jours) ✓ │
│ Moyenne: 12 (cible: <20, SLA: 30j) ✓ │
│ Basse: 45 (cible: <100, SLA: 90j) ✓ │
└─────────────────────────────────────────────────┘
VÉLOCITÉ REMÉDIATION:
┌─────────────────────────────────────────────────┐
│ Temps moyen remédiation (par sévérité): │
│ Critique: 18 heures (SLA: 24h) ✓ │
│ Haute: 4 jours (SLA: 7 jours) ✓ │
│ Moyenne: 21 jours (SLA: 30 jours) ✓ │
│ Basse: 65 jours (SLA: 90 jours) ✓ │
└─────────────────────────────────────────────────┘
Bonnes Pratiques
- Réserver de la capacité pour le travail sécurité chaque sprint
- Traiter vulnérabilités critiques comme interruption, pas planifié
- Inclure critères sécurité dans Definition of Done
- Suivre métriques sécurité aux côtés métriques livraison
- Intégrer scans sécurité dans pipeline CI/CD
- MAJ dépendances régulières comme maintenance routine
- Revue sécurité pour changements à haut risque
- Célébrer victoires sécurité comme livraison fonctionnalités
Anti-Patterns
✗ Travail sécurité seulement quand violation
✗ "On corrigera plus tard" pour vulnérabilités
✗ Pas de capacité sécurité dédiée
✗ Sécurité comme bloqueur vs collaborateur
✗ Ignorer MAJ dépendances
✗ Exigences sécurité ajoutées post-développement