Commencer "à gauche de la gauche" : Un code sûr est-il toujours un code de qualité ?

Une version de cet article a été publiée dans Lecture sombre. Elle a été mise à jour et publiée 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ûr". Cela reste vrai ; nous avons peut-être échappé à un désastre lorsque des logiciels vulnérables étaient utilisés dans la nature dans les années 90, mais le jeu n'en vaut pas la chandelle aujourd'hui. Nombreux sont ceux qui ont travaillé dur pour inculquer aux développeurs un état d'esprit axé sur la sécurité au fil des ans et, ce faisant, ont, je l'espère, fait de la sécurité un synonyme de qualité lorsqu'il s'agit d'une autoassessment de leur code.

Toutefois, après réflexion (et débat entre mes pairs), il s'agit peut-être d'une simplification excessive du concept. Il est tout à fait possible de créer un code qui soit effectivement sûr, mais qui présente des signes de techniques de développement novices ou d'autres problèmes qui le rendent moins qu'idéal.

Notre industrie parle beaucoup de la notion de "déplacement vers la gauche". Dans mon esprit, il s'agit de "commencer" à gauche en permettant aux ingénieurs de partager la responsabilité de la sécurité (qui est un aspect de la qualité) et en leur donnant le pouvoir d'éliminer les vulnérabilités courantes du bout de leurs doigts (littéralement). À la lumière de l'énigme actuelle, cependant, il semble que l'enveloppe doive être poussée un peu plus loin.

Un code d'un certain niveau de qualité est, par définition, également sûr, mais tout code sûr n'est pas nécessairement de bonne qualité. Commencer "à gauche de la 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 sur 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 pirate 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, qui passe d'un int(eger) à une chaîne de caractères, permet à l'utilisateur de manipuler la requête à l'aide d'une saisie libre, contrairement à un nombre qui ne peut pas l'être. Ce changement - ou un copier-coller désordonné de la chaîne sql depuis un autre endroit - crée immédiatement un environnement dans lequel les vulnérabilités d'injection SQL sont possibles, avec tous les risques qui y sont associés :

Les mesures de sécurité avaient ici une portée très limitée, alors qu'un développeur plus minutieux (ou plus expérimenté) aurait pu adopter une approche différente et prendre en compte les implications d'une structure d'arguments inefficace. L'envoi de code comme celui-ci n'est pas seulement une mauvaise pratique, c'est aussi un mauvais exemple pour les autres membres de la cohorte de développement.

Le logiciel "triple menace" : Forme, fonction, forteresse ?

Dans l'industrie du spectacle, une "triple menace" est une personne qui peut jouer, danser et chanter avec un niveau de compétence tout aussi élevé. Ces personnes sont craintes et enviées à chaque audition et sont les licornes d'un espace déjà compétitif. Chaque secteur a sa propre version d'un exemple exceptionnel de ses produits et services, les logiciels ne faisant pas exception à la règle.

Si nous pensons à trois éléments clés des applications qui sont difficiles à équilibrer avec une qualité égale (élevée), il pourrait s'agir de la fonctionnalité/élégance, d'une sécurité à toute épreuve et d'un bon rapport coût-efficacité si l'on considère la vitesse 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 être aussi performants que Hugh Jackman, ou pouvons-nous nous contenter de Nicolas Cage ? En d'autres termes, si vous pouvez intégrer Wolverine dans votre équipe, vous devez donner le meilleur de vous-même.

Martin Fowler a posé la question suivante : " La haute qualité vaut-elle le coût ?" dans le domaine du développement de logiciels, et a conclu que non seulement elle "en valait la peine", mais qu'elle était en fait moins coûteuse au fil du temps. La plupart des utilisateurs ne vont pas regarder sous le capot pour évaluer si le code est en désordre, ni si la sécurité a été rendue aussi importante que le reste. Cependant, ceux qui travaillent sur les outils perdront un temps précieux à refaire du code bâclé pour ajouter de nouvelles fonctionnalités, ou à parcourir des parties importantes du projet pour comprendre ce qui se passe, ou, dans le pire des cas, à corriger une vulnérabilité qui a rebondi sur l'équipe AppSec et qui a retardé la production. Passer du temps maintenant pour rendre le code à la fois sûr et de bonne qualité permet d'éviter bien des maux de cœur à l'avenir, sans parler du coût du démêlage d'un travail mal exécuté.

Les développeurs compétents en matière de sécurité écrivent un code qui conserve leur vision créative et leur capacité à résoudre les problèmes lors de la livraison des fonctionnalités, en tenant compte de l'élimination des pièges courants en matière de sécurité que les ingénieurs peuvent contrôler à leur stade du processus. Un code sécurisé n'est pas terriblement efficace s'il est isolé, et c'est pourquoi la notion de commencer "à gauche de la gauche" contribuera à soutenir une culture de la sécurité comme une seconde nature pour les développeurs, intégrée dans leur capacité à fournir des fonctionnalités étonnantes avec un risque réduit.

Commencer "à gauche de la gauche" est essentiel pour assurer la sécurité de l'utilisateur.

Depuis longtemps, la sécurité est prise en compte dans l'expérience des utilisateurs de logiciels, mais elle a manifestement donné lieu à des résultats mitigés. Les erreurs de configuration en matière de sécurité ont été à l'origine de 21 % des violations de données basées sur l'informatique en nuage au cours de l'année écoulée. Les erreurs commises par des amateurs, comme le stockage de mots de passe en clair, ont entraîné de graves pertes de productivité, de revenus et de confiance de la part des clients pour les entreprises concernées.

De plus, les utilisateurs eux-mêmes peuvent être leur pire ennemi lorsqu'il s'agit de protéger leurs propres données. Beaucoup trop de gens utilisent encore le mot de passe "password" ou la même combinaison pour plusieurs comptes sensibles.

Je ne connais aucun développeur qui saute de joie lorsqu'on lui dit qu'il doit travailler sur un écran de connexion, et ce n'est pas étonnant : c'est un équilibre délicat que de concevoir un flux de sécurité qui soit robuste et fonctionnel, et que les utilisateurs puissent naviguer d'une manière qui leur paraisse logique, avec le moins de perturbations possible.

Si vous introduisez trop d'étapes et de restrictions complexes, les utilisateurs risquent de ne plus revenir (un désastre pour une nouvelle application). Si vous rendez les choses trop confuses, vous risquez de donner une migraine collective à l'équipe d'assistance qui doit répondre aux questions des utilisateurs qui tentent d'accéder à leurs comptes. Si vous rendez les choses trop faciles, vous échouez 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é rigoureuse dans un flux logique, présenté d'une manière qui ne porte pas atteinte à tout ce qui fait l'attrait du logiciel. Vous pouvez certainement atteindre l'objectif de coder une fonction de connexion sécurisée, en mettant en place toutes sortes d'exigences en matière de mots de passe complexes, de CAPTCHA, de mini-boss et de quatre vagues de zombies, mais s'il s'agit d'un désordre total qui rebute les utilisateurs, c'est que vous avez raté le coche.

Posez les bases de l'excellence en matière de logiciels.

En tant que développeur, je sais que la grande majorité d'entre nous est fière de son travail et veut faire ce qu'il faut. Des obstacles tels que les contraintes de temps, les changements soudains de l'objectif en cours ou les correctifs urgents peuvent perturber le flux et conduire à des erreurs, mais la dure vérité est que de nombreux ingénieurs logiciels ne sont pas préparés à la réussite.

Commencer "à gauche de la gauche" est un concept de développeur d'abord, et exige des organisations qu'elles prennent au sérieux l'amélioration de 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, la fourniture des bons outils et la possibilité d'être encadrés par des développeurs plus expérimentés favoriseront un environnement où le code est conçu avec un état d'esprit axé sur la sécurité, avec la précision et l'attention aux détails nécessaires pour faire passer le logiciel au niveau supérieur.

Prêt à allumer en vous la flamme du codage sécurisé ? Relevez le défi.

‍