En commençant « de gauche à gauche » : le code sécurisé est-il toujours un code de qualité ?

Une version de cet article a été publiée dans Lecture sombre. Il a été mis à jour et diffusé ici.

Lorsque je parle de sécurité aux développeurs, l'un de mes mantras est que « le seul code de qualité est un code sécurisé ». Cela reste vrai ; nous aurions peut-être échappé à la catastrophe lorsque des logiciels vulnérables sont apparus dans la nature dans les années 90, mais le risque n'en vaut pas la peine aujourd'hui. Beaucoup ont travaillé d'arrache-pied pour inculquer aux développeurs un état d'esprit soucieux de la sécurité au fil des ans et, ce faisant, ils ont, espérons-le, fait de la sécurité un synonyme de qualité lorsqu'il s'agit d'auto-évaluer leur code.

Après réflexion (et après quelques débats entre pairs), cela simplifie peut-être trop le concept. Il est tout à fait possible de créer un code qui soit effectivement sécurisé, mais qui présente des signes de technique de développement novice ou d'autres problèmes qui le rendent loin d'être idéal.

Notre industrie parle longuement de la notion de « glissement vers la gauche ». À mon avis, il s'agit de « repartir » vers la gauche en permettant aux cohortes d'ingénieurs de partager la responsabilité de la sécurité (en tant qu'aspect de la qualité) et en leur donnant le pouvoir d'effacer les vulnérabilités courantes du bout des doigts (littéralement). À la lumière de cette énigme actuelle, il semble toutefois que les limites doivent être repoussées un peu plus loin.

Un code d'un certain niveau de qualité est par définition également sécurisé, mais tout code sécurisé n'est pas nécessairement de bonne qualité. Commencer « à gauche de gauche » est-il la formule pour garantir des normes de codage purement sécurisées ?

À quoi ressemble un code sécurisé « de mauvaise qualité » ?

Passons la loupe à la loupe à cet extrait de code :

Si nous analysons ce code du point de vue de la sécurité, cet extrait est en effet sécurisé et ne constitue pas un point d'entrée permettant à un attaquant d'exploiter une vulnérabilité d'injection SQL.

S'agit-il d'un exemple de code de haute qualité ? Pas vraiment, malheureusement. Une simple modification de l'argument d'un int (entier) à un Corde value permet à l'utilisateur de saisir librement la requête, contrairement à un nombre qui ne le peut pas. Ce changement, ou un copier-coller aléatoire de la chaîne sql depuis un autre endroit, crée immédiatement un environnement dans lequel des vulnérabilités d'injection SQL sont possibles, avec tous les risques qui y sont associés :

Les mesures de sécurité avaient une portée très limitée ici, alors qu'un développeur plus minutieux (ou expérimenté) aurait peut-être adopté une approche différente et envisagé les implications d'une structure d'arguments inefficace. Un code d'expédition comme celui-ci n'est pas seulement une mauvaise pratique, mais aussi un mauvais exemple pour les autres membres de la cohorte de développement.

La « triple menace » logicielle : forme, fonction, forteresse ?

Une « triple menace » dans l'industrie du divertissement est une personne capable de jouer, de danser et de chanter avec un niveau de compétence tout aussi élevé. Ce sont les personnes redoutées et enviées à chaque audition, et ce sont les licornes d'un espace déjà compétitif. Chaque secteur possède sa propre version d'un exemple exceptionnel de ses produits et services, les logiciels ne faisant pas exception.

Si nous pensons à trois éléments clés des applications qui sont difficiles à équilibrer avec une qualité (élevée) égale, ils peuvent être la fonctionnalité et l'élégance, une sécurité irréprochable et la rentabilité compte tenu de la rapidité de livraison requise. Ce dernier attribut est sans aucun doute un facteur déterminant dans la manière dont les deux autres options sont appliquées, et il peut être le catalyseur d'une baisse de la qualité globale au fil du temps.

Cependant, tous les logiciels doivent-ils fonctionner comme Hugh Jackman, ou pouvons-nous nous en tirer avec Nicolas Cage ? En d'autres termes, si vous pouvez intégrer Wolverine dans votre équipe, vous faites de votre mieux.

Martin Fowler a posé la question, La haute qualité en vaut-elle le coût ? dans le développement de logiciels, en concluant que non seulement cela « en valait la peine », mais que cela coûtait en fait moins cher au fil du temps. La plupart des utilisateurs ne vont pas regarder sous le capot pour déterminer si le code est un gâchis ou si la sécurité a été accordée à tout le reste. Cependant, les utilisateurs des outils perdront un temps précieux à refaire du code bâclé pour ajouter de nouvelles fonctionnalités, à parcourir les principales parties du projet pour comprendre ce qui se passe, ou, dans le pire des cas, à corriger une vulnérabilité qui a été rebondie par l'équipe AppSec et a retardé la production. Passer du temps maintenant à rendre le code à la fois sécurisé et de bonne qualité permet d'éviter bien des soucis futurs, sans parler des coûts liés à la résolution de tâches mal exécutées.

Les développeurs expérimentés soucieux de la sécurité écrivent du code qui conserve leur vision créative et leur capacité à résoudre les problèmes lors de la fourniture de fonctionnalités, en veillant à éliminer les pièges de sécurité courants que les ingénieurs peuvent contrôler à leur stade du processus. Le code sécurisé n'est pas très efficace lorsqu'il est isolé, et c'est pourquoi l'idée de commencer « de gauche à gauche » contribuera à promouvoir une culture de la sécurité considérée comme une seconde nature pour les développeurs, intégrée à leur capacité à fournir des fonctionnalités exceptionnelles avec un risque réduit.

Pour une expérience utilisateur sécurisée, il est essentiel de commencer « de gauche à gauche ».

La sécurité est prise en compte dans l'expérience utilisateur des logiciels depuis longtemps, mais elle s'est clairement soldée par un succès mitigé. Erreurs de configuration de sécurité prises en compte 21 % des violations de données basées sur le cloud au cours de l'année écoulée, des erreurs commises par des amateurs, telles que le stockage de mots de passe en texte clair, ont entraîné de graves pertes de productivité, de revenus et de confiance des clients pour les entreprises concernées.

Cela, et les utilisateurs eux-mêmes peuvent être leur pire ennemi lorsqu'il s'agit de protéger leurs propres données. Beaucoup trop de monde utilisent toujours « mot de passe » comme mot de passe, ou utilisent la même combinaison sur plusieurs comptes sensibles.

Je ne connais aucun développeur qui fasse preuve de souplesse lorsqu'on leur demande de travailler sur un écran de connexion, et ce n'est pas étonnant : concevoir un flux de sécurité robuste et fonctionnel dans lequel les utilisateurs pourront naviguer de la manière qui leur convient le mieux, avec le moins de perturbations possible, est un équilibre délicat.

Si vous introduisez trop d'étapes et de restrictions complexes, les utilisateurs risquent de se déconnecter pour ne jamais revenir (ce qui est un désastre pour une nouvelle application), de créer trop de confusion, et vous pourriez finir par donner à l'équipe d'assistance une migraine collective lorsqu'elle répondra aux questions des utilisateurs qui tentent d'accéder à leur compte. Si vous le faites trop facilement, vous échouerez en quelque sorte sur le plan de la sécurité.

Une expérience utilisateur sécurisée réussie doit intégrer une sécurité renforcée dans un flux logique, présenté de manière à ne pas nuire à tout ce qui est convaincant à propos du logiciel. Vous pouvez certainement atteindre l'objectif qui consiste à coder une fonction de connexion sécurisée, en introduisant toutes sortes de mots de passe complexes, un CAPTCHA, des mini-boss et quatre vagues de zombies, mais s'il s'agit d'un désordre total qui repousse les utilisateurs, c'est passer à côté de la cible.

Jeter les bases de l'excellence logicielle.

En tant que développeur, je sais que la grande majorité d'entre nous sont fiers de notre travail et veulent faire le bon choix. Les aléas tels que les contraintes de temps, les changements brusques de l'objectif actuel ou les correctifs urgents peuvent perturber le flux et entraîner des erreurs, mais la dure vérité est que de nombreux ingénieurs logiciels ne sont pas prêts à réussir.

Commencer « de gauche à gauche » est un concept qui donne la priorité aux développeurs et qui oblige les organisations à sérieusement améliorer leur cohorte d'ingénieurs. Les développeurs sensibilisés à la sécurité valent leur pesant d'or, et le soutien sous forme de formation, de fourniture des bons outils et de la possibilité d'être encadré par des développeurs plus expérimentés favorisera un environnement dans lequel le code est conçu avec une approche axée sur la sécurité, avec la précision et l'attention aux détails nécessaires pour faire passer les logiciels au niveau supérieur.

Êtes-vous prêt à allumer le feu du codage sécurisé en vous ? Relevez le défi.

‍