Faire contrôler la sécurité d'un incrément, avec des preuves vérifiables sans être expert

Quand l’employer

À employer sur un incrément déjà livré, avec un agent distinct de celui qui l'a construit. À ne pas employer comme audit général du produit : une revue sans périmètre rend une liste que personne ne traite.

Les 5 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{INCREMENT_A_CONTROLER}

Quel incrément est contrôlé, et quels fichiers a-t-il touchés ?

Pourquoi ce trou existe. Une revue sans périmètre produit une liste interminable où le point grave se noie parmi les remarques de style.

Si vous ne savez pas répondre. Reprenez la liste des fichiers touchés que vous avez exigée à la livraison. Si vous ne l'avez pas, c'est cette exigence qui manque, pas la revue.

{DONNEES_EN_JEU}

Quelles données cet incrément lit, écrit ou transmet, et lesquelles sont personnelles ?

Pourquoi ce trou existe. Le risque se mesure à la donnée touchée. Un même défaut est bénin sur un catalogue public et grave sur un dossier médical.

Si vous ne savez pas répondre. Listez les informations affichées à l'écran par cet incrément. Si l'une d'elles permet de reconnaître une personne, la réponse est oui.

{QUI_PEUT_Y_ACCEDER}

Qui devrait pouvoir utiliser cette fonctionnalité, et qui ne devrait pas ?

Pourquoi ce trou existe. Sans réponse écrite, le contrôle ne peut pas conclure : il ne saura pas si un accès constaté est voulu ou accidentel.

Si vous ne savez pas répondre. Écrivez la liste des profils autorisés. Tous les autres, y compris un visiteur non connecté, sont réputés interdits.

{CE_QUI_SERAIT_GRAVE}

Qu'est-ce qui, arrivant demain, serait grave pour vous ou pour vos utilisateurs ?

Pourquoi ce trou existe. Le classement par gravité vient de vous, pas de l'agent. Ce que vous ne pouvez pas assumer commande l'ordre de traitement.

Si vous ne savez pas répondre. Prenez trois scénarios concrets : une donnée personnelle rendue publique, une action faite au nom de quelqu'un d'autre, une perte de données sans sauvegarde.

{ENVIRONNEMENT}

Ce code tourne-t-il déjà avec de vraies données, ou seulement en essai ?

Pourquoi ce trou existe. Un défaut identique n'appelle pas la même urgence selon qu'il existe sur un banc d'essai ou devant de vrais utilisateurs.

Si vous ne savez pas répondre. Si vous ne savez pas répondre, traitez-le comme s'il était en service : c'est l'hypothèse la moins coûteuse à se tromper.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es spécialiste de la sécurité applicative, et tu contrôles le travail d'un autre. Ton mandat est de me remettre des constats que je peux vérifier moi-même sans être développeur. Je ne te demande pas un avis : un avis ne se contrôle pas. Je te demande des faits, chacun accompagné du moyen de le voir de mes yeux.

## 2. CONTEXTE FACTUEL

Incrément contrôlé et fichiers touchés : {INCREMENT_A_CONTROLER}
Données lues, écrites ou transmises : {DONNEES_EN_JEU}
Profils autorisés, tous les autres étant interdits : {QUI_PEUT_Y_ACCEDER}
Ce qui serait grave pour moi : {CE_QUI_SERAIT_GRAVE}
État de mise en service : {ENVIRONNEMENT}

Tu ne modifies aucun fichier pendant ce contrôle. Une revue qui corrige au passage détruit la preuve de ce qu'elle a trouvé.

## 3. DEMANDE BORNÉE

Contrôle ces six points, dans cet ordre, et aucun autre.

1. Secrets : y a-t-il, dans les fichiers touchés, une clé, un mot de passe, un jeton ou une adresse de connexion écrits en clair ?
2. Accès : qui peut réellement déclencher cette fonctionnalité, y compris un visiteur non connecté, et cela correspond-il aux profils autorisés ?
3. Entrées : ce que l'utilisateur saisit est-il contrôlé avant d'être utilisé, et que se passe-t-il quand il saisit autre chose que ce qui était prévu ?
4. Erreurs : existe-t-il un endroit où une erreur est attrapée puis ignorée sans trace, faisant croire au succès ?
5. Traces : les informations écrites dans les journaux contiennent-elles des données personnelles ou des secrets ?
6. Sorties : quelles données quittent le produit vers un tiers, et lesquelles pourraient rester chez moi ?

Ce que je ne veux pas : un septième point, une recommandation d'outil, une correction appliquée, un renvoi vers une norme sans dire ce qu'elle exige ici, un avis global sur la qualité du code.

## 4. FORMAT DE SORTIE EXIGÉ

Un tableau à cinq colonnes, une ligne par point contrôlé : point, verdict, fichier et ligne, extrait recopié tel quel, ce que je fais pour le constater moi-même en moins de deux minutes.

Le verdict est l'un de ces trois mots exactement : conforme, non conforme, non vérifiable. « Non vérifiable » est un verdict légitime et tu dois dire ce qu'il te manquerait. Aucun autre mot n'est accepté, en particulier aucune nuance du genre « globalement correct ».

Sous le tableau, la liste des points non conformes classés par gravité selon ce que je t'ai dit être grave pour moi, avec pour chacun une phrase sur ce qu'un tiers mal intentionné pourrait en faire.

Ta réponse est refusable si un verdict n'est pas l'un des trois mots, si un constat n'a pas de fichier et de ligne, ou si un point est déclaré conforme sans que je puisse le constater moi-même.

Ce que vous devez recevoir

• Un tableau à cinq colonnes couvrant les six points, dans l'ordre demandé.
• Un verdict pris parmi trois mots exactement : conforme, non conforme, non vérifiable.
• Un chemin de fichier et un numéro de ligne pour chaque constat.
• L'extrait de code recopié tel quel, jamais paraphrasé.
• Pour chaque ligne, la manipulation qui vous permet de constater vous-même, en moins de deux minutes.
• Les non conformités classées selon la gravité que vous avez définie, pas selon celle de l'agent.
• Pour chaque « non vérifiable », ce qu'il manquerait pour conclure.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• Un verdict est nuancé (« globalement sûr », « acceptable ») au lieu d'être l'un des trois mots.
• Un point est déclaré conforme sans fichier, sans ligne et sans manipulation de contrôle.
• L'agent affirme qu'un secret n'est pas exposé sans montrer où la valeur est réellement lue.
• Un extrait de code est reformulé au lieu d'être recopié, ce qui empêche la comparaison.
• La réponse renvoie à une norme ou à un outil au lieu de dire ce qui est vrai dans ce code.
• L'agent a corrigé un problème pendant la revue, effaçant la preuve de son existence.
• Les erreurs avalées sont signalées sans dire comment provoquer l'erreur pour le voir.

Selon pour qui vous construisez

Pour moi.

Faites la revue avec un agent neuf, dans une conversation vide. Un agent qui a construit le code défend ce qu'il a écrit, sans intention de tromper.

Pour mon employeur.

Les constats non conformes touchant des données personnelles sont transmis à la personne responsable de la conformité le jour même, même si la correction attend.

Pour un client.

Le tableau daté est conservé. Il prouve que le contrôle a eu lieu, ce qui est exactement la question qui vous sera posée si un incident survient.