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
Procédure de traçabilité
1. Enregistrer le condensat déployé
Utilisez le registre ou le runtime de conteneur pour relever le condensat immuable :
La sortie attendue ressemble à ceci :
2. Vérifier la signature
Les workflows de publication de CaseBender utilisent la signature sans clé Cosign, reposant sur l’OIDC de GitHub Actions :
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.
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é.
Documentation associée
