Adopter le « left of left » : un code sécurisé est-il toujours un code de qualité ?

Une version de cet article a été publiée dans Dark Reading. Il a été mis à jour et syndiqué 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 avons peut-être évité le pire lorsque des logiciels vulnérables circulaient dans les années 90, mais cela ne vaut pas le risque aujourd'hui. Beaucoup ont travaillé dur au fil des ans pour inculquer une culture de la sécurité aux développeurs et, ce faisant, ont espéré rendre la sécurité synonyme de qualité lors de l'auto-évaluation de leur code.

Après réflexion (et quelques débats avec 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écurisé, tout en montrant des signes de techniques de développement novices ou d'autres zones problématiques qui le rendent loin d'être idéal.

Notre industrie parle longuement de la notion de « décalage vers la gauche » (shifting left). À mon sens, tout repose sur le fait de « commencer » à gauche en permettant aux équipes d'ingénierie de partager la responsabilité de la sécurité (en tant qu'aspect de la qualité) et en leur donnant le pouvoir d'éliminer les vulnérabilités courantes au bout de leurs doigts. À la lumière de ce dilemme actuel, il semble toutefois nécessaire d'aller un peu plus loin.

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

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

Examinons ce fragment de code à la loupe :

Si nous analysons ce code sous l'angle de la sécurité, ce fragment est effectivement sécurisé et ne constitue pas un point d'entrée permettant à un attaquant d'exploiter une vulnérabilité par injection SQL.

Est-ce un exemple de code de haute qualité ? Malheureusement, pas vraiment. Un simple changement de l'argument, passant d'un int(eger) à une valeur String, permet à une saisie utilisateur libre de manipuler la requête, contrairement à un nombre qui ne le permet pas. Ce changement — ou un copier-coller hasardeux de la chaîne SQL depuis un autre endroit — crée immédiatement un environnement où les vulnérabilités par injection SQL deviennent 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 rigoureux (ou expérimenté) aurait pu adopter une approche différente et prendre en compte les implications d'une structure d'argument inefficace. Livrer un tel code n'est pas seulement une mauvaise pratique, cela donne un mauvais exemple aux autres membres de l'équipe de développement.

Le « triple défi » du logiciel : forme, fonction, forteresse ?

Dans l'industrie du divertissement, un « triple talent » est une personne capable de jouer la comédie, de danser et de chanter avec un niveau d'excellence égal dans chaque discipline. Ce sont les personnes redoutées et enviées lors de chaque audition, les licornes d'un secteur déjà très compétitif. Chaque industrie possède sa propre version de produits et services d'exception, et le logiciel ne fait pas exception à la règle.

Si l'on considère trois éléments clés dans les applications qu'il est difficile d'équilibrer avec une qualité égale (et élevée), il s'agit peut-être de la fonctionnalité/élégance, d'une sécurité à toute épreuve et de la rentabilité, compte tenu de 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 ? Disons les choses ainsi : si vous pouvez avoir Wolverine dans votre équipe, alors donnez tout ce que vous avez.

Martin Fowler a posé la question : La haute qualité vaut-elle son coût ? dans le développement logiciel, concluant que non seulement cela « en valait la peine », mais que c'était en réalité moins coûteux sur le long terme. La plupart des utilisateurs ne vont pas regarder sous le capot pour évaluer si le code est un désordre, ni si la sécurité a été traitée avec autant d'importance 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, à fouiller dans des parties majeures du projet pour comprendre ce qui se passe, ou, pire encore : à corriger une vulnérabilité renvoyée par l'équipe AppSec qui retarde la production. Prendre le temps de rendre le code à la fois sécurisé et de bonne qualité permet d'éviter bien des tourments futurs, sans parler du coût lié à la correction d'un travail mal exécuté.

Les développeurs qualifiés et conscients des enjeux de sécurité écrivent un code qui préserve leur vision créative et leur capacité à résoudre des problèmes lors de la livraison des fonctionnalités, tout en veillant à éliminer les pièges de sécurité courants que les ingénieurs peuvent contrôler à leur niveau. Un code sécurisé n'est pas très efficace s'il est isolé, et c'est pourquoi la notion de « commencer avant le début » aidera à soutenir une culture de la sécurité comme seconde nature pour les développeurs, intégrée à leur capacité à fournir des fonctionnalités incroyables avec un risque réduit.

« Commencer avant le début » est essentiel pour une expérience utilisateur sécurisée.

La sécurité est une considération de longue date dans l'expérience utilisateur des logiciels, mais elle a clairement connu un succès mitigé. Les erreurs de configuration de sécurité ont représenté 21 % des violations de données basées sur le cloud au cours de l'année écoulée, avec des erreurs de débutant comme le stockage de mots de passe en texte clair, entraînant de graves pertes de productivité, de revenus et de confiance des clients pour les entreprises concernées.

De plus, les utilisateurs sont souvent leurs propres ennemis lorsqu'il s'agit de protéger leurs données. Bien trop de personnes utilisent encore « motdepasse » comme mot de passe, ou la même combinaison pour plusieurs comptes sensibles.

Je ne connais aucun développeur qui saute de joie à l'idée de travailler sur un écran de connexion, et ce n'est pas étonnant : concevoir un parcours de sécurité à la fois robuste, fonctionnel et intuitif pour l'utilisateur, tout en minimisant les frictions, est un exercice d'équilibriste.

Ajoutez trop d'étapes complexes et de restrictions, et les utilisateurs risquent de fuir (ce qui est désastreux pour une nouvelle application) ; rendez le processus trop confus, et vous donnerez une migraine collective à votre équipe de support qui devra gérer les demandes d'accès. À l'inverse, si c'est trop simple, vous échouez 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 parcours cohérent, sans nuire à ce qui rend le logiciel attrayant. Vous pouvez certes coder une fonction de connexion sécurisée avec des exigences complexes, des CAPTCHA et des obstacles à n'en plus finir, mais si le résultat est une expérience rebutante, vous manquez votre cible.

Posez les bases de l'excellence logicielle.

En tant que développeur, je sais que la grande majorité d'entre nous est fière de son travail et souhaite bien faire. Les imprévus comme les contraintes de temps, les changements d'objectifs ou les correctifs urgents peuvent perturber le travail et mener à des erreurs, mais la réalité est que beaucoup d'ingénieurs ne sont pas mis dans les meilleures conditions pour réussir.

Le concept « left of left » place le développeur au centre et exige des organisations qu'elles s'investissent réellement dans la montée en compétences de leurs équipes. Les développeurs sensibilisés à la sécurité valent de l'or. La formation, les bons outils et le mentorat favorisent un environnement où le code est conçu avec une approche « sécurité d'abord », avec la précision nécessaire pour hisser le logiciel vers le haut.

Prêt à éveiller votre fibre du code sécurisé ? Relevez le défi.

‍