Gestion des failles de sécurité dans l'écosystème PHP/Symfony

Avez-vous idée de comment se déroule la correction d'une vulnérabilité dans notre écosystème ?

Signalement, discrétion, validation, mesure d'impact, coordination inter-projets ... C'est tout un processus dont chaque étape doit être traîtée minutieusement avant qu'une faille puisse être révélée et son correctif mis à disposition de l'ensemble de la communauté, afin de protéger nos projets.

Ça demande beaucoup de travail, génère une pression conséquente, et c'est principalement un effort bénévole pour lequel chaque intervenant•e donne de son temps personnel.

Curieux•se d'en savoir plus ? Je vous montre comment ça se passe de l'intérieur avec le cas de Symfony et des nombreux projets communautaires qui en dépendent.

Transcript

1. Gestion des failles de sécurité
2. Robin Chalas github.com/chalasr chalasr.bsky.social x.com/chalas_r PHP Consultant / Symfony Core Team / baksla.sh Co-founder
4. Qu’est-ce qu’une faille de sécurité ?
5. C’est un bug qui peut être exploité à des fins malveillantes.
6. Pourquoi Symfony souffre-t-il de failles de sécurité ?
7. Plus il y a de code, plus il y a de bugs™.
9. Plus un code interagit avec le monde exterieur, plus la surface d’attaque est grande.
10. Et plus un code est utilisé, plus il est sujet à être attaqué.
13. La sécurité absolue n’existe pas.
14. Comment on fait du coup ?
15. Étape 1. Disclosure
16. Nouveau ticket sur dépôt mirroir secret
17. 👀
18. On confirme SANS DÉLAI au reporter qu’on est sur l’affaire (ACK). Étape 1. Disclosure
19. La Core Team analyse le signalement, confirme ou infirme la vulnérabilité, et informe le reporter. Étape 2. Confirmer
20. Ici pas de débat.
21. Pas toujours évident.
22. On identifie ensuite les versions impactées e.g. 5.4, 6.4, 7.2
23. Étape 3. Correctif Une Pull Request sur le même dépôt privé, à l’initiative volontaire d’un membre de la Core Team.
24. Parfois, le reporter lui-même fournit un patch.
26. Relecture
27. Et merge
28. Étape 4 - Coordination On identifie les projets commautaires impactés ainsi que les projets tiers membres du programme.
29. Coordination - Partenaires Pour les projets tiers, un mirroir dédié du projet est créé afin de tenter d’y intégrer le patch et d’en discuter avec les mainteneurs.
30. Coordination - Release Date La date de publication du correctif est déterminée avec les éventuels partenaires impactés.
31. Étape 5 - Security Advisory
32. Étape 5 - Security Advisory
33. Sévérité - Méthode de calcul Symfony
34. CVSS - Méthode de calcul standarde
35. Le jour J : Release
36. git push sur le dépôt public
37. tag + release
38. Dans la foulée, on publie le security advisory.
40. Puis on le partage dans l’annuaire des security advisories de PHP.
43. Et pour finir, un blogpost.
44. Take home security.txt composer audit / dependabot / renovate
45. Merci ! 🍻