> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # Programme d’assurance de la sécurité > Comment CaseBender teste les modifications, bloque les régressions de sécurité, protège les artefacts de version et communique aux clients les éléments probants d’assurance. ## Objectif CaseBender étant utilisé par des équipes de sécurité, la sécurité du produit est considérée comme une exigence de mise en production plutôt que comme une liste de contrôle ponctuelle. Le Programme d’assurance de la sécurité associe des workflows de développement protégés, des tests de sécurité automatisés, des contrôles des conteneurs et des dépendances, la provenance des versions, des exceptions documentées et la planification d’évaluations indépendantes. Cette section explique : * quels contrôles s’exécutent automatiquement ; * quels constats bloquent une modification ou une version ; * quels éléments probants chaque contrôle produit ; * comment les exceptions sont encadrées ; * ce que les clients peuvent vérifier de manière indépendante ; et * où s’arrêtent les garanties automatisées. L’assurance de la sécurité réduit les risques ; elle ne prouve pas que le logiciel est exempt de vulnérabilités. Les badges de workflow, rapports d’analyse, SBOM et signatures attestent de contrôles précis : ils ne constituent ni des certifications de sécurité ni des substituts à un test d’intrusion indépendant. ## Vue d’ensemble de l’assurance Les demandes d’extraction vers les branches protégées doivent franchir une porte de sécurité agrégée avant leur fusion. Les secrets, le code source, les dépendances, les licences, l’infrastructure et toutes les images de service sont contrôlés à l’aide d’outils indépendants. Les workflows de publication génèrent des SBOM, des données de provenance, des condensats immuables et des signatures cryptographiques. Les clients peuvent identifier les éléments probants associés à un commit, à un condensat d’image ou à une version. ## Cycle de vie sécurisé des modifications Chaque modification proposée suit le même cycle de vie général : ```text theme={null} Developer change → Pull request → Build and functional checks → Parallel security controls → Aggregate Security Gate → Protected-branch review and merge → Pre-publish image scan → Digest-based publication and signing → Deployment readiness verification → Scheduled reassessment ``` Les contrôles sont volontairement organisés en plusieurs couches. Par exemple, les risques liés aux dépendances sont évalués à la fois au moyen de la base de données d’avis de sécurité du gestionnaire de paquets et de Trivy ; les images de conteneur sont analysées après leur création ; et des contrôles négatifs déterministes vérifient que les outils de détection de secrets et de SAST continuent de rejeter des jeux de test dont la non-conformité est connue. ## Déclenchement des contrôles | Événement | Activité d’assurance | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Demande d’extraction vers `main` ou `production` | Porte de sécurité complète couvrant le code source, les dépendances, les licences, l’IaC, les Dockerfiles et les sept images | | Envoi vers `main` | Porte de sécurité, génération de SBOM et workflows d’artefacts de la branche principale | | Build de conteneur publié | Analyse des vulnérabilités avant publication, capture du condensat immuable, création de la signature et vérification de la signature | | Planification hebdomadaire | Workflow de sécurité complet et analyse authentifiée OWASP ZAP de l’environnement de préproduction lorsque la cible et l’identité de test requises sont configurées | | Mise à jour d’une dépendance | Les mêmes portes de contrôle que pour les demandes d’extraction s’appliquent ; GitHub Dependency Review est également imposé lorsque la licence du dépôt le permet | La définition du workflow, et non cette page, constitue la source technique faisant autorité pour les déclencheurs et la configuration exacte des outils. Les réviseurs autorisés du dépôt peuvent consulter le workflow [Security Scan (en anglais)](https://github.com/casebender/webapp/actions/workflows/security-scan.yml) ; les clients sans accès au dépôt doivent utiliser les éléments probants propres à la version décrits dans le [Guide des éléments probants de sécurité](/fr/security/security-evidence). ## Porte de sécurité bloquant les fusions La porte agrégée Security Gate exige la réussite des jobs suivants pour les demandes d’extraction et les envois : | Contrôle | Périmètre | Condition de blocage | | ---------------------------------------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Gitleaks | Code source actuel et historique Git complet | Motif de secret détecté | | Analyse du système de fichiers par Trivy | Dépôt et manifestes de dépendances | Vulnérabilité HIGH ou CRITICAL non acceptée pour laquelle un correctif est disponible | | Analyse des conteneurs par Trivy | Images des services web, API, ingestion, worker, workflow processor, MISP processor et search sync | Vulnérabilité d’image HIGH ou CRITICAL non acceptée pour laquelle un correctif est disponible | | Hadolint | Les sept Dockerfiles | Violation de la politique relative aux Dockerfiles | | Analyse IaC par Trivy | Dockerfiles et configuration Kubernetes | Mauvaise configuration de sécurité HIGH ou CRITICAL | | Règles de sécurité ESLint | TypeScript et JavaScript de l’application web | Erreur de règle de sécurité | | Semgrep | Règles TypeScript, Next.js, OWASP, d’injection, XSS, de secrets et d’audit de sécurité | Constat de sévérité ERROR ou échec de l’outil d’analyse | | Politique de licences | Dépendances du dépôt | Licence bloquante non approuvée ou rapport incorrect/vide | | `pnpm audit` | Dépendances de production | Avis de sécurité HIGH ou CRITICAL | | Génération de SBOM | Espace de travail complet | Échec de la génération CycloneDX | | Tests des contrôles de sécurité | Jeux de test générés contenant des secrets et du code non sécurisé | L’outil d’analyse ne rejette pas un jeu de test dont la non-conformité est connue | | GitHub Dependency Review | Écart de dépendances de la demande d’extraction, sous réserve de licence | Nouvelle vulnérabilité HIGH/CRITICAL ou licence refusée | Le téléversement des résultats d’analyse peut s’effectuer au mieux lorsque GitHub Code Security n’est pas sous licence, mais l’analyse locale sous-jacente reste bloquante. Les rapports sont également conservés comme artefacts de workflow afin que la porte ne dépende pas de l’ingestion SARIF. ## Tests de sécurité dynamiques Le job DAST hebdomadaire utilise OWASP ZAP sur un déploiement de préproduction dédié. Avant le début des tests actifs, la CI vérifie : 1. que la cible n’est ni une valeur fictive, ni localhost, ni une adresse de bouclage ; 2. que la réponse identifie un déploiement web CaseBender ; 3. que l’identité de test configurée produit une session authentifiée ; et 4. que l’en-tête d’authentification est fourni au moyen de secrets de dépôt masqués. L’analyse effectue des tests actifs authentifiés et conserve son rapport. L’absence de cible ou d’identifiants entraîne l’échec du job DAST, au lieu de lancer silencieusement une analyse sur une page non pertinente. La couverture DAST est limitée aux routes et aux états accessibles à l’identité de test. Elle ne remplace pas les tests manuels portant sur les autorisations, l’isolation des tenants, le détournement des workflows, les analyseurs syntaxiques ou les intégrations. ## Assurance des conteneurs CaseBender produit actuellement sept images de service. Chaque Dockerfile de production utilise un build multi-étapes et un utilisateur d’exécution non-root. Le processus d’assurance des conteneurs comprend : * l’analyse statique des Dockerfiles ; * l’élagage des dépendances de production ; * l’analyse des vulnérabilités avant publication ; * la détection des secrets intégrés au moyen de l’analyse d’image ; * la sélection d’un condensat immuable après publication ; * la signature sans clé avec Cosign au moyen de l’identité OIDC de GitHub ; et * la vérification de la signature par rapport au condensat publié exact. Les workflows Docker Hub et GitHub Container Registry signent le condensat que les clients téléchargent, au lieu de s’appuyer uniquement sur des tags modifiables tels que `latest`. ## Éléments probants de la chaîne d’approvisionnement logicielle Les workflows de publication génèrent plusieurs enregistrements complémentaires : * **SBOM CycloneDX** — inventaire des paquets et composants destiné à l’analyse des dépendances ; * **SBOM et provenance BuildKit** — métadonnées de build émises lors de la création des conteneurs ; * **signature Cosign** — identité cryptographique liée à un condensat d’image immuable ; * **attestation de SBOM** — association signée entre une image et son inventaire de composants ; * **document de provenance au format SLSA** — révision de la source, identité du workflow et métadonnées d’invocation ; et * **rapports d’analyse** — sortie SARIF ou JSON conservée par le workflow concerné. Le document autonome au format SLSA constitue une métadonnée de build signée. Son champ `subject` actuel est vide ; il n’est donc pas lié cryptographiquement aux sept condensats d’image et ne doit pas être présenté comme une provenance au niveau de l’artefact ni comme une certification SLSA indépendante. ## Traitement des vulnérabilités Les constats sont triés selon leur sévérité, leur exploitabilité, le mode de déploiement affecté, l’exposition et la disponibilité d’un correctif. Les objectifs de remédiation par défaut documentés par le projet sont les suivants : | Sévérité | Objectif | | -------- | --------- | | Critical | 24 heures | | High | 7 jours | | Medium | 30 jours | | Low | 90 jours | Il s’agit d’objectifs de remédiation internes, et non de niveaux de service contractuels, sauf s’ils sont intégrés à un accord client. Lorsqu’une remédiation immédiate est impossible, toute exception doit être circonscrite et révisable. Les exceptions IaC Trivy actuelles sont stockées dans `.trivyignore.yaml` et indiquent le constat, le chemin affecté, la justification et la date d’expiration. Les exceptions de licence sont propres à chaque paquet ; la politique ne masque pas globalement un identifiant de licence. Le fichier du dépôt ne doit pas être interprété comme un registre complet de toutes les catégories de risques produit acceptés. ## Intégrité des outils et des workflows Les contrôles eux-mêmes sont également protégés : * les GitHub Actions de tiers sont épinglées à des SHA de commit immuables ; * les principaux binaires et images de conteneur des outils d’analyse sont épinglés à une version ou à un condensat ; * les installations reposant sur le fichier de verrouillage utilisent `--frozen-lockfile` ; * les contrôles négatifs de sécurité détectent tout outil d’analyse qui cesse de façon inattendue de rejeter une entrée dont la non-conformité est connue ; * les paramètres actuels de protection des branches GitHub rejettent les mises à jour directes n’ayant pas produit les contrôles de statut requis ; cette politique est administrée en dehors du dépôt source ; et * les jobs agrégés échouent lorsqu’un job de sécurité requis a échoué, a été annulé ou a été ignoré de manière inattendue. ### Heuristique complémentaire de détection des logiciels malveillants Un workflow post-fusion distinct surveille sur `main` les modifications apportées aux fichiers de configuration Next.js et PostCSS afin de détecter des motifs malveillants connus de la chaîne d’approvisionnement npm ; il peut créer un retour arrière automatisé. Il s’agit d’un contrôle de récupération restreint, fondé sur des motifs. Ce n’est ni une porte de contrôle des demandes d’extraction, ni un moteur antivirus, ni un contrôle EDR, ni une analyse exhaustive des logiciels malveillants. ## Responsabilités du client CaseBender peut être déployé sur une infrastructure gérée par le client. L’assurance du produit ne remplace pas l’exploitation sécurisée de cet environnement. Les clients restent responsables : * des certificats TLS, de l’ingress, du pare-feu et de la segmentation réseau ; * de la configuration du fournisseur d’identité, de la MFA et des rôles ; * du durcissement de la base de données, de Redis, du stockage objet et du service de recherche ; * de la rotation des secrets et de l’accès aux identifiants de déploiement ; * des sauvegardes, de la surveillance, de la conservation et de la réponse aux incidents ; * de l’application des mises à jour prises en charge et de la consultation des notes de version ; et * de la validation des contrôles au regard de leur environnement réglementaire et de menaces. Consultez le [Guide de durcissement du déploiement (en anglais)](/en/security/hardening-guide) pour obtenir des recommandations opérationnelles. ## Limites actuelles de l’assurance En juillet 2026 : * les workflows automatisés de SAST, SCA, détection de secrets, licences, IaC, conteneurs, SBOM, signature et provenance sont mis en œuvre ; * le DAST authentifié de l’environnement de préproduction est configuré dans la CI, mais dépend du maintien d’une cible de préproduction et d’une identité de test ; * les fonctionnalités SARIF et Dependency Review hébergées par GitHub dépendent de la licence du dépôt, tandis que les portes Trivy locales et d’audit des paquets restent disponibles ; * aucun rapport de test d’intrusion tiers achevé ni aucune lettre de contre-test de remédiation ne sont revendiqués ; et * les correspondances avec les référentiels de conformité décrivent l’alignement des contrôles, et non une certification indépendante. Le périmètre proposé de l’évaluation indépendante est documenté dans le [Périmètre du test d’intrusion indépendant (en anglais)](/en/security/penetration-test-scope). ## Documentation associée * [Sécurité du code (en anglais)](/en/security/code-security) — configuration des outils d’analyse, DAST, licences et gestion des vulnérabilités * [Sécurité de la chaîne d’approvisionnement (en anglais)](/en/security/supply-chain) — dépendances, images, SBOM, signature et provenance * [Guide des éléments probants de sécurité](/fr/security/security-evidence) — types d’éléments probants et méthode d’interprétation * [Architecture de sécurité (en anglais)](/en/security/architecture) — conception de la sécurité de l’application et du déploiement * [Périmètre du test d’intrusion indépendant (en anglais)](/en/security/penetration-test-scope) — couverture prévue de l’évaluation manuelle