Angaben validieren
In der DevSecOps Architektur müssen die während der CI-Pipeline gesammelten Beweise vor der Bereitstellung validiert werden, um sicherzustellen, dass die Assets die Compliance-Anforderungen erfüllen. Dieser Validierungsprozess fungiert als Qualitätssperre, die verhindert, dass nicht konforme Assets in der Entwicklungs- oder Produktionsumgebung eingesetzt werden.
Die Sammlung von Beweisen ist ein wesentlicher Aspekt der Referenzarchitektur DevSecOps:
- Die CI-Pipeline sammelt Beweise für alle Scans oder Schritte, die an den Assets durchgeführt werden
- Die CD-Pipeline setzt die von der CI-Pipeline produzierten Assets ein
- Die CC-Pipeline durchsucht die von der CD-Pipeline bereitgestellten Assets
Die Evidenzvalidierung unterstützt zwei Betriebsmodi:
- Verwendung des Standard-Tastermodus
- Konfigurationsdatei verwenden
Standard-Torsteuerungsmodus
Standardmäßig wird die Bereitstellung blockiert, wenn sich ein Beweismittel in einem der folgenden Zustände befindet:
- Ausstehend- Beweiserhebung ist im Gange
- Fehlschlag- Die Beweiserhebung ist fehlgeschlagen oder die Prüfung der Einhaltung der Vorschriften wurde nicht bestanden
Dieser Modus bietet eine strenge Kontrolle, um sicherzustellen, dass sich alle gesammelten Beweise in einem erfolgreichen Zustand befinden, bevor die Verteilung fortgesetzt wird.
Modus der Konfigurationsdatei
Der Konfigurationsdateimodus bietet einen flexiblen und anpassbaren Rahmen für die Beweisvalidierung durch eine spezielle Konfigurationsdatei. In diesem Modus haben Sie folgende Möglichkeiten:
- Definition spezifischer Beweisanforderungen pro Umgebung (Dev, Stage, Prod)
- Legen Sie Evidenzerklärungsebenen fest, um das Einsatzverhalten zu steuern:
recommendedrequiredrequired_if_present
- Konfigurieren Sie unterschiedliche Validierungsregeln für verschiedene Asset-Typen (z. B. Bilder, Commits oder Artefakte)
- Kontrollieren Sie, wie Nachweise aus verschiedenen Umgebungen bei der Beförderung bewertet werden
Der Konfigurationsdateimodus unterstützt nun auch die Auswertung anhand von OPA-Richtlinien (Open Policy Agent). Weitere Informationen finden Sie unter „ Deployment Gating mit OPA “.
Verständnis der Deklarationsstufen für Nachweise
1. Empfohlener Modus:
Wenn Konformitätsprüfungen als "empfohlen" gekennzeichnet sind, dienen sie eher als Warnung denn als Hindernis. Dies bedeutet:
- Die Ausführung der Pipeline wird fortgesetzt, auch wenn die Prüfungen fehlschlagen
- Die Pipeline bietet einen Überblick über den Konformitätsstatus, erzwingt aber keine automatischen Fehler
- Sie sind für die Untersuchung und Lösung aller gemeldeten Probleme verantwortlich
- Alle mangelhaften oder fehlenden Konformitätsprüfungen müssen im Rahmen Ihres CI-Prozesses behandelt und behoben werden
Bei diesem Ansatz liegt der Schwerpunkt auf einem Modell der geteilten Verantwortung: Die Pipeline bietet Transparenz und Empfehlungen zur Einhaltung der Vorschriften, aber die Teams müssen aktiv dafür sorgen, dass ihre CI-Prozesse die erforderlichen Nachweise erbringen und etwaige Lücken vor dem Produktionseinsatz beheben.
2. Erforderlicher Modus:
Die Beweise müssen unter success zu finden sein. Die Bereitstellung wird blockiert, wenn Beweise fehlen, ausstehen oder fehlgeschlagen sind.
3. Erforderlich, wenn vorhandener Modus:
Wenn es Beweise gibt, müssen sie unter success zu finden sein. Dieser Modus:
- Schlägt nur fehl, wenn der Beweisstatus
failure - Bestanden, wenn die Beweise
success,pending, odermissing - Nützlich für optionale Scans, die bei ihrer Ausführung erfolgreich sein müssen
Aggregation von Beweisen
Die Zusammenführung von Nachweisen ist ein Prozess, bei dem Nachweise für die Einhaltung der Vorschriften in verschiedenen Serviceumgebungen (Entwicklung, Phase, Produktion) gesammelt und ausgewertet werden, um die Einhaltung der Vorschriften auf Anwendungsebene insgesamt zu bestimmen. Während der CI/CD-Pipeline-Läufe sammeln verschiedene Compliance-Tools Beweise für verschiedene Asset-Typen (Images, Commits, Artefakte). Die Nachweise werden für jede Dienstumgebung separat verfolgt, und das System aggregiert die Ergebnisse auf der Grundlage der in Ihrer Konfigurationsdatei definierten Regeln. Der allgemeine Konformitätsstatus wird durch die Bewertung aller gesammelten Nachweise anhand der konfigurierten Anforderungen ermittelt.
Wichtige Vorteile:
- Umgebungsspezifische Validierung: Unterschiedliche Umgebungen können unterschiedliche Anforderungen an die Nachweise stellen (z. B. kann die Bühne weniger Kontrollen erfordern als der Produktionsbereich)
- Flexible Konfiguration: Passen Sie an, welche Beweistypen für jede Umgebung erforderlich, empfohlen oder bedingt erforderlich sind
- Promotion Gating: Blockieren Sie die Bereitstellung in der Produktion, wenn die erforderlichen Nachweise fehlen oder in früheren Umgebungen fehlgeschlagen sind
- Prüfpfad: Führen Sie eine vollständige Beweishistorie über alle Umgebungen hinweg für Compliance-Berichte
Das folgende Diagramm veranschaulicht, wie Beweise durch Umgebungen fließen und wie die Aggregation die Einsatzbereitschaft bestimmt:
Config-Datei Abschnitte
Kontrollen vor der Entsendung:
- Validierung der von der CI-Pipeline erzeugten Nachweise
- Gate-Einsatz auf der Grundlage dieser Kontrollen
- Automatisches Genehmigen von Änderungsanträgen, wenn alle Prüfungen bestanden sind
- Sperrung der Bereitstellung bei fehlgeschlagenen Prüfungen (außer bei
emergencychange requests) - Config-Datei als Teil des Änderungsantrags hinzufügen
Kontrollen nach der Entsendung:
- Validierung der von der CD-Pipeline erzeugten Nachweise
- Bewerten Sie die Pipeline auf der Grundlage dieser Prüfungen
Regelstruktur der Konfigurationsdatei
Die Konfigurationsdatei verwendet die folgende JSON-Struktur, um Validierungsregeln zu definieren. Jede Beweisart kann mehrere Regeln haben, die auf Asset-Typen und Umgebungen basieren:
Struktur:
- Evidenzarten-ID- Beispiel:
com.ibm.static-scan- Regeln
- Asset-Typ- Beispiele:
image,commit,artifact - source_environments- Woher die Beweise stammen
- name- Name der Umgebung (z. B.
ci-pipeline,stage,prod) - Region – Geografische Region (optional)
- name- Name der Umgebung (z. B.
- target_environments- Wo Evidenz validiert wird
- name- Name der Umgebung (z. B.
stage,prod) - Region – Geografische Region (optional)
- name- Name der Umgebung (z. B.
- erforderlich- Beweismittel müssen im Zustand
successvorhanden sein; blockiert die Bereitstellung, wenn sie fehlen, ausstehen oder fehlschlagen- Tool- Tooltyp für die Beweiserhebung (z. B.
SonarQube,owasp-zap,*)
- Tool- Tooltyp für die Beweiserhebung (z. B.
- required_if_present- Evidence muss sich im Zustand
successbefinden, wenn es existiert; schlägt nur beifailurefehl; ist erfolgreich, wennsuccess,pendingodermissing- Tool- Tooltyp für die Beweiserhebung (z. B.
SonarQube,owasp-zap,*)
- Tool- Tooltyp für die Beweiserhebung (z. B.
- empfohlen- Pipeline protokolliert Warnungen, wenn Beweise fehlen/ausstehen/fehlerhaft sind; blockiert die Bereitstellung nicht
- Tool- Tooltyp für die Beweiserhebung (z. B.
SonarQube,owasp-zap,*)
- Tool- Tooltyp für die Beweiserhebung (z. B.
Bei Beweisen, die in der CI-Pipeline gesammelt werden, sollte das Herkunftsfeld in der Konfigurationsdatei auf ci-pipeline gesetzt werden.
Ausführliche Erläuterungen zu den Stufen der Nachweisdeklaration (erforderlich, erforderlich_wenn_vorhanden, empfohlen) finden Sie im Abschnitt Modus der Konfigurationsdatei.
Evidenzvalidierung mittels Konfigurationsdatei
Um den Konfigurationsdateimodus in Ihrer Toolchain zu implementieren, führen Sie die folgenden Konfigurationsschritte aus:
Schritt 1: Evidenzvalidierung aktivieren
Legen Sie in den Eigenschaften Ihrer CD- und CC-Pipeline-Umgebung die folgende Variable fest, um die Evidence Validation-Funktion in Ihren Bereitstellungspipelines zu aktivieren:
opt-in-evidence-checks=1
Schritt 2: Konfigurieren Sie den Pfad der Validierungsdatei
Legen Sie den Pfad zu Ihrer Konfigurationsdatei in der pipeline-config-repo fest:
evidence-checks-config-path=validation.json
Wenn evidence-checks-config-path nicht definiert ist, sucht das System automatisch nach einer Datei mit dem Namen <region>.<target>.validation.json, <target>.validation.json, oder validation.json im Verzeichnis pipeline-config-repo.
Schritt 3: Konfiguration überprüfen
Sobald die Pipeline läuft, überprüfen Sie, ob die Beweisvalidierung auf der Grundlage der Konfigurationsdatei aktiviert ist, indem Sie die folgenden Schritte ausführen:
- Access Pipeline- Navigieren Sie zu dem spezifischen CD-Pipeline-Lauf, der mit Ihrer Änderung verbunden ist
- Aufgabe suchen- Suchen Sie die Aufgabe mit der Bezeichnung
prod-change-requestund wählen Sie den Schrittchange-request - Review Tables- Suchen Sie zwei kritische Tabellen, indem Sie nach diesen Schlüsselwörtern suchen:
- Tabelle Vermögensumfang: Suche nach
Current pipeline scope(erste Tabelle) - Tabelle zur Überprüfung der Beweise: Suche nach
PRE-DEPLOYMENT(zweite Tabelle)
- Tabelle Vermögensumfang: Suche nach
Wenn Sie diese Tabellen sehen können, bestätigt dies, dass die Beweisvalidierung auf der Grundlage der Konfigurationsdatei aktiviert ist.
Hinweis: Die Pipeline-Auswertung erfolgt auch, wenn die Prüfung sowohl in der CD- als auch in der CC-Pipeline unter Verwendung der Konfigurationsdatei aktiviert ist.
Verschiedene Einsatztopologien
Die folgenden Beispiele zeigen, wie die Beweisvalidierung in verschiedenen Einsatztopologien funktioniert. Jede Topologie zeigt, wie die in einer Umgebung gesammelten Erkenntnisse bei der Übertragung auf nachfolgende Umgebungen validiert werden.
Service-Umgebungen:
masteroderdev- Entwicklungstage- Vorproduktion (kürzlich unterstützt)prod- Produktion
Beförderung von master nach prod
{: caption="Anwendungsfall 1. Promotion von master Zu prod " Bildunterschrift-Seite = "unten"}
Immobilien in Manual Promotion Trigger und Manual CD Trigger
| Name | Wert |
|---|---|
source-environment |
master |
target-environment |
prod |
target-environment-purpose |
production |
Beispiel einer Konfigurationsregel:
{
"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": []
}
]
}
Beförderung von master zu stage und dann zu prod
: caption="Anwendungsfall 2. Promotion von master Zu stage Zu prod " Bildunterschrift-Seite
= "unten"}
Eigenschaften für die Umgebungen „ Manual Promotion Trigger “ und „ Manual CD Trigger “ stage
| Name | Wert |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
pre_prod |
Eigenschaften für die Umgebungen „ Manual Promotion Trigger “ und „ Manual CD Trigger “ prod
| Name | Wert |
|---|---|
source-environment |
stage |
target-environment |
prod |
target-environment-purpose |
production |
Beispiel einer Konfigurationsregel:
{
"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": []
}
]
}
Beförderung von master zu stage(us-east) zu stage(us-south) und dann zu prod(us-south)
{: caption="Anwendungsfall 3. Promotion von master Zu stage(us-east) Zu stage(us-south) und dann zu prod(us-south) " Bildunterschrift-Seite = "unten"}
Eigenschaften für die Umgebungen „ Manual Promotion Trigger “ und „ Manual CD Trigger “ stage(us-east)
| Name | Wert |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
pre_prod |
region |
us-east |
Eigenschaften für die Umgebungen „ Manual Promotion Trigger “ und „ Manual CD Trigger “ stage(us-south)
| Name | Wert |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
pre_prod |
region |
us-south |
Eigenschaften für die Umgebungen „ Manual Promotion Trigger “ und „ Manual CD Trigger “ prod(us-south)
| Name | Wert |
|---|---|
source-environment |
master |
target-environment |
stage |
target-environment-purpose |
production |
region |
us-south |
source-regions |
us-south |
Beispiel einer Konfigurationsregel:
{
"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": []
}
]
}
Standard-Werkzeugwerte für DevSecOps Stufen
Verschiedene Asset-Typen (z. B. Container-Images, Quellcode-Commits oder Deployment-Artefakte) erfordern unterschiedliche Arten von Nachweisen. In der Konfigurationsdatei können Sie angeben, welche Arten von Nachweisen für jeden Asset-Typ gesammelt werden müssen, und das System prüft, ob die entsprechenden Nachweise von den entsprechenden Tools gesammelt wurden.
| Angabentyp-ID | Standardmäßig unterstütztes Tool | Artefakttyp |
|---|---|---|
com.ibm.branch_protection |
cocoa-branch-protection |
repo (Übergabe) |
com.ibm.unit_tests |
jest |
repo (Übergabe) |
com.ibm.detect_secrets |
detect-secrets |
repo (Übergabe) |
com.ibm.code_vulnerability_scan |
Für Anwendungen: cra-tf, cra, mendFür 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 |
Für Anwendungen: sonarqube, gosecFür IaC: terraform-fmt, terraform-validate, tflint |
repo(commit) |
com.ibm.cloud.image_signing |
artifact-signing |
Artefakt (Bild) |
com.ibm.acceptance_tests |
jest |
Artefakt (Steuerrad, Bild oder Karte) |
com.ibm.dynamic_scan |
owasp-zap, owasp-zap-ui |
Artefakt (Bild) |
com.ibm.cloud.image_vulnerability_scan |
va, sysdig, xray |
Artefakt |
com.ibm.prod_change_request |
gitlab |
Artefakt (Steuerrad, Bild oder Karte) |
com.ibm.close_change_request |
gitlab |
Artefakt (Steuerrad, Bild oder Karte) |
| com.ibm.cloud.slsa | tekton-chains | Artefakt (Helm, Bild oder Karte) |
Häufig gestellte Fragen
Mein Einsatz ist blockiert - wie kann ich herausfinden, warum?
Wenn Ihre Bereitstellung blockiert ist, gehen Sie folgendermaßen vor, um das Problem zu ermitteln:
- Access Pipeline- Navigieren Sie zu dem spezifischen CD-Pipeline-Lauf, der mit Ihrer Änderung verbunden ist
- Aufgabe suchen- Suchen Sie die Aufgabe mit der Bezeichnung
prod-change-requestund wählen Sie den Schrittchange-request - Review Tables- Suchen Sie zwei kritische Tabellen, indem Sie nach diesen Schlüsselwörtern suchen:
- Tabelle Vermögensumfang: Suche nach
Current pipeline scope(erste Tabelle) - Tabelle zur Überprüfung der Beweise: Suche nach
PRE-DEPLOYMENT(zweite Tabelle)
- Tabelle Vermögensumfang: Suche nach
Die Evidence Check Tabelle zeigt, welche Evidence Items missing oder failed sind, wodurch Ihr Einsatz blockiert werden kann.
Verständnis der Evidence Check Table
Die Tabelle zur Überprüfung der Nachweise zeigt den Validierungsstatus der Nachweise für jedes Asset an. Die Kenntnis ihrer Struktur hilft Ihnen bei der Behebung von Problemen mit der Einhaltung der Vorschriften.
Asset-Tabellenstruktur:
- ID-Spalte: Primärschlüssel zur Identifizierung jedes Assets
- Vollständige_id: Vollständige Asset-ID.
- Typ: Art des Vermögenswerts
- URI-Spalte: Das eigentliche Asset (Bild, Artefakt, etc.), das validiert wird
- Beziehung: Die Asset-ID dient als Fremdschlüssel (
AssetId) in der Tabelle "Evidence Check"
Evidence Check Tabellenstruktur:
- AssetId Spalte: Fremdschlüssel zur Identifizierung jedes Vermögenswerts
- EvidenceTypeId: Gibt an, welcher Konformitätsnachweis erforderlich ist (z. B. Schwachstellenscan, Einheitstests, Peer Review)
- Herkunft der Nachweise: Gibt an, woher die Nachweise stammen sollen (typischerweise
ci-pipeline) - Status: Zeigt für jedes Asset an, ob Beweise vorhanden sind, fehlen oder fehlgeschlagen sind
Struktur der Evidenztabelle:
Diese Tabelle zeigt die Zusammenfassung der Konformitätsnachweise für alle Assets an und gibt an, wie viele Nachweise fehlen, erfolgreich, fehlgeschlagen oder ausstehend sind.
Wie kann ich fehlende oder misslungene Beweise reparieren?
Sobald Sie die fehlenden oder fehlerhaften Beweise in der Tabelle zur Überprüfung der Beweise identifiziert haben, verwenden Sie diesen Entscheidungsbaum, um das Problem zu lösen. Beachten Sie die spezifische Art der Nachweise (z. B. com.ibm.static_scan)
und die Art des Assets (z. B. image, commit).
Frage: "Habe ich meine CI-Pipeline so konfiguriert, dass sie [Beweise] für den [Asset-Typ] sammelt?"
Wenn NEIN (Sie haben es nicht abgeholt):
- Fragen Sie: "Ist dies eine gültige Compliance-Anforderung für meinen Dienst?"
- JA, es ist gültig: Implementieren Sie die Sammlung von Beweisen in Ihrer CI-Pipeline
- Hinzufügen der erforderlichen Scan-Tools oder Skripte
- Konfigurieren Sie geeignete Mechanismen für die Berichterstattung über Beweise
- Sicherstellen, dass die Nachweise mit dem richtigen Asset verknüpft sind
- Einzelheiten zur Umsetzung finden Sie im Leitfaden zur Sammlung von Vermögensnachweisen
- NEIN, es ist nicht anwendbar: Rechtfertigung dokumentieren und eskalieren
- Wenden Sie sich an Ihre Kontaktstelle für Sicherheit
- Erläutern Sie, warum diese Prüfung nicht auf Ihren Dienst zutrifft
- Eine klare Begründung liefern
- Entfernen Sie die Prüfung nach der Genehmigung aus Ihrer Konfigurationsdatei
Wenn JA (Sie haben diese Nachweise bereits gesammelt):
- Untersuchen Sie, warum es in der Tabelle zur Überprüfung der Nachweise als fehlend angezeigt wird
- Mögliche zu prüfende Punkte:
- Werden die Beweise in Ihrer CI-Pipeline korrekt generiert?
- Wird es an die richtige Stelle gemeldet?
- Ist die Asset-ID ordnungsgemäß mit dem Beweismittel verknüpft?
- Gibt es Zeit- oder Synchronisationsprobleme zwischen CI- und CD-Pipelines?
- Ist das Nachweisformat mit den Validierungsanforderungen kompatibel?
- Überprüfen Sie die Pipeline-Protokolle auf Fehlermeldungen im Zusammenhang mit der Beweissammlung oder Berichterstattung
Referenz
Beispielhafte Konfigurationsdatei
{
"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": []
}
]
}
]
}