Comment GitHub stimule le développement de logiciels sécurisés
En tant que premier responsable de la sécurité de GitHubs, Mike Hanley a la tâche gigantesque de superviser tout ce qui concerne la sécurité dans l’ensemble de l’organisation, de la sécurité informatique et de la conformité de l’entreprise à la sécurité de sa plate-forme, sur laquelle des millions de développeurs s’appuient pour collaborer et créer des logiciels chaque jour.
Sa nomination plus tôt cette année intervient également à un moment où les menaces pour la sécurité augmentent au milieu de la pandémie, y compris l’attaque sophistiquée SolarWinds qui aurait été menée par des acteurs étatiques qui avaient subverti l’environnement de construction du logiciel pour injecter du code malveillant.
Sous sa responsabilité, GitHub a mené des efforts pour renforcer l’adoption des meilleures pratiques de sécurité parmi les développeurs et les organisations, en s’appuyant sur l’approche de l’entreprise en matière de sécurité axée sur les développeurs.
Dans une interview de grande envergure avec Computer Weekly, Hanley partage son point de vue sur ce que le paysage des cybermenaces signifie pour les développeurs, ce qu’il faut pour créer des logiciels sécurisés et ses priorités pour l’année à venir.
Comment la pandémie a-t-elle changé le paysage des développeurs avec les exigences croissantes en matière d’informatique et de travail à distance ?
Hanley: À un niveau élevé, il y a eu quelques tendances intéressantes qui remodèlent le paysage des développeurs. Tout d’abord, évidemment, avec Covid-19 et nous travaillant tous à domicile, vous ne pouvez plus vous rendre au bureau de quelqu’un pour voir sur quoi il travaille ou lui parler de la façon dont vous implémentez une fonctionnalité. Nous avons complètement changé cette situation maintenant, nous dépendons donc plus que jamais des outils de collaboration à distance pour faire notre travail, rester connectés à nos équipes et coordonner le développement.
Cela signifie que la plate-forme et les outils que nous utilisons doivent être en mesure de prendre en charge un trafic accru, avec des fonctionnalités et des fonctionnalités supplémentaires pour garantir que l’expérience de collaboration sur une plate-forme est encore meilleure que ce que vous pourriez obtenir en personne. Ce qui est bien, c’est que GitHub a été conçu pour des équipes très distantes et distribuées. Si vous pensez à la communauté open source, elle a toujours été distribuée et vous avez toujours des personnes travaillant ensemble du monde entier pour créer des logiciels ensemble.
Nous étions bien préparés à mettre en place une infrastructure pour soutenir les changements qui se produisent dans l’écosystème qui nous entoure. Nous pensons qu’avec le développement croissant du cloud, il est impératif de pouvoir accéder aux talents en ligne à travers le monde. GitHub se penche beaucoup sur la façon dont nous pouvons faciliter l’idée que le développement se déplace vers le cloud avec des éléments tels que les espaces de code, mais également l’intégration de fonctionnalités et de capacités supplémentaires dans le produit.
Nous avons également vu des attaques sophistiquées très médiatisées comme l’incident de SolarWinds. Que pensez-vous de ces types d’attaques et comment les développeurs doivent-ils être préparés à y faire face ? Certaines solutions ont été proposées, telles que la demande d’une nomenclature logicielle et l’activation de constructions reproductibles.
Hanley: Je pense que beaucoup des projets que vous venez de mentionner sont très importants pour renforcer la confiance dans l’écosystème logiciel plus large qui a été secoué par le volume sans précédent d’attaques de la chaîne d’approvisionnement.
Dans le même temps, bien que nous puissions continuer à investir et à travailler ensemble sur ces projets avec l’écosystème communautaire plus large, GitHub, par exemple, est récemment devenu un sponsor principal de l’Open Source Security Foundation, les développeurs ont beaucoup de choses qu’ils peuvent utiliser pour protéger l’écosystème.
Un exemple est l’activation de l’authentification multifacteur (MFA) pour leur compte GitHub, et nous avons fait beaucoup de travail pour assurer la sécurité du compte sur GitHub.com et la façon dont les gens interagissent avec les fonctionnalités se fait en toute sécurité. À votre avis, les attaquants sont assez sophistiqués et ont souvent de grandes équipes qui effectuent ces attaques.
Ensemble, ils recherchent des endroits faciles d’accès qui aideront à prévenir l’attribution. Si vous laissez la porte d’entrée de votre maison déverrouillée et que vous n’avez pas de caméras autour, il est assez facile pour quelqu’un d’utiliser simplement la porte d’entrée ou de faire tout ce qu’il faut pour entrer, comme mettre une échelle contre le côté de la maison ou percer un trou dans le toit.
De même, pour les comptes qui n’ont pas de MFA en place, je peux pulvériser un mot de passe ou hameçonner le titulaire du compte pour qu’il se mette directement à la porte d’entrée de la maison. Cela rend beaucoup plus difficile pour moi d’être attribué. Les adversaires, étant des acteurs rationnels, essaient juste de faire le travail, et ils chercheront des moyens faciles de se fondre dans ce genre de choses, ce qui est malheureusement trop courant.
Donc, vraiment aider à piloter les bases de choses comme une bonne sécurité et une bonne hygiène du compte rend beaucoup plus difficile pour les attaquants de prendre le contrôle du compte de quelqu’un. Par extension, si vous travaillez dans une organisation, qu’il s’agisse d’un projet open source ou d’une organisation d’entreprise, obliger les participants ou les responsables à utiliser MFA pour contribuer aux projets est une autre mesure de sécurité que vous pouvez déployer.
DevSecOps
L’une des choses dont on a beaucoup parlé ces dernières années a été cette idée de DevSecOps. Quelles sont vos pensées à ce sujet? Certains pensent que la sécurité devrait de toute façon faire partie de DevOps, puis il y a l’autre groupe qui pense qu’avoir la sécurité dans le terme met l’accent sur la nécessité d’avoir des équipes de sécurité dans les équipes DevOps.
Hanley: Je pense que vous avez fait remarquer à juste titre que c’est un débat philosophique auquel les gens souscrivent. Quelle que soit la voie empruntée par les gens, ce que je pense est vrai, c’est que que vous l’appeliez DevSecOps, ou DevOps avec une fonction de sécurité distincte ou un autre cycle de vie de développement logiciel avec un modèle de sécurité en place, je reviens toujours à la hiérarchie des besoins en matière de sécurité. pyramide publiée par Forrester il y a plusieurs années.
Au bas de la pyramide, il y a trois choses qui me paraissent les plus importantes. L’une est votre stratégie de sécurité en termes de ce que vous essayez de protéger et comment, et la seconde consiste à développer un vivier de talents pour exécuter cette stratégie. Le troisième concerne les pratiques et les politiques.
Près du sommet de la pyramide, il y a toutes sortes de choses que les gens poursuivent parfois trop rapidement avant d’avoir une stratégie en place. Grâce à la formation et à l’acquisition des meilleurs talents pour exécuter cette stratégie, vous pouvez vous adapter à n’importe quel modèle, que vous croyiez en DevSecOps ou en un autre modèle de développement logiciel auquel vous souscrivez.
Voyez-vous les équipes de sécurité rester séparées de beaucoup d’équipes de développement ?
Hanley: Oui, je le fais, et cela varie selon l’organisation. Personnellement, je trouve que la plupart des meilleurs travaux de sécurité se déroulent dans les équipes d’ingénierie. Ma philosophie personnelle, et la façon dont nous le faisons au sein de GitHub, est que même si j’ai une grande équipe bien dotée en ressources, notre objectif est de fournir d’excellents résultats avec nos partenaires des équipes d’ingénierie via un modèle de partenaire de sécurité.
Et nous intégrons des équipes pour nous assurer qu’elles peuvent se concentrer sur la construction de choses. Nous sommes là pour prendre en charge chaque phase du cycle de vie de la conception et les exigences de sécurité qui doivent être intégrées, depuis les tests, le déploiement et l’exploitation sécurisée d’un service. Cela peut sembler être un modèle DevSecOps selon certaines définitions, mais mon approche concerne l’équipe de sécurité permettant aux équipes d’ingénierie d’être des super-héros de la sécurité.
Initiatives liées à l’automatisation
Pourriez-vous nous en dire plus sur les initiatives liées à l’automatisation que GitHub mène pour alléger la pression sur les équipes de développement et de sécurité ?
Hanley: L’exemple que la plupart des gens connaissent est l’analyse secrète, qui traite d’un modèle de développeur commun où par commodité, ou parce que vous êtes au milieu de votre travail, le moyen le plus simple de faire le travail est de simplement valider le secret dans le code.
Parfois c’est intentionnel, parfois ce n’est pas le cas, mais c’est sans ambiguïté une pratique dangereuse ou non sécurisée d’avoir fait cela. GitHub a intégré cela directement dans le flux afin que nous puissions le signaler pour vous. Nous travaillons avec des dizaines de partenaires pour invalider ces secrets, vous protégeant de cette erreur si vous le faites dans un référentiel public, par exemple.
Un autre exemple plus proche des développeurs qui écrivent du code au quotidien est notre technologie d’analyse de code basée sur CodeQL. Nous travaillons avec la communauté open source, l’industrie et la communauté de recherche pour apporter des requêtes qui ajoutent de la valeur à l’analyse de code à nos clients et aux projets open source qui l’utilisent.
Contribuaient à empêcher les gens d’envoyer un défaut logiciel en premier lieu parce que nous apprenons du corpus de mauvais modèles connus, des soumissions de bug bounty ou des choses que les gens nous ont signalées. Nous nous sommes fortement concentrés sur le fait de continuer à développer la prise en charge des langues pour ce produit et d’augmenter la densité des requêtes qui sont intégrées dans chaque langue que nous prenons en charge.
L’objectif est de permettre aux développeurs de se concentrer sur ce qu’ils veulent faire, c’est-à-dire créer des fonctionnalités et des capacités. Nous aidons à rendre la partie sécurité de cela aussi simple que possible, donc c’est en quelque sorte leur donner la cape de super-héros de la sécurité même s’ils n’ont pas une expertise et une expérience approfondies dans le domaine.
Attaques contre les systèmes OT
Avec l’augmentation significative du nombre d’attaques contre les systèmes de technologie opérationnelle (OT), vos clients qui exploitent des systèmes OT utilisent-ils GitHub de quelque manière que ce soit pour relever les défis auxquels ils sont confrontés ?
Hanley: J’ai en fait parlé à certains clients au cours des dernières semaines qui travaillent avec des systèmes embarqués et OT. La nature générale de certaines de ces conversations est que dans de nombreux cas, les contraintes sont vraiment liées au cycle de vie du matériel auquel ils doivent faire face.
Par exemple, vous pourriez avoir un appareil d’usine qui a une durée de vie de 25 ans, et vous êtes donc fortement limité par les capacités qui vous ont été livrées il y a 10 à 15 ans.
Il existe des défis uniques associés au modèle matériel, mais ce n’est qu’un commentaire généralisé sur certains des défis qui existent là-bas. Le développement de logiciels et de micrologiciels pour ceux-ci peut se faire sur GitHub, comme tout autre projet logiciel. Mais je pense que l’espace OT a spécifiquement de nombreux défis associés aux cycles de vie du matériel.
Priorités pour aller de l’avant
Quelles sont vos priorités pour l’année prochaine ?
Hanley: GitHub est un acteur clé pour aider à maintenir la confiance et la sécurité de l’écosystème open source. Comme vous le savez, la plupart des logiciels open source vivent sur GitHub et c’est un grand privilège pour nous de pouvoir héberger ces formidables projets et communautés.
Cela s’accompagne également d’une grande responsabilité, car nous devons nous assurer de protéger la plate-forme, de créer un espace sûr pour que les personnes puissent travailler sur des projets et de faciliter la sécurité des développeurs. Il peut être difficile pour les développeurs qui n’ont pas d’expérience en sécurité d’atteindre les résultats et les objectifs de sécurité qui leur tiennent à cœur. Ainsi, les flux de travail et les outils que nous fournissons sur GitHub rendent ces capacités largement disponibles pour les clients et les développeurs open source et le faire d’une manière qui est dans le contexte et conforme à la façon dont ils développent des logiciels est très important.
Nous nous sommes également concentrés sur la façon dont nous pouvons aider les gens à adopter de meilleures pratiques de sécurité. Nous avons récemment abandonné l’authentification par mot de passe uniquement pour les opérations Git, mais nous recherchions également des moyens de favoriser l’adoption de l’authentification MFA sur les comptes GitHub.com et de donner aux organisations plus de visibilité sur la posture de sécurité de leurs référentiels.
Nous cherchons également à aider les gens à mieux retracer leurs dépendances et à fournir de meilleures données dans la base de données consultative GitHub afin que les gens puissent prendre des décisions plus éclairées concernant leur exposition à une dépendance vulnérable. C’est le genre de choses sur lesquelles nous voulons continuer à nous concentrer et doubler parce qu’elles auront un impact substantiel sur l’ensemble de l’écosystème si nous faisons ces choses correctement.