Enquête sur le langage Go : les génériques proposés par Go 1.18 ont rapidement été adoptés
Enquête sur le langage Go : les génériques proposés par Go 1.18 ont rapidement été adoptés,
les dépendances tierces sont un problème de sécurité majeur
Go est un langage de programmation compilé et concurrent inspiré de C et Pascal. Développé par Google, Go veut faciliter et accélérer la programmation à grande échelle : en raison de sa simplicité il est donc concevable de l'utiliser aussi bien pour écrire des applications, des scripts ou de grands systèmes. Cette simplicité est nécessaire aussi pour assurer la maintenance et l'évolution des programmes sur plusieurs générations de développeurs.
S'il vise aussi la rapidité d'exécution, indispensable à la programmation système, il considère le multithreading comme le moyen le plus robuste d'assurer sur les processeurs actuels cette rapidité tout en rendant la maintenance facile par séparation de tâches simples exécutées indépendamment afin d'éviter de créer des « usines à gaz ». Cette conception permet également le fonctionnement sans réécriture sur des architectures multicœurs en exploitant immédiatement l'augmentation de puissance correspondante.
Google a mené une enquête auprès des développeurs Go comptant pour le deuxième trimestre 2022. La version de Go qui était alors en disponibilité était Go 1.18 (dont une préversion était disponible en novembre 2021, la version étant en disponibilité générale en mars 2022), Go 1.19 étant sorti en août 2022.
En voici les principaux résultats :
- Les génériques ont été rapidement adoptés. Une grande majorité des répondants savaient que les génériques avaient été inclus dans la version Go 1.18, et environ 1 répondant sur 4 a déclaré avoir déjà commencé à utiliser des génériques dans son code Go. Le commentaire le plus courant concernant les génériques était "merci !", mais il est clair que les développeurs se heurtent déjà à certaines limitations de la mise en œuvre initiale des génériques.
- Le fuzzing est nouveau pour la plupart des développeurs Go. La sensibilisation aux tests fuzz intégrés de Go était beaucoup plus faible que les génériques, et les répondants avaient beaucoup plus d'incertitude quant à la raison ou au moment où ils pourraient envisager d'utiliser les tests fuzz.
- Les dépendances tierces sont un problème de sécurité majeur. Éviter les dépendances avec des vulnérabilités connues était le principal défi lié à la sécurité pour les répondants. Plus généralement, le travail de sécurité peut souvent être imprévu et non récompensé, ce qui implique que les outils doivent respecter le temps et l'attention des développeurs.
- Google reconnaît pouvoir faire mieux lors de l'annonce de nouvelles fonctionnalités. Les participants échantillonnés au hasard étaient moins susceptibles de connaître les dernières versions d'outils Go que les personnes qui ont trouvé l'enquête via le blog Go : « Cela suggère que nous devrions soit regarder au-delà des articles de blog pour communiquer les changements dans l'écosystème Go, soit étendre nos efforts pour partager ces articles plus largement ».
- La gestion des erreurs reste un défi. Suite à la sortie des génériques, le principal défi des répondants lorsqu'ils travaillaient avec Go s'est déplacé vers la gestion des erreurs. Dans l'ensemble, cependant, la satisfaction à l'égard de Go reste très élevée et nous n'avons trouvé aucun changement significatif dans la façon dont les répondants ont déclaré utiliser Go.
Go et la programmation générique
Les génériques peuvent donner des blocs de construction puissants qui permettent de partager du code et de construire des programmes plus facilement. La programmation générique consiste à écrire des fonctions et des structures de données où certains types sont laissés à spécifier ultérieurement. Avec les génériques, il est possible d’écrire une fonction qui opère sur une tranche d'un type de données arbitraire, où le type de données réel n'est spécifié que lorsque la fonction est appelée. Il est également possible de définir une structure de données qui stocke des valeurs de n'importe quel type, le type réel à stocker étant spécifié lorsque qu’une instance de la structure de données est créée.
Bien que les génériques aient des cas d'utilisation clairs, les intégrer proprement dans un langage comme Go est une tâche difficile. L'une des premières tentatives (imparfaite) d'ajouter des génériques à Go remonte à 2010. Il y en a eu plusieurs autres au cours de la dernière décennie. L'équipe de développement de go a publié un Playground de go 1.18 où chacun peut essayer d'exécuter go avec des génériques. Il existe également un compilateur expérimental qui implémente un ensemble minimal de fonctionnalités disponibles sur une branche du dépôt go. Ces deux options sont idéales pour jouer avec les génériques dans Go 1.18. Voici, ci-dessous, un cas d'utilisation.
La fonction uniq a été décrite avec les deux approches de conception possibles. Avec les génériques, elle pourrait être modifiée en func Uniq[T](data []T) []T et appelé avec n'importe quel type tel que :
Code Go : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
L'ajout des génériques à Go ouvrira de nouvelles sortes de solutions, d'approches et de paradigmes, dont un meilleur support de la programmation fonctionnelle. Avec la popularité croissante de la programmation fonctionnelle, un meilleur support de la programmation fonctionnelle et les possibilités qui en découlent ont le potentiel d'attirer des développeurs qui n'auraient pas envisagé d'apprendre Go et d'élargir la communauté.
Envoyé par équipe Go
Qu'est-ce qui empêchait certains développeurs d'utiliser des génériques ? La majorité des répondants appartenaient à l'une des deux catégories. Tout d'abord, 30 % des répondants ont déclaré avoir atteint une limite de l'implémentation actuelle des génériques, comme vouloir des méthodes paramétrées, améliorer l'inférence de type ou activer les types. Les répondants ont déclaré que ces problèmes limitaient les cas d'utilisation potentiels des génériques ou estimaient qu'ils rendaient le code générique inutilement verbeux. La deuxième catégorie impliquait de dépendre de quelque chose qui ne prenait pas (encore) en charge les génériques - les linters étaient l'outil le plus courant empêchant l'adoption, mais cette liste comprenait également des éléments tels que les organisations restant sur une version antérieure de Go ou dépendant d'une distribution Linux qui ne le fournissait pas encore des packages Go 1.18 (26%). Une courbe d'apprentissage abrupte ou un manque de documentation utile a été cité par 12 % des répondants. Au-delà de ces principaux problèmes, les répondants nous ont parlé d'un large éventail de défis moins courants (mais toujours significatifs), comme le montre le tableau ci-dessous. Pour éviter de se concentrer sur des hypothèses, cette analyse n'inclut que les personnes qui ont déclaré utiliser déjà des génériques, ou qui ont essayé d'utiliser des génériques mais ont été bloquées par quelque chose.
L'équipe Go a également demandé aux personnes interrogées qui avaient essayé d'utiliser des génériques de lui faire part de leurs commentaires supplémentaires. Fait encourageant, un répondant sur dix a déclaré que les génériques avaient déjà simplifié leur code ou entraîné moins de duplication de code. La réponse la plus courante était une variante de « merci ! » ou un sentiment général positif (43 % ); à titre de comparaison, seuls 6 % des répondants ont manifesté une réaction ou un sentiment négatif. Reflétant les résultats de la question sur le "plus grand défi" ci-dessus, près d'un tiers des personnes interrogées ont évoqué le fait d'avoir atteint une limitation de la mise en œuvre des génériques par Go. L'équipe Go utilise cet ensemble de résultats pour aider à décider si ou comment certaines de ces limitations pourraient être assouplies.
Sécurité
Suite à la violation de SolarWinds en 2020, la pratique du développement de logiciels en toute sécurité a reçu une attention renouvelée. L'équipe Go a priorisé le travail dans ce domaine, y compris les outils de création d'une nomenclature logicielle (SBOM), les tests fuzz et, plus récemment, l'analyse des vulnérabilités. Pour soutenir ces efforts, cette enquête a posé plusieurs questions sur les pratiques et les défis en matière de sécurité du développement logiciel. L'équipe a spécifiquement voulu comprendre :
- Quels types d'outils de sécurité les développeurs Go utilisent-ils aujourd'hui ?
- Comment les développeurs Go trouvent-ils et corrigent-ils les vulnérabilités ?
- Quels sont les plus grands défis pour écrire un logiciel Go sécurisé ?
Les résultats suggèrent que si les outils d'analyse statique sont largement utilisés (65 % des répondants), une minorité de répondants l'utilisent actuellement pour trouver des vulnérabilités (35 %) ou améliorer la sécurité du code (33 %). Les répondants ont déclaré que les outils de sécurité sont le plus souvent exécutés pendant la période CI/CD (84 %), une minorité affirmant que les développeurs exécutent ces outils localement pendant le développement (22 %). Cela correspond aux recherches supplémentaires sur la sécurité que l'équipe Go a menées, qui ont révélé que l'analyse de sécurité au moment du CI/CD est un backstop souhaité, mais les développeurs ont souvent considéré cela trop tard pour une première notification : ils préféreraient savoir qu'une dépendance peut être vulnérable avant de construire dessus, ou pour vérifier qu'une mise à jour de version a résolu une vulnérabilité sans attendre que CI exécute une batterie complète de tests supplémentaires par rapport à leur Pull Request.
L'équipe a également interrogé les répondants sur leurs plus grands défis liés au développement de logiciels sécurisés. La difficulté la plus répandue était l'évaluation de la sécurité des bibliothèques tierces (57 % des répondants), un sujet que les scanners de vulnérabilité (tels que le dependabot de GitHub ou le govulncheck de l'équipe Go) peuvent aider à résoudre. Les autres principaux défis suggèrent des opportunités pour des outils de sécurité supplémentaires : les personnes interrogées ont déclaré qu'il était difficile d'appliquer systématiquement les meilleures pratiques lors de l'écriture de code et de valider que le code résultant ne présente pas de vulnérabilités.
Les tests fuzz, une autre approche pour augmenter la sécurité des applications, étaient encore assez nouveaux pour la plupart des répondants. Seuls 12% ont déclaré l'utiliser au travail et 5% ont déclaré avoir adopté les outils de fuzzing intégrés de Go. Une question de suivi ouverte demandant ce qui rendait le fuzzing difficile à utiliser a révélé que les principales raisons n'étaient pas des problèmes techniques : les trois premières réponses ont évoqué le fait de ne pas comprendre comment utiliser les tests de fuzz (23 %), un manque de temps à consacrer au fuzzing ou la sécurité plus largement (22 %), et comprendre pourquoi et quand les développeurs pourraient vouloir utiliser les tests fuzz (14 %). « Ces résultats indiquent que nous avons encore du travail à faire pour communiquer la valeur des tests fuzz, ce qui devrait être testé fuzz et comment l'appliquer à une variété de bases de code différentes ».
Une fois que les répondants ont pris connaissance d'une vulnérabilité, la résolution la plus courante consistait à mettre à niveau la dépendance vulnérable (67 %). Parmi les répondants qui ont également discuté de l'utilisation d'un scanner de vulnérabilité (un proxy pour les participants qui discutaient d'une vulnérabilité dans une dépendance tierce), ce chiffre est passé à 85 %. Moins d'un tiers des personnes interrogées ont évoqué la lecture du rapport CVE ou de vulnérabilité (31 %), et seulement 12 % ont mentionné une enquête plus approfondie pour comprendre si (et comment) leur logiciel était affecté par la vulnérabilité.
Que seulement 12 % des personnes interrogées aient déclaré avoir mené une enquête pour déterminer si une vulnérabilité était accessible dans leur code, ou l'impact potentiel qu'elle aurait pu avoir sur leur service, était surprenant pour l'équipe Go. Pour mieux comprendre cela, elle a également examiné ce qui, selon les répondants, était le plus difficile pour répondre aux vulnérabilités de sécurité. Ils ont décrit plusieurs sujets différents dans des proportions à peu près égales, allant de la vérification que les mises à jour des dépendances ne cassent rien à la compréhension de la mise à jour des dépendances indirectes via les fichiers go.mod. Cette liste contient également le type d'investigation nécessaire pour comprendre l'impact ou la cause première d'une vulnérabilité. Cependant, lorsque l'équipe Go se concentre uniquement sur les personnes interrogées qui ont déclaré avoir effectué ces enquêtes, elle constate une corrélation claire : 70 % des personnes interrogées qui ont déclaré avoir effectué une enquête sur l'impact potentiel de la vulnérabilité l'ont citée comme la partie la plus difficile de ce processus. Les raisons comprenaient non seulement la difficulté de la tâche, mais le fait qu'il s'agissait souvent à la fois d'un travail non planifié et non récompensé.
L'équipe Go estime que ces enquêtes plus approfondies, qui nécessitent de comprendre comment une application utilise une dépendance vulnérable, sont essentielles pour comprendre le risque que la vulnérabilité peut présenter pour une organisation, ainsi que pour comprendre si une violation de données ou un autre compromis de sécurité s'est produit. Ainsi, elle a conçu govulncheck pour alerter uniquement les développeurs lorsqu'une vulnérabilité est invoquée, et pointer les développeurs vers les endroits exacts de leur code en utilisant les fonctions vulnérables. Elle espère que cela permettra aux développeurs d'enquêter plus facilement sur les vulnérabilités qui comptent vraiment pour leur application, réduisant ainsi la quantité globale de travail non planifié dans cet espace.
Source : enquête Go
Et vous ?
Que pensez-vous de Go en général ? L'avez-vous déjà utilisé ?
Voir aussi :
Répondre avec citation
Partager