Sécuriser dès la conception

1. La sécurité dans le projet

AUne demande d’Anaïs

Lundi 19 octobre 2026. Les spécifications du module de maintenance préventive de KerMaint ont été validées le 16 octobre par Franck Guillou, responsable technique des bâtiments de Kervanet (SLAM-01, ticket VEL-2026-4203). Le devis du 19 octobre attend la signature de Kervanet.

Anaïs Lecoq, responsable du pôle développement de Vellacor, réunit Sarah Cherif, alternante SLAM, et Romain Daguet, développeur :

« Les spécifications disent ce que le module doit faire, très peu ce qu’il ne doit pas permettre. Avant de coder, je veux les exigences de sécurité, une analyse des menaces et la liste de ce que nous vérifierons à la recette. Sarah s’en charge, Romain relira. »

BPourquoi dès la conception

Une faille découverte en production coûte cher : comprendre, corriger, tester, redéployer, parfois informer la CNIL. Et si personne n’a prévu de contrôler qui peut modifier un plan, personne ne le codera. L’OWASP le résume (Top 10:2025) : une implémentation parfaite ne répare pas une conception non sûre, car les contrôles nécessaires n’ont jamais été prévus.

On distingue deux types de défauts :

• un défaut de conception : le contrôle nécessaire n’existe pas dans le modèle (aucune règle ne limite la modification des plans au responsable) ;
• un défaut d’implémentation : le contrôle est prévu, mais mal codé (la règle existe, mais le code oublie de la vérifier sur une des pages).

Ce chapitre traite surtout des premiers ; les seconds sont l’objet de B3SLAM-02 et B3SLAM-03.

CLa sécurité à chaque étape

La sécurité n’est pas une phase à part : chaque étape du développement reçoit ses propres activités.

En Scrum, ces activités se répètent à chaque sprint (B1-10).

2. Écrire les exigences de sécurité

AD’où viennent les exigences

Les exigences de sécurité d’un projet ne s’inventent pas : elles se déduisent de cinq sources.

S’y ajoute la modélisation des menaces de la partie 3 : elle fait apparaître des exigences que personne n’avait formulées.

BUne exigence vérifiable

Une exigence floue (« le module doit être sécurisé ») ne sert à rien : on ne peut ni la coder ni la tester. Une bonne exigence de sécurité a les mêmes qualités qu’une exigence non fonctionnelle de SLAM-01 : elle est précise, vérifiable, justifiée et identifiée.

CLes exigences dans les récits utilisateur

En agilité, les besoins s’écrivent en récits utilisateur avec des critères d’acceptation (SLAM-01). La sécurité s’y intègre de deux façons.

1. Des critères d’acceptation négatifs. À chaque récit, on ajoute au moins un scénario qui doit échouer : droit insuffisant, valeur hors limite, donnée d’un autre établissement.

2. Des récits d’attaquant. Un cas d’abus (misuse case, ou récit d’attaquant) décrit ce qu’une personne malveillante, ou simplement maladroite, voudrait faire avec l’application : « En tant que technicien pressé, je veux marquer « conforme » un contrôle sans l’avoir fait, afin de finir ma tournée plus vite. » On ne réalise pas ce récit : on écrit les exigences qui l’empêchent ou qui le rendent visible (traçabilité EXS-03, durée minimale saisie, relecture par le responsable).

DLes exigences dans le cahier des charges

Dans un projet plus classique, le cahier des charges comporte une section « Exigences de sécurité », numérotée comme les autres. Elle sert de base au contrat (obligation de conseil du prestataire, CEJMA-03) et à la recette : une exigence non satisfaite est une réserve au procès-verbal.

3. Modéliser les menaces

AQuatre questions

La modélisation des menaces (threat modeling) se fait sur la conception, avant le code, et se refait à chaque évolution importante. Elle répond à quatre questions simples :

1. Que construit-on ? On représente l’application : ses utilisateurs, ses traitements, ses données, ses échanges.
2. Que peut-il mal se passer ? On cherche les menaces, élément par élément.
3. Que fait-on contre chaque menace ? On choisit une mesure, qui devient une exigence (partie 2).
4. A-t-on bien travaillé ? On vérifie que chaque menace retenue a une mesure, un responsable et un test.

BLe diagramme de flux de données

Pour répondre à la première question, on dessine un diagramme de flux de données (data flow diagram, DFD). Il n’utilise que quatre symboles :

• les entités externes (rectangles) : personnes ou systèmes hors de l’application (le technicien, la messagerie) ;
• les traitements (formes arrondies) : les parties de l’application qui transforment les données ;
• les stockages (deux traits) : bases, fichiers, journaux ;
• les flux (flèches) : les données qui circulent.

S’y ajoutent les frontières de confiance, en pointillés.

CLes six familles STRIDE

STRIDE est une grille proposée par Microsoft pour ne rien oublier : chaque lettre désigne une famille de menaces, et chaque famille s’attaque à une propriété de sécurité.

DSTRIDE appliqué au module

Sarah et Romain passent une heure sur le schéma. Ils retiennent huit menaces et les évaluent avec les échelles de Vellacor (B3-01 : gravité et vraisemblance de 1 à 4, criticité = gravité × vraisemblance).

E1 reçoit la vraisemblance 3 parce qu’un oubli de contrôle sur une seule page suffit ; I1, parce qu’un journal de débogage resté actif a déjà fait tomber KerMaint le 7 octobre (B1-06). Toutes les menaces sont au moins modérées : aucune n’est acceptée sans mesure.

4. Concevoir de façon sûre

ALe moindre privilège dans l’application

Le moindre privilège (B3-05) s’applique aussi aux comptes que l’application utilise elle-même : le compte de base kermaint_app lit, ajoute et modifie, sans pouvoir supprimer de table ni gérer les droits ; la tâche nocturne ne fait que lire les plans et créer des interventions ; le jeton d’une plateforme partenaire de KerResa ne donne accès qu’aux opérations de son contrat (B3SLAM-03) ; le serveur web n’écrit que dans les dossiers prévus, jamais dans le code.

Question à poser pour chaque composant : « S’il était compromis, que ferait l’attaquant avec ses droits ? »

BLa défense en profondeur

La défense en profondeur (définie en B3-04 pour les postes) s’applique aussi à l’intérieur d’une application : une requête traverse plusieurs contrôles indépendants, et aucun ne suppose que le précédent a fonctionné.

Exemple : même si la validation laissait passer une valeur étrange, la requête préparée (B1-08) l’empêcherait d’être interprétée comme du SQL ; même si une requête SQL était détournée, le compte limité empêcherait de supprimer une table.

CLa sécurité par défaut et l’échec sûr

Sarah code la matrice des droits du module en liste blanche : ce qui n’est pas écrit est interdit. La règle RG8 de SLAM-01 devient une ligne de la matrice.

<?php
declare(strict_types=1);

// Matrice des droits du module (liste blanche) : ce qui n'est pas écrit est interdit
const DROITS = [
    'Technicien'  => ['voir_echeances', 'saisir_controle'],
    'Responsable' => ['voir_echeances', 'saisir_controle', 'gerer_plan', 'exporter_registre'],
];

function peutFaire(?string $profil, string $action): bool
{
    // Refus par défaut : profil absent, inconnu ou action non listée
    return in_array($action, DROITS[$profil] ?? [], true);
}

function autoriser(callable $lireProfil, string $action): bool
{
    try {
        return peutFaire($lireProfil(), $action);
    } catch (Throwable $e) {
        error_log('contrôle des droits impossible : ' . $e->getMessage());
        return false;                 // en cas d'erreur, on refuse (échec sûr)
    }
}

Résultats relevés le 20/10/2026 sur la machine de laboratoire LAB-UBU01 (Ubuntu 24.04 LTS, PHP 8.3) :

Responsable  gerer_plan        autorisé
Technicien   gerer_plan        refusé
Technicien   saisir_controle   autorisé
Consultation voir_echeances    refusé
(aucun)      voir_echeances    refusé
Responsable  supprimer_plan    refusé
annuaire en panne, gerer_plan : refusé

Le profil Consultation, qui n’apparaît pas dans la matrice du module, est refusé sans qu’on ait eu à l’écrire ; une action oubliée (supprimer_plan) aussi ; et quand la lecture du profil échoue, la réponse est « non ».

La gestion complète des habilitations dans le code (profils rattachés à la session, contrôle de l’objet consulté) est traitée en B3SLAM-03.

DValider les entrées

B1-08 t’a appris à contrôler un formulaire côté serveur avec filter_var. Du point de vue de la conception, trois idées s’ajoutent.

1. Valider à la frontière, au même endroit. Toute donnée qui franchit une frontière de confiance (formulaire, paramètre d’adresse, appel d’API, fichier importé) passe par une couche de validation commune ; le reste du code ne manipule que des valeurs validées.

2. Normaliser avant de valider. Une même information peut s’écrire de plusieurs façons (espaces superflus, caractère accentué codé de deux manières en Unicode) : on la ramène d’abord à une forme canonique unique, puis on la contrôle.

3. Valider par liste blanche. On décrit ce qui est autorisé (valeurs d’une liste, format, intervalle, longueur), plutôt que d’essayer d’énumérer ce qui est interdit, et l’on refuse les champs non prévus. Ce dernier point empêche l’affectation de masse (mass assignment) : un utilisateur qui ajoute à sa requête un champ actif=0 ne doit pas pouvoir désactiver un plan par ce biais.

La fonction de Sarah pour la création d’un plan (extrait : les contrôles 2 et 3 ne sont pas reproduits) :

<?php
declare(strict_types=1);

const CHAMPS_PLAN = ['id_equip', 'libelle', 'periodicite', 'premiere_echeance'];
const PERIODICITES = [1, 3, 6, 12];          // RG2 : périodicité en mois

function normaliserTexte(string $texte): string
{
    $texte = Normalizer::normalize($texte, Normalizer::FORM_C);   // forme Unicode unique
    return trim(preg_replace('/\s+/u', ' ', $texte));            // espaces uniformisés
}

function validerPlan(array $entree): array
{
    $erreurs = [];
    // 1. Refuser tout champ non prévu (pas d'affectation de masse)
    $inconnus = array_diff(array_keys($entree), CHAMPS_PLAN);
    if ($inconnus !== []) {
        $erreurs['_'] = 'Champ non prévu : ' . implode(', ', $inconnus);
    }
    // 2 et 3. Identifiant d'équipement (entier >= 1) et libellé normalisé (3 à 60 caractères,
    //        sans caractère de contrôle) : contrôles sur le même modèle, non reproduits ici
    // 4. Périodicité : valeur de la liste blanche seulement
    $per = filter_var($entree['periodicite'] ?? null, FILTER_VALIDATE_INT);
    if ($per === false || !in_array($per, PERIODICITES, true)) {
        $erreurs['periodicite'] = 'Périodicité : 1, 3, 6 ou 12 mois.';
    }
    // 5. Date au format ISO 8601 (AAAA-MM-JJ), qui existe vraiment
    $d = DateTimeImmutable::createFromFormat('!Y-m-d', (string) ($entree['premiere_echeance'] ?? ''));
    if ($d === false || $d->format('Y-m-d') !== ($entree['premiere_echeance'] ?? '')) {
        $erreurs['premiere_echeance'] = 'Date au format AAAA-MM-JJ.';
    }
    if ($erreurs !== []) {
        return [null, $erreurs];
    }
    return [['id_equip' => $id, 'libelle' => $libelle, 'periodicite' => $per,
             'premiere_echeance' => $d->format('Y-m-d')], []];   // valeurs propres et typées
}

Le jeu d’essai, relevé sur LAB-UBU01 le 20/10/2026 :

A correct         : accepté {"id_equip":12,"libelle":"Entretien annuel chaudière","periodicite":12,"premiere_echeance":"2026-11-16"}
B periodicite 2   : refusé {"periodicite":"Périodicité : 1, 3, 6 ou 12 mois."}
C date 31/11      : refusé {"premiere_echeance":"Date au format AAAA-MM-JJ."}
D champ en trop   : refusé {"_":"Champ non prévu : actif"}
E id negatif      : refusé {"id_equip":"Équipement invalide."}
avant : false (10 et 11 octets)
après : true

Le cas A montre la normalisation (espaces retirés, identifiant converti en entier) ; le cas C, qu’une date doit exister ; le cas D, le refus d’un champ non prévu. Les deux dernières lignes montrent pourquoi normaliser : « chaudière » peut s’écrire avec un « è » en un seul caractère (10 octets) ou avec un « e » suivi d’un accent combinant (11 octets) ; sans forme canonique, deux libellés identiques à l’écran seraient différents pour le programme (doublons, contrôles d’unicité contournés).

EGérer les erreurs sans fuite

Une erreur mal gérée fait deux dégâts : elle renseigne l’attaquant (nom de la base, requête, chemins des fichiers, versions) et elle peut laisser l’application dans un état incohérent (une opération à moitié faite). L’OWASP a créé en 2025 une catégorie dédiée à ce problème (partie 7).

Voici ce qu’il ne faut pas faire (extrait d’un prototype, à ne pas reproduire) :

// À NE PAS FAIRE : erreurs affichées et message technique renvoyé à l'utilisateur
ini_set('display_errors', '1');
try { /* ... */ } catch (PDOException $e) { echo 'Erreur : ' . $e->getMessage(); }

Le message d’une exception de base de données révèle souvent le compte, le serveur ou la requête. Sarah écrit un gestionnaire de dernier recours, chargé par chaque page :

<?php
declare(strict_types=1);

// Réglages de production : rien d'interne n'est affiché, tout est journalisé
ini_set('display_errors', '0');
ini_set('log_errors', '1');

const JOURNAL = __DIR__ . '/kermaint_erreurs.log';   // en production : /var/log/kermaint/

function journaliser(string $reference, Throwable $e): void
{
    $ligne = sprintf("%s ref=%s %s: %s (%s:%d)\n",
        gmdate('Y-m-d\TH:i:s\Z'), $reference, get_class($e),
        str_replace(["\r", "\n"], ' ', $e->getMessage()),   // une ligne par erreur
        basename($e->getFile()), $e->getLine());
    file_put_contents(JOURNAL, $ligne, FILE_APPEND | LOCK_EX);
}

// Gestionnaire de dernier recours : toute exception non traitée arrive ici
set_exception_handler(function (Throwable $e): void {
    $reference = bin2hex(random_bytes(4));          // relie l'écran au journal
    journaliser($reference, $e);
    if (PHP_SAPI !== 'cli') {
        http_response_code(500);
    }
    echo "Une erreur est survenue. Merci de réessayer plus tard.\n";
    echo "Si le problème persiste, communique au support la référence $reference.\n";
});

On simule un refus de connexion de la base (LAB-UBU01, 20/10/2026). Ce que voit l’utilisateur :

Une erreur est survenue. Merci de réessayer plus tard.
Si le problème persiste, communique au support la référence 5b1235b6.

Ce qu’enregistre le journal, lisible par les seuls administrateurs :

2026-10-20T21:03:45Z ref=5b1235b6 RuntimeException: SQLSTATE[HY000] [1045] Access denied for user 'kermaint_app'@'localhost' (using password: YES) (test_erreurs.php:6)

La référence aléatoire relie l’appel de l’utilisateur à la ligne du journal, sans rien révéler. L’heure est en temps universel (Z), pour recouper plusieurs serveurs (B3-07). Les retours à la ligne sont remplacés : une donnée ne peut pas fabriquer une fausse ligne de journal.

FGarder les secrets hors du code

Un secret est une information qui donne un accès : mot de passe de base de données, clé d’API, jeton d’une plateforme partenaire, secret HMAC des notifications de KerResa (B3-06), clé de signature des livraisons. B1-08 a posé la première règle : les paramètres de connexion sont hors de la racine web, et le mot de passe n’est jamais dans le dépôt. La conception sûre va plus loin.

Chez Vellacor, le mot de passe du compte kermaint_app est rangé dans le gestionnaire de secrets et fourni au serveur sous forme de variable d’environnement, définie dans un fichier de configuration du service lisible par le seul administrateur. Le code se contente de la lire :

<?php
declare(strict_types=1);

// Les secrets ne sont jamais dans le code : ils viennent de l'environnement du serveur,
// alimenté depuis le gestionnaire de secrets (une valeur différente par environnement).
function secret(string $nom): string
{
    $valeur = getenv($nom);
    if ($valeur === false || $valeur === '') {
        // Sécurité par défaut : sans secret, l'application refuse de démarrer
        throw new RuntimeException("Configuration incomplète : variable $nom absente.");
    }
    return $valeur;
}

function parametresBase(): array
{
    return [
        'dsn'          => 'mysql:host=localhost;dbname=kermaint;charset=utf8mb4',
        'utilisateur'  => 'kermaint_app',
        'mot_de_passe' => secret('KERMAINT_DB_PASSWORD'),
    ];
}

Sur LAB-UBU01, sans puis avec la variable (valeur fictive Exemple-2026!) :

démarrage refusé : Configuration incomplète : variable KERMAINT_DB_PASSWORD absente.
configuration chargée pour kermaint_app (mot de passe de 13 caractères, non affiché)

GUn code modulaire et robuste

Un code organisé, lisible et prévisible est plus facile à vérifier, donc plus sûr.

5. Protéger les données dès la conception

ACe que dit l’article 25

Tu connais le principe (art. 25 RGPD, à jour au 20/10/2026, CEJMA-08) : le responsable du traitement (Kervanet) protège les données dès la conception et par défaut (seules les données nécessaires, en quantité, étendue, durée et accessibilité). Vellacor, sous-traitant, l’y aide : son obligation de conseil lui interdit de livrer une application impossible à rendre conforme (CEJMA-08).

Pour le développeur, la question devient : quels réglages, quels champs, quels droits ma conception impose-t-elle par défaut ?

BDu principe aux choix de conception

CLes droits des personnes dans l’application

Les personnes concernées (clients, salariés) peuvent accéder à leurs données, les faire rectifier, effacer, limiter, s’opposer à un traitement ou les récupérer (CEJM-14). Kervanet doit répondre dans un délai d’un mois, et Vellacor exécute la partie technique sous 5 jours ouvrés (B3-02). Ces délais ne peuvent être tenus que si l’application a été conçue pour les droits.

Chaque droit devient donc un récit (« En tant qu’administrateur fonctionnel, je veux exporter toutes les données d’un client… ») avec ses critères d’acceptation : une fonction à développer et à tester. L’exécution technique d’une demande est décrite en B3-02.

DLa sécurité par défaut dans les textes

6. Sécuriser la chaîne de développement

ALes maillons de la chaîne

Chaque maillon a son risque : poste compromis, secret versionné, bibliothèque vulnérable ou piégée, code fusionné sans relecture, archive remplacée, recette nourrie de données réelles. L’ANSSI (« Les essentiels — DevSecOps », v1.0, février 2024) recommande notamment un gestionnaire de secrets par environnement et aucun secret en dur dans le code, les dépôts ou les journaux, des dépendances réduites, évaluées et corrigées avant déploiement, l’authentification multifacteur sur les dépôts, des environnements séparés et des livraisons signées.

BGérer les dépendances

KerMaint utilise des bibliothèques PHP installées par le gestionnaire de dépendances Composer. Deux fichiers comptent :

• composer.json déclare les bibliothèques voulues et les versions acceptables (contraintes, par exemple « 6.4 ou plus, mais pas 7 ») ;
• composer.lock enregistre les versions exactes installées. Il est versionné dans le dépôt : chaque environnement installe exactement les mêmes versions, celles qui ont été testées.

La commande composer audit (Composer 2.8.12 du laboratoire) compare les versions aux avis de sécurité publiés (--locked : d’après composer.lock ; --no-dev : sans les outils de développement) et renvoie le code 1 en cas de problème, ce qui permet de bloquer un pipeline.

Le pôle développement complète ce contrôle par sa politique de délais : une fois un avis publié, le composant doit être mis à jour en 7 jours si la faille est critique, 30 jours si elle est élevée, 90 jours si elle est moyenne et 180 jours si elle est faible. Pour suivre aussi les avis de sa veille (bulletins des éditeurs, avis du CERT-FR, B3SISR-03), Sarah a écrit un court programme PHP qui lit composer.lock, compare chaque version installée à la version corrigée de chaque avis (fonction version_compare, qui sait que 6.4.10 est postérieure à 6.4.3, ce qu’une comparaison de textes ne garantit pas), calcule l’âge de l’avis et le compare au délai de la politique, puis renvoie le code 1 s’il reste un composant à corriger.

Résultat sur la branche du module le 20/10/2026 (LAB-UBU01 ; les noms de composants et les numéros d’avis sont ceux de l’inventaire et de la veille internes de Vellacor) :

AVIS-2026-0117  exemple/rapport-pdf    6.4.1   À METTRE À JOUR en 6.4.3 (élevée, avis de 15 j, délai 30 j : reste 15 j)
AVIS-2026-0098  exemple/planificateur  2.3.2   corrigé (>= 2.3.2)
AVIS-2026-0121  exemple/journal-psr    3.0.2   À METTRE À JOUR en 3.0.4 (critique, avis de 4 j, délai 7 j : reste 3 j)
code retour : 1

La bibliothèque de journalisation passe en priorité (3 jours restants) ; la bibliothèque d’export PDF, utilisée par un écran réservé aux responsables, sera mise à jour avec la livraison mensuelle, dans son délai (B3-07).

Le programme ne voit que les avis publiés, pas les composants plus maintenus : le framework de KerMaint, Symfony 7.3, ne reçoit plus aucun correctif depuis janvier 2026, d’où la migration vers Symfony 7.4, version à support long (SLAM-07). L’inventaire note donc aussi la date de fin de maintenance de chaque composant.

CUtiliser la gestion de version en sécurité

L’outil de gestion de version (Git, avec la forge GitLab chez Vellacor) est un outil de sécurité s’il est bien réglé.

La branche principale est protégée. Dans GitLab, une branche protégée n’accepte pas d’envoi direct (push) : le code n’y arrive que par une merge request (demande de fusion), fusionnée par une personne habilitée. La branche par défaut est protégée automatiquement ; Vellacor a retiré à tous le droit d’y pousser directement.

Les secrets n’entrent pas dans le dépôt. Le fichier .gitignore liste ce qui ne doit jamais être versionné (fichiers .env, configuration locale). Mais .gitignore se contourne d’une simple option : Sarah a ajouté un crochet (hook) pre-commit, un script que Git exécute avant chaque commit sur le poste du développeur.

#!/bin/sh
# .git/hooks/pre-commit : refuse un commit qui ajoute un secret probable
motifs='(mot_de_passe|password|secret|api_key|token)[^=:]{0,20}[=:>]+ *["'"'"'][^"'"'"']{8,}["'"'"']|-----BEGIN [A-Z ]*PRIVATE KEY-----'
if git diff --cached -U0 --diff-filter=AM | grep '^+' | grep -v '^+++' | grep -Eiq "$motifs"; then
    echo "Commit refusé : secret probable dans les lignes ajoutées."
    echo "Range-le dans le gestionnaire de secrets et lis-le par une variable d'environnement."
    exit 1
fi
for f in $(git diff --cached --name-only --diff-filter=AM); do
    case "$f" in
        *.env|*.pem|*.key|config.local.php)
            echo "Commit refusé : le fichier $f ne doit jamais être versionné."
            exit 1 ;;
    esac
done
exit 0

Le motif cherche, dans les lignes ajoutées, un nom évocateur (mot_de_passe, token…) suivi d’une valeur d’au moins 8 caractères entre guillemets, ou un en-tête de clé privée. Essai dans un dépôt de test (LAB-UBU01, Git 2.43, 20/10/2026 ; sortie abrégée aux lignes utiles) :

== commit 1 (secret lu dans l'environnement)
accepté
== commit 2 (mot de passe écrit dans le code)
Commit refusé : secret probable dans les lignes ajoutées.
Range-le dans le gestionnaire de secrets et lis-le par une variable d'environnement.
== git check-ignore -v .env
.gitignore:1:.env   .env
== commit 3 (.env forcé)
Commit refusé : le fichier .env ne doit jamais être versionné.

Le crochet est local et peut être oublié : le contrôle est refait côté serveur, dans le pipeline, par le modèle GitLab de détection de secrets (Jobs/Secret-Detection.gitlab-ci.yml).

DLa revue de code

La revue de code consiste à faire relire chaque modification par un autre développeur avant sa fusion. C’est l’application au développement de la séparation des tâches (B3-05) : celui qui écrit ne valide pas seul.

Dans l’édition gratuite de GitLab utilisée par Vellacor (B1-10), une approbation peut être donnée, mais elle n’est pas bloquante : la règle « une approbation d’un autre développeur avant fusion » est donc une règle d’équipe, contrôlée par Anaïs Lecoq, seule habilitée à fusionner sur la branche principale avec Romain Daguet.

ESéparer les environnements

Développement, recette et production sont des environnements séparés : machines différentes, secrets différents, données différentes. KerMaint est développé sur les postes Linux du pôle, recetté sur KV-RECETTE avec une base anonymisée, exploité sur KV-KERMAINT (B1-11). Les techniques d’isolation, la configuration de production et les tests de sécurité avant mise en production sont traités en B3SLAM-04.

7. Vérifier la conformité à un référentiel

AL’OWASP

L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie librement des documents, des outils et des référentiels sur la sécurité des applications. Ses deux productions les plus utilisées sont présentées ici.

BLe Top 10 de l’OWASP

Le Top 10 classe les dix catégories de risques les plus importantes pour les applications web. L’édition en vigueur au 20/10/2026 est le Top 10:2025 (site top10.owasp.org, consulté le 20/10/2026).

A06 recommande la modélisation des menaces, des exigences de sécurité dans les récits et des tests de cas d’abus ; A10, nouvelle en 2025, regroupe les erreurs mal gérées, les messages trop bavards et les contrôles qui « échouent ouverts ».

CL’ASVS de l’OWASP

L’ASVS (Application Security Verification Standard) est une liste d’exigences de sécurité vérifiables pour les applications web et les API. La version stable au 20/10/2026 est la 5.0.0, publiée en mai 2025 : 345 exigences réparties en 17 chapitres (validation et logique métier, authentification, sessions, autorisation, cryptographie, configuration, protection des données, codage sûr et architecture, journalisation et gestion des erreurs, etc.).

Chaque exigence porte un niveau :

L’ASVS ne dit pas quel niveau viser : l’organisation le choisit d’après ses risques et la sensibilité de l’application. La charte de développement du pôle de Vellacor fixe : L1 pour toute application, L2 pour toute application exposée sur Internet ou traitant des données de clients (KerResa, « Kervanet & Moi »). KerMaint, interne, vise L1, complété d’exigences L2 choisies d’après la modélisation des menaces.

Une exigence se cite avec la version : v5.0.0-2.2.1 désigne l’exigence 1 de la section 2 (validation des entrées) du chapitre 2 ; la version évite les confusions d’une édition à l’autre.

DLes guides français

En France, l’ANSSI (« Les essentiels — DevSecOps », 2024) et la CNIL (guide RGPD de l’équipe de développement, B3-02) complètent l’OWASP. Cite toujours le titre, la version et la date du document utilisé.

EVérifier la conformité

Vérifier la conformité, c’est confronter l’application, exigence par exigence, au référentiel retenu, et conserver la preuve de chaque réponse.

8. Préparer l’épreuve E7

Erreurs fréquentes et points de vigilance

L’essentiel du chapitre

Sources et références

• Arrêté du 29 avril 2019 portant définition et fixant les conditions de délivrance du BTS « Services informatiques aux organisations », modifié par les arrêtés du 8 juillet 2024 et du 22 novembre 2024 ; référentiel de la fiche RNCP40792 (annexe I.B, bloc 3, partie SLAM, activité B3.5), lu le 20/10/2026.
• OWASP Top 10:2025, site top10.owasp.org (liste des dix catégories, pages A06:2025 « Insecure Design » et A10:2025 « Mishandling of Exceptional Conditions »), consulté le 20/10/2026.
• OWASP, Application Security Verification Standard 5.0.0 (mai 2025), dépôt officiel github.com/OWASP/ASVS (étiquette v5.0.0_release) : chapitre « What is the ASVS » (niveaux) et chapitres V2, V8, V13, V15, V16 lus le 20/10/2026 ; décompte des exigences par niveau fait sur les fichiers de la version 5.0.0.
• Microsoft Learn, « Threat Modeling Tool threats » (STRIDE), consulté le 20/10/2026.
• ANSSI, « Les essentiels — DevSecOps », version 1.0 (février 2024 ; page de messervices.cyber.gouv.fr publiée le 13/03/2024), consulté le 20/10/2026 ; ANSSI, « Recommandations pour la mise en œuvre d’un site web : maîtriser les standards de sécurité côté navigateur », v2.0, page publiée le 28/04/2021, consultée le 20/10/2026.
• Règlement (UE) 2024/2847 du 23 octobre 2024 (cyberrésilience), art. 2, art. 3 (définitions 13 et 22), art. 71, considérants 12, 15, 16 et 64, annexe I, partie I, lus sur EUR-Lex le 20/10/2026 et le 21/10/2026 ; page « Cyber Resilience Act » de la Commission européenne (mise à jour le 07/09/2026), consultée le 20/10/2026. Règlement (UE) 2016/679 (RGPD), art. 25 : voir CEJMA-08 (lu sur EUR-Lex le 20/10/2026).
• Documentations consultées le 20/10/2026 : GitLab Docs (« Merge request approvals », « Protected branches », « Pipeline secret detection ») ; Composer (ligne de commande, audit, rôle de composer.lock ; aide de Composer 2.8.12) ; PHP-FIG, « PER Coding Style 3.1 ».
• symfony.com, page « Symfony 7.3 » (sortie en mai 2025, fin de maintenance en janvier 2026, statut « non maintenue »), consultée le 21/10/2026.
• Versions des outils de la machine de laboratoire LAB-UBU01 (Ubuntu 24.04.5 LTS) : PHP 8.3.6, Git 2.43.0.
• FuturBTS : B1-06, B1-08, B1-10, B1-11, B3-01 à B3-07, SLAM-01, SLAM-10, B3SLAM-02 à B3SLAM-04, B3SISR-03, CEJM-14, CEJMA-02, CEJMA-03, CEJMA-08.

Contenu original FuturBTS. Vellacor Services Numériques, Kervanet Hôtels & Résidences et les personnes citées sont fictifs ; les noms de composants (exemple/…), les numéros d’avis et les mots de passe montrés sont des valeurs d’exemple sans usage réel. Les produits nommés (PHP, Composer, Git, GitLab) le sont à titre d’exemple. Aucun passage, exemple ou exercice n’est repris d’un manuel existant.