> ## 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. # Guide des éléments probants de sécurité > Guide destiné aux clients qui examinent les rapports d’analyse, les SBOM, les signatures, la provenance, les exceptions et l’état des évaluations de CaseBender. ## Vue d’ensemble Les éléments probants de sécurité sont particulièrement utiles lorsqu’ils peuvent être rattachés au logiciel exact évalué par un client. CaseBender identifie les builds par commit Git et les artefacts de conteneur par condensat immuable. Pour procéder à une revue d’assurance, commencez par l’un des éléments suivants : * une version de CaseBender ; * le SHA du commit Git indiqué par la version ; * le condensat de chaque image de conteneur déployée ; ou * l’exécution du workflow ayant produit les artefacts. Les tags tels que `latest` constituent des références pratiques, mais pas des identifiants stables pour les éléments probants. ## Catalogue des éléments probants | Élément probant | Ce qu’il démontre | Limitation importante | | --------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Résultat de Security Gate | Les jobs de sécurité CI requis se sont terminés avec succès pour une révision | Couvre uniquement les contrôles automatisés configurés | | Rapport/journal Gitleaks | Aucun motif de secret correspondant n’est resté dans le code source et l’historique analysés | Ne peut pas identifier tous les formats d’identifiants possibles | | SARIF du système de fichiers Trivy | Constats relatifs aux dépendances pour l’état du dépôt analysé | Les bases de données d’avis de sécurité et la détection des paquets évoluent au fil du temps | | SARIF des conteneurs Trivy | Constats relatifs au système d’exploitation et aux applications dans une image de service créée | S’applique uniquement au condensat analysé | | SARIF IaC Trivy | Constats dans la configuration Docker et Kubernetes | Ne valide pas tous les paramètres de la plateforme d’exécution | | SARIF Semgrep | Constats issus des règles configurées d’analyse du code source et des flux de données entachées | La couverture des règles n’équivaut pas à une revue manuelle du code | | JSON d’audit des dépendances | Avis de sécurité connus du registre de paquets concernant les dépendances de production | Ne couvre pas les paquets du système d’exploitation | | JSON des licences et résultat de la politique | Licences détectées et décisions de politique propres à chaque paquet | L’interprétation juridique reste propre à chaque client | | SBOM CycloneDX | Composants détectés pour un dépôt ou une image | Une SBOM est un inventaire, et non une déclaration d’absence de vulnérabilités | | Signature Cosign | Une identité de workflow a signé un condensat d’image précis | La vérification de la signature n’évalue pas le comportement de l’application | | Attestation de SBOM | Une SBOM signée est associée à une image précise | L’exactitude de l’attestation dépend de celle de la génération de la SBOM | | Document de provenance au format SLSA | Révision de la source et métadonnées d’invocation du build | Le champ `subject` actuel est vide ; le document n’est ni lié à un condensat d’image ni certifié de manière indépendante | | Rapport OWASP ZAP | Résultats obtenus sur les routes authentifiées de préproduction atteintes par ZAP | Ne prouve pas une couverture complète de l’API ou de la logique métier | | Enregistrement d’exception | Un constat a été volontairement circonscrit, justifié et assorti d’une date d’expiration | N’élimine pas le risque sous-jacent | ## Procédure de traçabilité ### 1. Enregistrer le condensat déployé Utilisez le registre ou le runtime de conteneur pour relever le condensat immuable : ```bash theme={null} docker image inspect IMAGE:TAG \ --format='{{index .RepoDigests 0}}' ``` La sortie attendue ressemble à ceci : ```text theme={null} registry.example.com/casebender/web@sha256:... ``` ### 2. Vérifier la signature Les workflows de publication de CaseBender utilisent la signature sans clé Cosign, reposant sur l’OIDC de GitHub Actions : ```bash theme={null} cosign verify \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ IMAGE@sha256:DIGEST ``` La vérification doit porter sur un condensat, et non sur un simple tag. Le canal du registre et l’identité du certificat doivent correspondre à la documentation de version fournie avec l’artefact. ### 3. Vérifier les métadonnées de provenance Examinez les éléments suivants dans le document de provenance : * le dépôt et la révision de la source ; * l’identité et le déclencheur du workflow ; * l’horodatage du build et l’acteur ; * le champ `subject` et la question de savoir s’il identifie l’artefact examiné ; et * la signature jointe et le certificat de signature. Le champ `subject` du document autonome de provenance CaseBender actuel est vide. Ce document peut être vérifié en tant que métadonnée de workflow signée, mais il ne permet pas actuellement de prouver qu’un condensat de conteneur donné a été produit par cette invocation. Pour la traçabilité au niveau de l’artefact, utilisez le condensat du registre, la signature de l’image et l’attestation de SBOM de l’image. Vérifiez le blob signé avant de vous fier à son contenu : ```bash theme={null} cosign verify-blob \ --signature provenance.json.sig \ --certificate provenance.json.cert \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ provenance.json ``` ### 4. Examiner la SBOM Utilisez la SBOM pour identifier les composants directs et transitifs pertinents pour votre déploiement. Les clients peuvent importer le fichier JSON CycloneDX dans leurs propres outils de gestion des vulnérabilités ou des actifs logiciels. Une SBOM doit être associée au même commit ou condensat d’image que celui examiné. Une SBOM au niveau du dépôt et une SBOM au niveau de l’image répondent à des questions différentes et ne doivent pas être considérées comme interchangeables. ### 5. Examiner les constats de sécurité et les exceptions Vérifiez : * que l’analyse s’est terminée et n’a pas été ignorée ; * que le rapport correspond à la révision ou au condensat cible ; * la politique de sévérité utilisée par le workflow ; * si les constats sans correctif ont été exclus par la configuration de l’outil d’analyse ; * si une exception s’applique précisément au constat et au chemin concernés ; et * si l’exception se trouve encore dans sa période de révision. ## Conservation des artefacts Les paramètres de conservation actuels sont notamment les suivants : * artefacts des outils d’analyse et d’audit : généralement 30 jours ; * artefacts SBOM CycloneDX du dépôt et matériel de signature : 1 095 jours ; et * signatures et attestations du registre : conservées avec l’artefact de registre concerné, sous réserve de la politique de cycle de vie du registre. La conservation dans l’environnement propre d’un client est contrôlée par ce dernier. Les clients soumis à des exigences d’audit plus longues doivent archiver le dossier d’éléments probants reçu pour chaque version déployée. ## Dossier d’éléments probants suggéré aux clients Pour une revue d’assurance de version, le dossier pertinent peut comprendre : 1. l’identifiant de la version et le SHA du commit ; 2. les condensats immuables des images de service déployées ; 3. le résultat du workflow Security Gate ; 4. les résultats d’analyse des conteneurs pour ces condensats ; 5. les SBOM CycloneDX ; 6. la sortie de vérification des signatures ; 7. la provenance signée et la sortie de sa vérification ; 8. les enregistrements d’exception actifs applicables ; 9. un récapitulatif de la remédiation des vulnérabilités ; et 10. la déclaration actuelle relative à l’état des tests d’intrusion. La disponibilité peut dépendre des autorisations du dépôt, du canal du registre, des périodes de conservation des artefacts et des conditions contractuelles de divulgation. Les rapports bruts peuvent contenir des chemins de dépôt, des détails sur les dépendances ou des informations sur l’infrastructure, et nécessiter un transfert sécurisé ou une occultation. ## Interprétation d’un résultat positif Un workflow au vert signifie que les jobs configurés se sont terminés conformément à la politique codée dans cette révision. Cela ne signifie pas : * qu’aucune vulnérabilité n’existe ; * que chaque chemin de l’application a été testé ; * que toute l’infrastructure déployée correspond aux modèles analysés ; * que chaque dépendance est à l’abri de futurs avis de sécurité ; * qu’un tiers a validé le résultat de manière indépendante ; ou * que la version est certifiée selon un référentiel de conformité. Pour les déploiements nécessitant un niveau d’assurance supérieur, combinez les éléments probants automatisés à une revue de l’architecture, au durcissement de l’environnement client, à la modélisation des menaces et à des tests manuels indépendants. ## Éléments probants des tests d’intrusion CaseBender ne revendique actuellement ni rapport de test d’intrusion tiers achevé ni lettre de contre-test de remédiation. Les tests ZAP automatisés et la fonctionnalité intégrée de gestion des tests d’intrusion ne remplacent pas ces éléments probants. La mission prévue, les qualifications requises des testeurs, les règles d’engagement et les livrables attendus sont documentés dans le [Périmètre du test d’intrusion indépendant (en anglais)](/en/security/penetration-test-scope). ## Signaler un problème de sécurité Signalez toute vulnérabilité CaseBender présumée à [security@casebender.com](mailto:security@casebender.com). Précisez : * la version ou le condensat d’image affecté ; * le mode de déploiement ; * les étapes de reproduction ; * le comportement attendu et celui observé ; * l’impact potentiel ; et * tout élément de preuve de concept pouvant être traité de manière sécurisée. N’incluez aucun identifiant actif, aucune donnée client ni aucun élément d’exploitation destructeur dans un premier message non chiffré. ## Documentation associée * [Programme d’assurance de la sécurité](/fr/security/security-assurance) * [Sécurité du code (en anglais)](/en/security/code-security) * [Sécurité de la chaîne d’approvisionnement (en anglais)](/en/security/supply-chain) * [Guide de durcissement du déploiement (en anglais)](/en/security/hardening-guide)