08. Cycle sécurisé et préparation aux certifications

Comprendre le mécanisme

Les domaines publics CSSLP abordent la sécurité sur le cycle de vie : concepts, exigences, architecture, implémentation, vérification, exploitation et chaîne d’approvisionnement. Un cours PHPStan ne couvre qu’une partie de ces compétences. Une préparation sérieuse associe lecture du plan officiel en vigueur, exercices de raisonnement et preuves de pratique ; elle n’utilise pas des banques de questions divulguées.

Raisonner et vérifier

Construisez une matrice exigence, menace, contrôle, preuve et propriétaire. Les types réduisent certaines erreurs de programmation ; les tests négatifs vérifient le comportement ; la revue examine l’autorisation ; le contrôle de dépendances détecte des risques connus dans son périmètre. La CI doit préserver cette distinction et l’exploitation doit fournir un suivi d’incident et de renouvellement. Un score pédagogique ne constitue ni une certification de personne ni un audit complet du produit.

Exigences vérifiables

Le cycle sécurisé commence dès les exigences. Les choix de conception conditionnent les contrôles possibles. Avant l’implémentation, exprimez la propriété attendue : par exemple aucun client ne lit les factures d’un autre tenant. Déclinez-la en contrôle concret, scénario de refus et preuve conservée avec la release.

Repères de préparation

Les domaines publics CSSLP servent de repère de préparation. Le fournisseur officiel définit son processus de certification. Les domaines publics CSSLP permettent d’organiser conception, développement, vérification et exploitation sécurisés. Utilisez les objectifs publiés et des exercices originaux ; une matrice personnelle aide à repérer les domaines peu travaillés.

Évaluation indépendante

Un QCM indépendant ne reproduit pas l’examen officiel. La mesure pédagogique a un autre périmètre. Les QCM du site entraînent et mesurent une progression locale. Leur score ne délivre aucun titre officiel et ne reproduit ni le contenu confidentiel ni les conditions administratives d’un organisme certificateur.

Chaîne de preuves

Les preuves doivent relier risque et contrôle. Le volume ne montre pas les propriétés vérifiées. Pour chaque menace, notez exigence, contrôle, test, résultat et propriétaire. Un scanner vert ne suffit pas si son périmètre ne contient pas le composant exposé ou la propriété annoncée.

Tests négatifs

Les tests négatifs complètent les tests nominaux. Les frontières doivent être exercées directement. Un scénario nominal prouve qu’un accès autorisé fonctionne. Ajoutez acteur tiers, jeton expiré et entrée malformée en vérifiant l’absence d’effet ; ces refus établissent d’autres frontières que le succès.

Chaîne de dépendances

Les dépendances font partie du cycle de risque. La chaîne d’approvisionnement demande ses propres contrôles. Une bibliothèque et son système de build participent à la surface d’attaque. Verrouillez versions, révisez mises à jour et évitez d’exécuter du code non fiable avec les secrets d’une pipeline privilégiée.

Après déploiement

L’exploitation inclut surveillance et réponse à incident. Le système évolue et peut subir des incidents. Définissez surveillance, triage et réponse à incident avant la panne. Les journaux doivent être utiles sans exposer les credentials ; les procédures de rotation et restauration doivent être exercées.

Lacunes déclarées

Un dossier doit annoncer les lacunes restantes. L’assurance doit rester proportionnée aux preuves. Une propriété non testée doit rester visible dans le dossier. Assignez un traitement et un délai au risque résiduel ; masquer l’absence de preuve derrière un score élevé empêche une décision éclairée.

Questions originales

Les questions confidentielles ne sont pas nécessaires à la préparation. Les plans publics et exercices originaux suffisent à guider l’étude. Préparez-vous avec documentation publique, cas pratiques et questions authored pour le cours. L’apprentissage doit porter sur les mécanismes et leur application, sans rechercher de banques confidentielles d’examen officiel.

Responsabilité du risque

Chaque risque doit avoir un traitement et un propriétaire. Le suivi opérationnel ne se résume pas au score. Un risque sans propriétaire reste facilement sans suite. Désignez qui accepte, corrige ou surveille chaque risque et précisez le signal qui doit déclencher une nouvelle évaluation.

Atelier guidé : lire, expliquer et vérifier le code

# Périmètre de l’exercice : seule cette commande est exécutée.
script:
  - vendor/bin/phpstan analyse --no-progress

La pipeline d’exemple exécute uniquement l’analyse statique. Demandez quelle preuve manque pour l’isolation des réservations, puis écrivez un test à deux acteurs sur le même objet. Associez ce test à une menace explicite et à un responsable, sans attribuer au typage une propriété qu’il ne mesure pas.

Le bloc existe dans l’extrait. La politique d’objet demande des tests et une revue dédiés. La commande le montre bien. Le chemin est explicite.

Travail pratique : Établissez un dossier de préparation pour l’API de synthèse : trois risques, contrôles associés, preuves et lacunes restantes.

Critères de correction : Joignez configuration versionnée, résultat d’analyse, tests de refus, revue de droits et procédure d’incident. Reliez chaque pièce à une exigence et à un domaine du plan public. Consultez le fournisseur de certification pour ses conditions et modalités en vigueur.

CI : exécuter un fork sans lui donner les secrets de déploiement

pull_request_target s’exécute dans un contexte qui peut disposer de privilèges du dépôt cible. Si le workflow checkout le commit non fiable d’un fork puis lance ses tests, ce code peut contenir des scripts capables de lire secrets et credentials du job.

Séparez les tests de code non approuvé dans un contexte sans secrets et sans droits d’écriture. Réservez publication et déploiement à une chaîne de confiance explicite. La séparation doit aussi considérer les artefacts transmis : un job privilégié ne doit pas exécuter aveuglément un script ou un binaire produit par le job non fiable.

Testez les permissions effectives et les événements autorisés avec des données factices. Réduisez GITHUB_TOKEN aux besoins du job et épinglez les dépendances d’action selon votre politique. Le masquage de logs ne constitue pas une frontière de confidentialité contre un programme qui possède déjà le secret et peut l’envoyer par un autre canal.

Points de vigilance : Le code peut exfiltrer un secret autrement que par son affichage littéral dans les logs. Le nom du workflow et l’extension du fichier ne créent pas de frontière de confiance. Un délai court laisse le temps de détourner un secret ou une permission. La séparation empêche le code non approuvé d’hériter de privilèges de déploiement ; contrôler aussi les artefacts transmis.

Migration Strangler : une seule implémentation propriétaire de l’effet

Une extraction progressive laisse le monolithe et le nouveau service coexister. Définissez une frontière fonctionnelle et un contrat stable, puis routez une cohorte maîtrisée vers une seule implémentation active pour chaque intention de paiement.

La réversibilité doit porter sur les demandes futures et les états que l’ancienne implémentation sait encore comprendre. Elle ne signifie pas pouvoir annuler un débit externe déjà accepté. Évitez un double appel PSP pour comparer les sorties ; utilisez tests de contrat ou comparaison sans effet lorsque cela est réellement possible.

Définissez propriétaire de l’écriture, identité d’opération, compatibilité des messages et procédure de rapprochement pendant la transition. Testez bascule partielle et retour de routage avec états en cours. Les métriques doivent détecter divergence et erreur sans exposer les credentials. Une migration réussie retire progressivement les anciens chemins après preuve ; laisser deux producteurs d’effets en concurrence sans règle claire ajoute une nouvelle source de doublons.

Points de vigilance : La migration incrémentale exige un routage maîtrisé et un propriétaire clair de chaque effet irréversible. La première réponse ne supprime pas l’autre débit éventuellement exécuté. La suppression préalable retire le filet de retour demandé. Des écritures et décisions concurrentes sans propriétaire compliquent les invariants et le retour arrière.