Validation des informations collectées
Dans l'architecture DevSecOps, les preuves collectées au cours du processus d'analyse critique doivent être validées avant le déploiement afin de garantir que les actifs répondent aux exigences de conformité. Ce processus de validation agit comme une barrière de qualité, empêchant les actifs non conformes d'être déployés dans des environnements de production.
La collecte de preuves est un aspect essentiel de l'architecture de référence DevSecOps:
- Le pipeline de l'IC recueille des preuves pour toutes les analyses ou étapes effectuées sur les actifs
- Le pipeline CD déploie les ressources produites par le pipeline CI
- Le pipeline CC analyse les actifs déployés par le pipeline CD
La validation des preuves prend en charge deux modes de fonctionnement :
- Utilisation du mode de déclenchement par défaut
- Utilisation d'un fichier de configuration
Mode de déclenchement par défaut
Par défaut, le déploiement est bloqué si une preuve se trouve dans l'un des états suivants :
- En attente- La collecte des preuves est en cours
- Échec- La collecte des preuves a échoué ou le contrôle de conformité n'a pas abouti
Ce mode permet un contrôle strict afin de s'assurer que toutes les preuves collectées sont dans un état satisfaisant avant le déploiement.
Mode fichier de configuration
Le mode fichier de configuration fournit un cadre flexible et personnalisable pour la validation des preuves par le biais d'un fichier de configuration dédié. Ce mode vous permet de :
- Définir les exigences spécifiques en matière de preuves par environnement (dev, stage, prod)
- Définir des niveaux de déclaration de preuves pour contrôler le comportement de déploiement :
recommendedrequiredrequired_if_present
- Configurer différentes règles de validation pour différents types d'actifs (tels que les images, les commits ou les artefacts)
- Contrôler la manière dont les preuves provenant d'environnements multiples sont évaluées lors de la promotion
Désormais, le mode fichier de configuration prend également en charge l'évaluation à l'aide des politiques OPA (Open Policy Agent). Pour plus d'informations, consultez la section « Contrôle des étapes de déploiement à l'aide d'OPA ».
Comprendre les niveaux de déclaration des preuves
1. Mode recommandé :
Lorsque les contrôles de conformité sont marqués comme "recommandés", ils servent d'avertissements plutôt que d'obstacles. Cela signifie que :
- L'exécution du pipeline se poursuit même en cas d'échec des contrôles
- Le pipeline offre une visibilité sur l'état de la conformité, mais n'impose pas d'échec automatique
- Vous êtes responsable de l'examen et de la résolution de tous les problèmes signalés
- Tous les contrôles de conformité manquants ou défaillants doivent être traités et corrigés au cours de votre processus d'évaluation des risques
Cette approche met l'accent sur un modèle de responsabilité partagée: le pipeline fournit une visibilité et des recommandations en matière de conformité, mais les équipes doivent veiller activement à ce que leurs processus d'IC génèrent les preuves requises et remédient à toute lacune avant le déploiement de la production.
2. Mode requis :
Les preuves doivent être présentes sur le site success. Le déploiement est bloqué si la preuve est manquante, en attente ou a échoué.
3. Requis si mode présent :
Les preuves doivent se trouver sur le site success si elles existent. Ce mode :
- N'échoue que si l'état des preuves est
failure - Passe si la preuve est
success,pending, oumissing - Utile pour les analyses facultatives qui doivent être réussies lorsqu'elles sont exécutées
Agrégation des données
L'agrégation des preuves est le processus de collecte et d'évaluation des preuves de conformité dans plusieurs environnements de service (développement, étape, production) afin de déterminer la conformité globale au niveau de l'application. Au cours de l'exécution du pipeline CI/CD, divers outils de conformité collectent des preuves pour différents types d'actifs (images, commits, artefacts). Les preuves sont suivies séparément pour chaque environnement de service, et le système regroupe les résultats en fonction des règles définies dans votre fichier de configuration. Le statut global de conformité est déterminé en évaluant toutes les preuves collectées par rapport aux exigences configurées.
Avantages clés :
- Validation spécifique à l'environnement: Les exigences en matière de preuves peuvent varier d'un environnement à l'autre (par exemple, le stade peut nécessiter moins de vérifications que la production)
- Configuration flexible: Personnalisez les types de preuves requis, recommandés ou requis sous conditions pour chaque environnement
- Promotion Gating: Bloquer les déploiements vers la production si les preuves requises sont manquantes ou ont échoué dans les environnements précédents
- Piste d'audit: Conservez l'historique complet des preuves dans tous les environnements pour les rapports de conformité
Le diagramme suivant illustre la manière dont les éléments de preuve circulent dans les environnements et dont l'agrégation détermine l'état de préparation au déploiement :
Fichier de configuration Sections
Contrôles préalables au déploiement :
- Valider les preuves produites par le pipeline de l'IC
- Déploiement du portail sur la base de ces vérifications
- Auto-approbation de la demande de modification si tous les contrôles sont positifs
- Bloquer le déploiement en cas d'échec des vérifications (sauf pour les demandes de modification de
emergency) - Ajouter le fichier Config dans la demande de changement
Contrôles post-déploiement :
- Valider les preuves produites par le pipeline CD
- Évaluer la filière sur la base de ces contrôles
Structure des règles du fichier de configuration
Le fichier de configuration utilise la structure JSON suivante pour définir les règles de validation. Chaque type de preuve peut avoir plusieurs règles basées sur les types d'actifs et les environnements :
Structure :
- ID du type de preuve- Exemple :
com.ibm.static-scan- rules
- Type d'actif- Exemples :
image,commit,artifact - source_environments- Lieu d'origine des éléments de preuve
- name- Nom de l'environnement (par exemple,
ci-pipeline,stage,prod) - région- Région géographique (facultatif)
- name- Nom de l'environnement (par exemple,
- target_environments- Où les données probantes sont validées
- name- Nom de l'environnement (par exemple,
stage,prod) - région- Région géographique (facultatif)
- name- Nom de l'environnement (par exemple,
- requis- Les preuves doivent être présentes à l'adresse
success; le déploiement est bloqué en cas d'absence, d'attente ou d'échec- Outil- Type d'outil pour la collecte de données probantes (par exemple,
SonarQube,owasp-zap,*)
- Outil- Type d'outil pour la collecte de données probantes (par exemple,
- required_if_present- La preuve doit être dans l'état
successsi elle existe; échoue uniquement si l'état estfailure; réussit sisuccess,pending, oumissing- Outil- Type d'outil pour la collecte de données probantes (par exemple,
SonarQube,owasp-zap,*)
- Outil- Type d'outil pour la collecte de données probantes (par exemple,
- recommandé- Le pipeline enregistre des avertissements si des preuves manquent, sont en attente ou échouent; il ne bloque pas le déploiement
- Outil- Type d'outil pour la collecte de données probantes (par exemple,
SonarQube,owasp-zap,*)
- Outil- Type d'outil pour la collecte de données probantes (par exemple,
Les preuves collectées dans le pipeline CI doivent avoir leur champ d'origine fixé à ci-pipeline dans le fichier de configuration.
Pour des explications détaillées sur les niveaux de déclaration des preuves (requis, requis_si_présent, recommandé), voir la section Mode du fichier de configuration.
Validation des preuves à l'aide d'un fichier de configuration
Pour mettre en œuvre le mode fichier de configuration dans votre chaîne d'outils, suivez les étapes de configuration suivantes :
Étape 1 : Activer la validation des preuves
Dans les propriétés de l'environnement de vos pipelines CD et CC, définissez la variable suivante pour activer la fonction de validation des preuves dans vos pipelines de déploiement :
opt-in-evidence-checks=1
Étape 2 : Configurer le chemin d'accès au fichier de validation
Définissez le chemin d'accès à votre fichier de configuration dans le champ pipeline-config-repo:
evidence-checks-config-path=validation.json
Si evidence-checks-config-path n'est pas défini, le système recherche automatiquement un fichier portant le nom <region>.<target>.validation.json, <target>.validation.json ou validation.json dans le répertoire pipeline-config-repo.
Étape 3 : Vérifier la configuration
Une fois le pipeline en cours d'exécution, vérifiez que la validation des preuves basée sur le fichier de configuration est activée en suivant les étapes suivantes :
- Access Pipeline- Naviguer jusqu'à l'exécution spécifique du pipeline CD associée à votre modification
- Localiser la tâche- Trouvez la tâche intitulée
prod-change-requestet sélectionnez l'étapechange-request - Tableaux de révision- Localisez deux tableaux critiques en recherchant ces mots-clés :
- Tableau de l'étendue des actifs: Recherche de
Current pipeline scope(premier tableau) - Tableau de contrôle des preuves: Recherche de
PRE-DEPLOYMENT(deuxième tableau)
- Tableau de l'étendue des actifs: Recherche de
Si vous pouvez voir ces tableaux, cela confirme que la validation des preuves basée sur le fichier de configuration est activée.
Remarque : l'évaluation des pipelines se produit également lorsque le contrôle est activé dans les pipelines CD et CC, à l'aide du fichier de configuration.
Différentes topologies de déploiement
Les exemples suivants illustrent le fonctionnement de la validation des preuves dans différentes topologies de déploiement. Chaque topologie montre comment les preuves recueillies dans un environnement sont validées lors de la promotion dans les environnements suivants.
Environnements de service :
masteroudev- Développementstage- Pré-production (récemment soutenue)prod- Production
Promotion de master à prod
{ : caption="Cas d'utilisation 1. Promotion à partir de master à prod "
côté légende="bas"}
Propriétés pour Manual Promotion Trigger et Manual CD Trigger
| Nom | valeur |
|---|---|
source-environment |
master |
target-environment |
prod |
target-environment-purpose |
production |
Exemple de règle de configuration :
{
"evidence_type_id": "com.ibm.acceptance_tests",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Acceptance tests must pass if they are run"
}
],
"recommended": []
}
]
}
Promotion de master à stage puis à prod
: caption="Cas d'utilisation 2. Promotion à partir de master à stage à prod " côté légende="bas"}
Propriétés pour les environnements Manual Promotion Trigger et Manual CD Trigger stage
| Nom | valeur |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
pre_prod |
Propriétés pour les environnements Manual Promotion Trigger et Manual CD Trigger prod
| Nom | valeur |
|---|---|
source-environment |
stage |
target-environment |
prod |
target-environment-purpose |
production |
Exemple de règle de configuration :
{
"evidence_type_id": "com.ibm.acceptance_tests",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "ci-pipeline"
},
{
"name": "stage"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Acceptance tests must pass if they are run"
}
],
"recommended": []
}
]
}
Promotion de master à stage(us-east) à stage(us-south) et ensuite à prod(us-south)
{ : caption="Cas d'utilisation 3. Promotion à partir de master à stage(us-east) à stage(us-south) et puis à prod(us-south) " côté légende="bas"}
Propriétés pour les environnements Manual Promotion Trigger et Manual CD Trigger stage(us-east)
| Nom | valeur |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
pre_prod |
region |
us-east |
Propriétés pour les environnements Manual Promotion Trigger et Manual CD Trigger stage(us-south)
| Nom | valeur |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
pre_prod |
region |
us-south |
Propriétés pour les environnements Manual Promotion Trigger et Manual CD Trigger prod(us-south)
| Nom | valeur |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
production |
region |
us-south |
source-regions |
us-south |
Exemple de règle de configuration :
{
"evidence_type_id": "com.ibm.acceptance_tests",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "ci-pipeline"
},
{
"name": "stage",
"region": "us-south"
}
],
"target_environments": [
{
"name": "stage",
"region": "us-south"
},
{
"name": "stage",
"region": "us-east"
},
{
"name": "prod",
"region": "us-south"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Acceptance tests must pass if they are run"
}
],
"recommended": []
}
]
}
Valeurs d'outil par défaut pour les étapes DevSecOps
Les différents types d'actifs (tels que les images de conteneurs, les commits de code source ou les artefacts de déploiement) requièrent différents types de preuves. Le fichier de configuration vous permet de spécifier les types de preuves à collecter pour chaque type d'actif, et le système valide que les preuves appropriées ont été collectées par les outils correspondants.
| ID de type d'informations collectées | Outil pris en charge par défaut | Type d'artefact |
|---|---|---|
com.ibm.branch_protection |
cocoa-branch-protection |
repo (commit) |
com.ibm.unit_tests |
jest |
repo (commit) |
com.ibm.detect_secrets |
detect-secrets |
repo (commit) |
com.ibm.code_vulnerability_scan |
Pour les applications : cra-tf, cra, mendPour IaC: tfsec, checkov |
repo (commit) |
com.ibm.code_bom_check |
cra-bom, mend-bom |
repo (commit) |
com.ibm.code_cis_check |
cra-cis |
repo (commit) |
com.ibm.peer_review |
peer-review |
repo (commit) |
com.ibm.static_scan |
Pour les applications : sonarqube, gosecPour IaC: terraform-fmt, terraform-validate, tflint |
repo (commit) |
com.ibm.cloud.image_signing |
artifact-signing |
Artefact (image) |
com.ibm.acceptance_tests |
jest |
Artéfact (barre, image ou graphique) |
com.ibm.dynamic_scan |
owasp-zap, owasp-zap-ui |
Artefact (image) |
com.ibm.cloud.image_vulnerability_scan |
va, sysdig, xray |
Artefact |
com.ibm.prod_change_request |
gitlab |
Artéfact (barre, image ou graphique) |
com.ibm.close_change_request |
gitlab |
Artéfact (barre, image ou graphique) |
| com.ibm.cloud.slsa | tekton-chains | Artéfact (barre, image ou graphique) |
Foire aux questions
Mon déploiement est bloqué - comment savoir pourquoi?
Si votre déploiement est bloqué, suivez les étapes suivantes pour identifier le problème :
- Access Pipeline- Naviguer jusqu'à l'exécution spécifique du pipeline CD associée à votre modification
- Localiser la tâche- Trouvez la tâche intitulée
prod-change-requestet sélectionnez l'étapechange-request - Tableaux de révision- Localisez deux tableaux critiques en recherchant ces mots-clés :
- Tableau de l'étendue des actifs: Recherche de
Current pipeline scope(premier tableau) - Tableau de contrôle des preuves: Recherche de
PRE-DEPLOYMENT(deuxième tableau)
- Tableau de l'étendue des actifs: Recherche de
Le tableau de vérification des preuves indique les éléments de preuve qui sont missing ou failed, ce qui entraîne le blocage de votre déploiement.
Comprendre le tableau de contrôle des éléments de preuve
Le tableau de vérification des éléments de preuve affiche l'état de validation des éléments de preuve pour chaque actif. La compréhension de sa structure vous aide à résoudre les problèmes de conformité.
Structure du tableau des actifs :
- Colonne ID: Clé primaire identifiant chaque actif
- Full_id: Identifiant complet de l'actif.
- type: Type de l'actif
- Colonne URI: L'actif réel (image, artefact, etc.) en cours de validation
- Relation: L'ID de l'actif sert de clé étrangère (
AssetId) dans la table de vérification des preuves
Structure du tableau de vérification des preuves :
- AssetId Colonne: clé étrangère identifiant chaque actif
- EvidenceTypeId: Spécifie quelle preuve de conformité est requise (par exemple, analyse de vulnérabilité, tests unitaires, examen par les pairs)
- Origine de la preuve: indique la provenance de la preuve (généralement
ci-pipeline) - Statut: Indique si la preuve est présente, manquante ou défaillante pour chaque bien
Structure du tableau de synthèse des données :
Ce tableau affiche le résumé des preuves de conformité pour tous les actifs et indique le nombre d'éléments de preuve manquants, réussis, échoués ou en attente.
Comment corriger les preuves manquantes ou défaillantes?
Une fois que vous avez identifié les preuves manquantes ou défaillantes dans le tableau de vérification des preuves, utilisez cet arbre de décision pour résoudre le problème. Notez le type de preuve spécifique (par exemple, com.ibm.static_scan)
et le type d'actif (par exemple, image, commit).
Question : "Ai-je configuré mon pipeline d'analyse critique pour qu'il recueille le [type de preuve] pour le [type de bien]?
Si NON (vous ne l'avez pas collecté):
- Posez la question : "S'agit-il d'une exigence de conformité valable pour mon service?"
- OUI, c'est valable: Mettre en œuvre la collecte de preuves dans votre pipeline de CI
- Ajouter les outils ou les scripts d'analyse nécessaires
- Configurer des mécanismes appropriés de signalement des preuves
- Veiller à ce que les preuves soient liées à l'actif correct
- Pour plus de détails sur la mise en œuvre, voir le Guide de collecte des preuves d'actifs
- NON, ce n'est pas applicable: Documenter la justification et escalader
- Contactez votre point focal de sécurité
- Expliquez pourquoi cette vérification ne s'applique pas à votre service
- Fournir une justification claire
- Supprimez le contrôle de votre fichier de configuration après approbation
Si OUI (vous avez déjà recueilli ces preuves):
- Cherchez à savoir pourquoi il apparaît comme manquant dans le tableau de contrôle des éléments de preuve
- Questions potentielles à vérifier :
- Les preuves sont-elles générées correctement dans votre pipeline de CI?
- Les données sont-elles transmises au bon endroit?
- L'identifiant de l'actif est-il correctement lié à l'élément de preuve?
- Existe-t-il des problèmes de synchronisation entre les pipelines de CI et de CD?
- Le format des preuves est-il compatible avec les exigences de validation?
- Vérifier les journaux du pipeline pour y trouver des messages d'erreur liés à la collecte ou à la communication des preuves
Compte de référence
Exemple de fichier de configuration
{
"version": "2.0",
"pre-deployment": [
{
"evidence_type_id": "com.ibm.prod_change_request",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "stage"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Change request must be successful if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.acceptance_tests",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
},
{
"name": "stage"
},
{
"name": "prod"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Acceptance tests must pass if they are run"
}
],
"recommended": []
},
{
"asset_type": "image",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Acceptance tests must pass if they are run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.branch_protection",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Branch protection must be successful if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.cloud.slsa",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "SLSA attestation must be successful if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.dynamic_scan",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"owasp-zap"
],
"description": "Dynamic scan must pass if OWASP ZAP is run"
}
],
"recommended": [
{
"name": "tool",
"values": [
"*"
],
"description": "Other dynamic scan tools are recommended"
}
]
}
]
},
{
"evidence_type_id": "com.ibm.cloud.verify_signature",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Signature verification must pass if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.cloud.image_vulnerability_scan",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Image vulnerability scan must pass if run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.peer_review",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Peer review must be successful if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.unit_tests",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Unit tests must pass if they are run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.static_scan",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Static scan must pass if run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.detect_secrets",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Detect secrets scan must pass if run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.code_vulnerability_scan",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Code vulnerability scan must pass if run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.code_cis_check",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "CIS check must pass if run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.code_bom_check",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "BOM check must pass if run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.network_compliance",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Network compliance check must pass if run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.pipeline_run_data",
"rules": [
{
"asset_type": "generic",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Pipeline run data must be successful if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.pipeline_logs",
"rules": [
{
"asset_type": "generic",
"source_environments": [
{
"name": "ci-pipeline"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Pipeline logs must be successful if present"
}
],
"recommended": []
}
]
}
],
"post-deployment": [
{
"evidence_type_id": "com.ibm.prod_change_request",
"rules": [
{
"asset_type": "image",
"source_environments": [
{
"name": "stage"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Change request must be successful if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.acceptance_tests",
"rules": [
{
"asset_type": "commit",
"source_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Acceptance tests must pass if they are run"
}
],
"recommended": []
},
{
"asset_type": "image",
"source_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Acceptance tests must pass if they are run"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.pipeline_run_data",
"rules": [
{
"asset_type": "generic",
"source_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Pipeline run data must be successful if present"
}
],
"recommended": []
}
]
},
{
"evidence_type_id": "com.ibm.pipeline_logs",
"rules": [
{
"asset_type": "generic",
"source_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"target_environments": [
{
"name": "stage"
},
{
"name": "prod"
}
],
"required": [],
"required_if_present": [
{
"name": "tool",
"values": [
"*"
],
"description": "Pipeline logs must be successful if present"
}
],
"recommended": []
}
]
}
]
}