Vulnérabilités open source et sécurité avec Jeff McAffer de Microsoft

Alors que 2019 touche à sa fin, nous revenons sur quelques épisodes marquants de notre podcast The Secure Developer. Retrouvez le premier article ici.

Le podcast The Secure Developer fait partie de MyDevSecOps, notre communauté axée sur la formation à la sécurité et indépendante des fournisseurs. Cette communauté, autrefois également connue sous le nom de The Secure Developer, se réunit en ligne via notre groupe Slack et lors d’événements virtuels, ainsi qu’en personne lors des événements DevSecCon organisés dans le monde entier.

À propos de notre invité

Jeff McAffer est directeur du bureau des programmes open source de Microsoft. Dans le cadre de ses fonctions, il dirige ce bureau et contribue à faire évoluer les politiques, les processus, les outils et la culture dans toute l’entreprise, alors que Microsoft change de regard sur l’open source. Il a récemment participé à notre podcast The Secure Developer pour discuter des sujets suivants :

• Comment simplifier les processus de sécurité

• La gestion des vulnérabilités

• La gestion responsable de l’open source, et bien plus

Aujourd’hui, nous souhaitons partager les temps forts de notre conversation avec Jeff.

Simplifier le processus

Les douze membres de l’équipe de Jeff ont cherché à simplifier le processus open source chez Microsoft en appliquant la devise « éliminer, automatiser, déléguer ». Voici ce que cela signifie :

• Éliminer : dans la mesure du possible, l’équipe supprime toute politique, question ou source de friction qu’elle peut repérer et résoudre.

• Automatiser : l’équipe rédige des politiques hautement automatisées, capables de prendre en compte des données et du contexte pour produire une réponse.

• Déléguer : si l’équipe identifie un risque nécessitant un avis extérieur, elle le confie à un tiers possédant l’expertise nécessaire, comme un avocat ou un membre de l’équipe davantage axé sur les enjeux commerciaux.

Selon Jeff, en appliquant ce processus et en abandonnant le modèle « demande et approbation » au profit d’un modèle « enregistrement et examen », « nous en sommes arrivés à un point où, grâce aux intégrations à nos systèmes de build, à ces politiques automatisées et à des données fiables, environ 99 % de nos usages de l’open source sont détectés automatiquement et traités par nos moteurs de politiques, sans aucune intervention humaine. »

Malgré les efforts déployés pour automatiser les systèmes autant que possible, les outils ne sont pas parfaits : comme il le dit, les humains restent des humains et les outils restent des outils. Il est donc important de disposer d’un plan de sécurité pour gérer les vulnérabilités susceptibles d’apparaître.

Prendre en compte les vulnérabilités

Chez Microsoft, la sécurité s’articule autour de deux niveaux différents :

• Développement actif : le premier ensemble de composants de sécurité concerne le développement actif. Lorsqu’un composant ajouté présente un problème de sécurité ou de licence, il est signalé, l’équipe en est informée et peut alors intervenir.

• Réponse aux incidents : lorsqu’une vulnérabilité critique est divulguée, elle est transmise à l’équipe de réponse aux incidents de sécurité, qui prend une décision sur la base des informations disponibles. La décision de donner l’alerte dépend de la définition du SLA.

Ces niveaux couvrent la plupart des cas d’usage. Cependant, selon Jeff, il est toujours intéressant de se demander : « Quelles informations d’évaluation plus pertinentes pouvons-nous obtenir ? Comment puis-je savoir, en tant qu’utilisateur, si je suis vulnérable ? » Chez Snyk, nous partageons ces interrogations (et nos outils vous permettent de détecter à tout moment les vulnérabilités présentes dans vos dépendances). Cette approche permet aux entreprises de faire preuve d’une transparence totale dans la gestion de leurs vulnérabilités et de rendre compte des résultats obtenus.

Signaler de manière proactive vos vulnérabilités, que ce soit via les CDE standard ou par d’autres moyens, est une démarche responsable et respectueuse envers l’ensemble de la communauté open source. Cela fait partie de la prise en charge des responsabilités d’un mainteneur open source. Si vous choisissez d’utiliser des composants open source, Jeff vous recommande d’en assumer la responsabilité en suivant et en signalant les vulnérabilités associées lorsque vous distribuez ce code.

Mieux gérer l’open source

Dans le même esprit, alors que les entreprises cherchent à mieux détecter les vulnérabilités, Microsoft a lancé ClearlyDefined.io pour recueillir des données de licence auprès de la communauté. Les membres peuvent y annoter les licences et les titulaires de droits d’auteur difficiles à identifier, afin que les informations restent aussi à jour que possible.

ClearlyDefined est examiné comme toute contribution open source, puis intégré aux définitions des composants open source. L’idéal est que ces informations soient reversées aux composants d’origine, afin que leurs prochaines versions soient « plus clairement définies ».

Comme l’explique Jeff : « Beaucoup de gens pensent encore : “C’est open source. Je vais simplement le prendre, l’utiliser, et voilà.” Mais il faut vraiment le traiter comme s’il s’agissait de votre propre code. Même si vous n’allez pas en écrire, même si vous ne connaissez pas le langage, vous devez le considérer comme faisant partie de votre système, vous soucier de sa sécurité et collaborer avec les équipes qui le produisent, les équipes du projet, en leur demandant : “Comment pouvons-nous le construire ensemble ? Comment en faire un projet sécurisé, afin que nous puissions tous l’utiliser en toute sécurité ?” » Nous adhérons pleinement à cette vision de la gestion responsable de l’open source.

MyDevSecOps s’engage à inviter d’excellents intervenants comme Jeff McAffer à ses sessions virtuelles et à son podcast, The Secure Developer. Si vous souhaitez en savoir plus sur tous les aspects de la sécurité, pensez à rejoindre la communauté.