Programme d’assurance de la sécurité

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

Modifications protégées (en anglais)

Les demandes d’extraction vers les branches protégées doivent franchir une porte de sécurité agrégée avant leur fusion.

Tests multicouches

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.

Intégrité des versions (en anglais)

Les workflows de publication génèrent des SBOM, des données de provenance, des condensats immuables et des signatures cryptographiques.

Éléments probants destinés aux clients

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 :

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) ; 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é.

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 :

que la cible n’est ni une valeur fictive, ni localhost, ni une adresse de bouclage ;
que la réponse identifie un déploiement web CaseBender ;
que l’identité de test configurée produit une session authentifiée ; et
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) 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).

Documentation associée

Sécurité du code (en anglais) — configuration des outils d’analyse, DAST, licences et gestion des vulnérabilités
Sécurité de la chaîne d’approvisionnement (en anglais) — dépendances, images, SBOM, signature et provenance
Guide des éléments probants de sécurité — types d’éléments probants et méthode d’interprétation
Architecture de sécurité (en anglais) — conception de la sécurité de l’application et du déploiement
Périmètre du test d’intrusion indépendant (en anglais) — couverture prévue de l’évaluation manuelle

​Objectif

​Vue d’ensemble de l’assurance

Modifications protégées (en anglais)

Tests multicouches

Intégrité des versions (en anglais)

Éléments probants destinés aux clients

​Cycle de vie sécurisé des modifications

​Déclenchement des contrôles

​Porte de sécurité bloquant les fusions

​Tests de sécurité dynamiques

​Assurance des conteneurs

​Éléments probants de la chaîne d’approvisionnement logicielle

​Traitement des vulnérabilités

​Intégrité des outils et des workflows

​Heuristique complémentaire de détection des logiciels malveillants

​Responsabilités du client

​Limites actuelles de l’assurance

​Documentation associée

Objectif

Vue d’ensemble de l’assurance

Cycle de vie sécurisé des modifications

Déclenchement des contrôles

Porte de sécurité bloquant les fusions

Tests de sécurité dynamiques

Assurance des conteneurs

Éléments probants de la chaîne d’approvisionnement logicielle

Traitement des vulnérabilités

Intégrité des outils et des workflows

Heuristique complémentaire de détection des logiciels malveillants

Responsabilités du client

Limites actuelles de l’assurance

Documentation associée