#TALK

Les dessous d'un embargo de sécurité

Difficile d'échapper aux failles Meltdown et Spectre en ce début d'année. Outre les failles elles-mêmes, le processus impliqué dans leur découverte, leur documentation et leur correction peut surprendre : on parle de découverte début 2017, d'embargo depuis mi-2017, et un dévoilement soudain tout début 2018, quelques jours avant la date prévue, suivi de mesures d'urgence prises par plusieurs projets et hébergeurs cloud qui n'avaient pas été mis dans la confidence. Cette présentation expliquera comment sont gérés les bugs de sécurité dans les projets « open source », de la découverte à l'embargo puis au « responsible disclosure » voire « coordinated disclosure » ; qui participe, qui détermine le calendrier, comment est géré l'apparent besoin de secret même dans le cadre d'un projet développé en public...

Tech

Vous apprendrez comment réagir à la publication tant redoutée d'un CVE, que ce soit comme développeur ou comme utilisateur, comment évaluer un CVSS, comment rassurer (ou pas !) votre RSSI, mais aussi comment gérer de façon responsable une faille de sécurité que vous pourriez découvrir.

Je ne suis pas un pro de la sécurité, mais je fais partie de l'équipe de réponse au vulnérabilités dans OpenDaylight, et lorsque le besoin se présente, je travaille de près avec l'équipe de sécurité Red Hat (mon employeur) ; je suis aussi développeur Debian, ce qui me donne l'occasion de gérer des failles de sécurité découvertes dans les paquets dont je m'occupe, voire d'en trouver et d'en corriger moi-même. Je participe aussi à des audits de sécurité, des deux côtés de la barrière (auditeur et audité).