Guide des éléments probants de sécurité

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 :

docker image inspect IMAGE:TAG \
  --format='{{index .RepoDigests 0}}'

La sortie attendue ressemble à ceci :

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 :

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 :

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 :

l’identifiant de la version et le SHA du commit ;
les condensats immuables des images de service déployées ;
le résultat du workflow Security Gate ;
les résultats d’analyse des conteneurs pour ces condensats ;
les SBOM CycloneDX ;
la sortie de vérification des signatures ;
la provenance signée et la sortie de sa vérification ;
les enregistrements d’exception actifs applicables ;
un récapitulatif de la remédiation des vulnérabilités ; et
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).

Signaler un problème de sécurité

Signalez toute vulnérabilité CaseBender présumée à 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é.

Assurance de sécurité

Guide des éléments probants de sécurité

Vue d’ensemble

Catalogue des éléments probants

Procédure de traçabilité

1. Enregistrer le condensat déployé

2. Vérifier la signature

3. Vérifier les métadonnées de provenance

4. Examiner la SBOM

5. Examiner les constats de sécurité et les exceptions

Conservation des artefacts

Dossier d’éléments probants suggéré aux clients

Interprétation d’un résultat positif

Éléments probants des tests d’intrusion

Signaler un problème de sécurité

Documentation associée

​Vue d’ensemble

​Catalogue des éléments probants

​Procédure de traçabilité

​1. Enregistrer le condensat déployé

​2. Vérifier la signature

​3. Vérifier les métadonnées de provenance

​4. Examiner la SBOM

​5. Examiner les constats de sécurité et les exceptions

​Conservation des artefacts

​Dossier d’éléments probants suggéré aux clients

​Interprétation d’un résultat positif

​Éléments probants des tests d’intrusion

​Signaler un problème de sécurité

​Documentation associée

Vue d’ensemble

Catalogue des éléments probants

Procédure de traçabilité

1. Enregistrer le condensat déployé

2. Vérifier la signature

3. Vérifier les métadonnées de provenance

4. Examiner la SBOM

5. Examiner les constats de sécurité et les exceptions

Conservation des artefacts

Dossier d’éléments probants suggéré aux clients

Interprétation d’un résultat positif

Éléments probants des tests d’intrusion

Signaler un problème de sécurité

Documentation associée