« Les organisations doivent maîtriser les implications de sécurité du code tiers dans leurs logiciels » : Mike Hanley, GitHub

THB : Qu’est-ce qui a pris autant de temps à GitHub pour embaucher un responsable de la sécurité et quels sont certains des changements que vous avez apportés à la plateforme ?

MH : Lorsque j’ai été embauché, l’objectif était vraiment que la sécurité soit davantage une fonction primordiale, non seulement pour l’entreprise mais dans l’écosystème plus large. Ainsi, lorsque je suis arrivé, nous avons regroupé toutes les fonctions de sécurité sous un même toit, les fonctions quotidiennes de haut niveau au sein de l’entreprise relevant directement du PDG, car c’est ce que nous pensons que cela devrait être. Nous avons triplé le montant de l’investissement que nous avions dans l’équipe du point de vue des effectifs. Nous disposons d’un programme et de capacités de sécurité de bonne taille et je suis vraiment fier du travail accompli par l’équipe. Quant à savoir pourquoi il n’y en avait pas avant, je ne peux pas vraiment en parler. Mais je peux dire que nous avons littéralement triplé ce chiffre pour créer un impact positif non seulement sur GitHub mais pour tous les clients qui dépendent de nous dans l’écosystème logiciel plus large.

THB : Quels sont les plus grands défis auxquels votre équipe est confrontée ?

MH : Ce qui est intéressant, ce n’est pas seulement le rythme auquel les changements se produisent, mais aussi le rythme qui s’accélère constamment. C’est drôle de penser que ChatGPT est sorti il ​​y a seulement 18 mois environ. Cela fait plusieurs années à ce stade, n’est-ce pas ? Ce le rythme du changement ne fera que s’accélérer. La grande transition que les gens doivent rechercher, à mon avis, est de savoir comment en tirer parti tout en gérant intelligemment les risques. De toute évidence, nous croyons fermement à l’IA – nous avons des produits très réussis dans le domaine de l’IA, comme GitHub Copilot, qui est le premier programmeur IA en binôme qui aide plus d’un million d’utilisateurs à être plus productifs et plus sécurisés lorsqu’ils écrivent du code. Mais nous adoptons également l’IA dans différents endroits Dans notre secteur, il s’agit notamment de faciliter les progrès qui semblent anodins. Il s’avère en réalité qu’il peut être assez difficile de faire des progrès cohérents dans l’ensemble de l’entreprise. Il s’agit également de comprendre comment appliquer des choses que nous savons bien faire, comme évaluer la façon dont les fournisseurs utilisent nos données à de nouveaux problèmes comme l’IA, sans nécessairement réinventer la roue. J’ai vu des cas où ils pensaient ne pas savoir comment l’évaluer et refusaient tout simplement. Mais nous savons en fait comment poser des questions sur les diagrammes de flux de données, les modèles de menaces et la sécurité des fournisseurs. Ce sont des choses que nous faisons depuis des décennies et il s’agit simplement de les appliquer à un nouveau cadre et à un nouveau contexte.

THB : En avril, il y a eu un incident de découverte de porte dérobée dans le référentiel XZ qui aurait pu affecter des millions d’ordinateurs Linux. Il s’est avéré qu’il y avait un ingénieur, ne faisant pas partie de l’équipe de sécurité, qui était simplement curieux et qui a pu sauver la situation. Quels sont les enseignements tirés de cette affaire ?

MH : La bonne nouvelle, c’est que la sécurité est devenue plus coopérative et qu’elle doit continuer à être collaborative, en particulier lorsque les équipes de sécurité travaillent en étroite collaboration avec les ingénieurs pour comprendre leur travail, le soutenir et rendre la sécurité aussi simple que possible. Je pense, tout comme l’entreprise, que la sécurité commence par le développeur. Vous voulez tout construire pour le maintenir en sécurité et lui permettre de prendre facilement de bonnes décisions en matière de sécurité. De plus, les organisations qui intègrent du code tiers ou du code open source dans leurs logiciels, même si elles ne l’ont pas écrit, en assument toujours les conséquences en termes de sécurité. Elles doivent donc être responsables de la manière dont elles l’utilisent.

Ici, comme le code était open source, il a permis au développeur qui étudiait le problème de l’identifier. Mais nous avons besoin de meilleures capacités en tant qu’écosystème plus large pour investir dans la sécurité de la chaîne d’approvisionnement en logiciels.

THB : Des incidents comme ceux-ci créent-ils un sentiment de peur ?

MH : Je pense que c’est certainement possible à certains endroits. C’est pourquoi il est important d’examiner attentivement les enseignements tirés de cas comme celui-ci. Pour de nombreux incidents de ransomware, il vous suffit de mieux détecter cette vulnérabilité, pour laquelle de nombreuses organisations ne sont pas douées. De nombreux incidents de phishing et campagnes de piratage de compte nous indiquent que nous avons encore un long chemin à parcourir en tant qu’industrie pour amener les gens à adopter des technologies d’authentification sécurisées telles que les deux facteurs et les mots de passe. GitHub s’efforce d’aider les développeurs à favoriser l’adoption et à résoudre de tels problèmes.