Ce qu'un audit logiciel examine vraiment

On demande un audit logiciel quand quelque chose cloche sans que personne ne sache dire quoi. Les mises en production prennent plus de temps qu'avant, un seul développeur ose encore toucher à un module, une question de sécurité posée par un client a attendu une semaine. L'audit doit remplacer cette impression par une liste. Voici à quoi ressemble cette liste, ce que nous lisons pour l'écrire, et ce que nous ne ferons pas en chemin.

À quoi ressemble le rapport

Le rapport est plus court que la plupart des gens ne l'imaginent. Il a quatre parties.

• Des constats classés par conséquence. Chaque constat dit ce qui se passe si vous ne faites rien, à quel point c'est probable et à peu près ce qu'il faut pour le régler.
• Ce qu'il faut laisser tranquille. Une section du rapport nomme les parties qui vont bien telles quelles, pour que personne ne passe un trimestre à moderniser ce qui n'a jamais été le problème.
• Une première semaine de travail. Les points les moins chers qui retirent le plus de risque, regroupés pour qu'une équipe puisse commencer lundi sans nous.
• Là où notre rôle s'arrête. Le rapport dit ce que nous ferions ensuite si on nous le demandait et ce que votre propre équipe peut prendre en charge. Un bon audit ne se transforme pas en douce en promesse de piloter la mise en œuvre pour toujours.

Il est écrit en langage clair, il vous appartient, et il est rédigé pour que n'importe quelle équipe puisse agir dessus, y compris une équipe qui n'est pas la nôtre.

Ce que nous lisons

Les problèmes logiciels vivent rarement à un seul endroit, donc nous lisons le code et tout ce qui l'entoure. La documentation nous dit ce que les gens voulaient. Le dépôt, l'infrastructure et le flux réel du travail nous disent ce qui s'est passé.

• La structure : comment le système est découpé, où sont les frontières et lesquelles sont encore respectées dans le code.
• Les dépendances : sur quelles bibliothèques et plateformes il repose, lesquelles reçoivent encore des correctifs de sécurité et lesquelles se sont arrêtées sans bruit.
• Les raccourcis : les endroits où quelqu'un a pris la voie rapide sous pression. Tout système en a. La question est de savoir lesquels tiendront et lesquels portent aujourd'hui un poids pour lequel ils n'ont jamais été prévus.
• Une sécurité à la mesure du vrai risque : les mesures qui correspondent à vos données, à vos utilisateurs et aux conséquences d'une fuite. Pas de théâtre sécuritaire, et pas de liste de contrôles copiée d'une banque quand vous faites tourner un outil de planification.
• Pourquoi les mises en production font mal : comment un changement voyage de l'idée à la production, où il attend, ce qui casse en route et ce qui rendrait les livraisons à nouveau prévisibles.

Nous parlons aussi aux personnes qui font le travail avant de mesurer quoi que ce soit. Leurs inquiétudes visent en général le bon symptôme et parfois la mauvaise cause, et l'écart entre les deux est la chose la plus utile qu'un audit puisse trouver.

Deux schémas que nous retrouvons sans cesse

Les détails changent à chaque fois. Les formes reviennent, et deux d'entre elles en disent le plus sur ce à quoi sert un audit.

Le premier est le module que tout le monde veut réécrire. C'est la partie la plus ancienne du système, écrite dans un style que personne ne choisirait aujourd'hui, et elle a l'air de la cible évidente. Puis nous lisons l'historique des modifications et constatons qu'on y a à peine touché depuis des années, qu'elle fait une seule chose et qu'elle la fait sans incident. La recommandation est de la laisser tranquille : l'encapsuler, documenter la seule chose que les gens doivent savoir à son sujet et porter l'attention là où le changement a réellement lieu. Une réécriture coûterait des mois et jetterait ce que le code a déjà appris. La dette technique se mesure à sa conséquence, pas à son âge.

Le second est le système qui tourne sur la chance. Les sauvegardes s'exécutent, mais personne n'en a jamais restauré une. Les administrateurs partagent un seul compte, dont le mot de passe a survécu à deux départs. Une seule personne sait comment se déroule une mise en production, et cette personne prend des vacances. Rien de tout cela n'apparaît comme un bogue. Tout cela se corrige en une semaine de travail : une restauration testée, des comptes personnels avec authentification à deux facteursUne seconde preuve d'identité à côté du mot de passe, comme un code sur un téléphone, pour qu'un mot de passe divulgué n'ouvre pas à lui seul un compte administrateur., une page qui décrit une mise en production. L'audit place cette semaine au-dessus de toute ambition d'architecture dans le rapport, parce qu'elle retire le pire risque pour le moins d'argent.

Ce que nous refusons

• Noter les personnes. Nous jugeons le travail. La plupart des raccourcis étaient des décisions raisonnables dans les contraintes du moment, et un rapport qui distribue les blâmes est un rapport sur lequel personne n'agit.
• Nous recommander par défaut. Si une suite a du sens, nous le disons, et la décision vous appartient. L'avis se suffit à lui-même et peut très bien conclure que vous n'avez besoin de rien de notre part.
• Promettre des résultats. Nos conditions générales précisent que le conseil relève d'une obligation de moyensUn engagement à travailler avec compétence et soin, avec les ressources que la mission exige, sans garantir un résultat donné. Nos conditions générales l'appliquent au conseil, à l'avis et au développement. : nous travaillons avec soin et engageons ce que la mission demande, et nous ne garantissons pas d'issue. Un audit qui promet des mises en production indolores d'ici le printemps vend autre chose qu'un audit.

Avant d'en demander un

Si vous voulez d'abord une première lecture par vous-même, notre bilan de santé logiciel pose vingt questions sur un système en production et se termine par un décompte dont vous pouvez vous servir. Si le décompte vous surprend, ou si les questions auxquelles vous ne savez pas répondre sont celles sur qui détient la connaissance, c'est le moment où un audit prend sa place. Empêcher les constats de revenir est une habitude à part, et nous avons écrit à quoi ressemble cette routine.