Preuve

La collecte de preuves est l'un des aspects essentiels de l'architecture de référence DevSecOps. Les preuves de conformité créent la trace d'audit que les auditeurs recherchent lors d'un audit de conformité. L'un des objectifs de DevSecOps consiste à générer et stocker de manière automatisée des preuves dans des éléments de verrouillage des preuves vérifiables.

La façon dont les pipelines DevSecOps traitent les preuves (format de fichier et structure de casier) est la suivante :

Informations collectées v2 (informations collectées basées sur des actifs)

Création de preuves

Les preuves diffèrent des artefacts qui sont créés par les étapes de pipeline, par exemple, les résultats de test d'unité ou les fichiers XML ou JSON. Chaque tâche doit rendre compte à plusieurs outils qui gèrent les preuves, comme la création, le formatage et le stockage de preuves.

N'importe quel test, n'importe quelle vérification ou n'importe quelle analyse peut produire des preuves dans une étape de pipeline à l'aide des étapes des outils ou pipelines DevSecOps qui sont illustrés dans l'image ci-après. Les outils DevSecOps doivent être en mesure de recevoir le résultat de la tâche, de créer la preuve et de la stocker dans le casier à preuves.

Le format des preuves contient le résultat de la tâche (réussite ou échec), des liens vers les artefacts créés et des liens vers n'importe quel incident qui est créé en fonction du résultat de la tâche.

Ces outils se concentrent uniquement sur la collecte de preuves et ne modifient en rien le comportement de votre processus de génération. Le pipeline de référence DevSecOps ne se rompt pas lorsqu'une tâche échoue. Une image peut être générée et déployée avec des tests qui échouent et des vulnérabilités si les preuves des vérifications et des échecs existent. L'équipe est avertie, une demande de changement créée durant le déploiement contient les preuves de ces incidents, et elle est approuvée manuellement.

Flux de preuves

Le diagramme suivant montre comment les preuves sont traitées et comment elles passent par les étapes de l'intégration et du déploiement continus.

Chaque élément de preuve qui est collecté au cours des différentes étapes de l'architecture DevOps est stocké dans des éléments de verrouillage des preuves vérifiables. Lors du déploiement, ces preuves sont collectées pour créer un récapitulatif de preuves qui est sauvegardé dans le casier de preuves à la fin de l'exécution de déploiement.

Le récapitulatif de preuves est connecté à la demande de changement, qui est publiée dans le magasin de demandes de changement. Lors d'une approbation manuelle de demande de changement, l'approbateur a connaissance des incidents trouvés lors de la génération.

Informations collectées v2 (format en cours)

Verrouilleur de preuve v2

Les preuves sont stockées dans une hiérarchie plate, où chaque élément de preuve est identifié par son propre hachage SHA256, ce qui fournit une couche de protection de l'intégrité (c'est-à-dire que toute modification du contenu de la preuve peut être détectée). Comme chaque élément de preuve est lié à un ou plusieurs actifs, les algorithmes de synthèse des preuves découvrent les éléments de preuve pertinents en fonction des actifs.

La seule hiérarchie est la différenciation des types et un regroupement de hachage similaire à la structure des objets de hachage Git.

Exemple

.
└── raw/
    ├── assets/
    │   └── xx/
    │       └── abcdef123456789/
    │           ├── evidences/
    │           │   ├── 00abcdef123456789
    │           │   └── 01abcdef123456789
    │           └── index.json
    ├── attachments/
    │   ├── aa/
    │   │   └── abcdef123456789/
    │   │       └── content
    │   └── ab/
    │       └── abcdef123456789/
    │           └── content
    ├── cd/
    │   ├── c9b77749-fd59-4d32-bbdb-18e55db1615d/
    │          └── summary.json
    |          └── evdience-checks.json
    ├── cc/
    │   ├── absd7749-fd59-4d32-bbdb-18e55db1615d/
    │          └── summary.json
    |          └── evdience-checks.json              
    └── evidences/
        ├── 00/
        │   └── abcdef123456789/
        │       └── index.json
        └── 01 /
            └── abcdef123456789/
                └── index.json

Collection d'informations collectées v2

Les informations collectées v2 doivent être collectées aussi près que possible du processus qui a créé le résultat pour les informations collectées. Après chaque exécution d'examen, après chaque test par exemple.

Pour collecter des preuves, le script collect-evidence peut être utilisé dans les pipelines DevSecOps.

Format d'informations collectées v2

Un élément d'informations collectées représente le résultat d'un examen, d'un test, etc. Les informations collectées sont toujours connectées à au moins un actif unique. Plusieurs actifs sont autorisés, par exemple une suite de tests de bout en bout unique qui teste probablement plusieurs actifs ensemble.

Un actif représente quelque chose que vous pouvez tester, analyser, etc., tel qu'un Git commit dans un référentiel ou un image docker, ou tout actif generic avec un URI.

Les types Evidence et Asset représentent le schéma des éléments de verrouillage v2: preuve et actif. Le schéma utilise une syntaxe typescript, mais vous pouvez le convertir pour utiliser un schéma JSON.

type SHA1 = string;          // 40 character string representing a SHA-1 hash in hexadecimal format
type SHA256 = string;        // 64 character string representing a SHA256 hash in hexadecimal format
type IssueURL = string;      // Link to issues on a git service provide like GitHub or GitLab
type RepositoryURL = string; // Link to a git repository
type AssetURI = string;      // URI of an Asset, like an image or a repository link and git hash
type FileName = string;      // file basename of the attachment


interface Evidence {
  version: 2;
  id: SHA256;
  date: string;
  evidence_type_id: string;
  evidence_type_version: string;
  origin: {
    // scope defines a contextual set for multiple evidence, usually a SHA256 identifier or a CI/CD run ID
    scope: SHA256;  

    // any further IDs can be used to determine evidence origin, see example
    [index: string]: string;
  },
  details: {
    result: 'success' | 'failure' | 'pending';
    tool: string;

    // field "details" can have any arbitrary key-value pairs to provide metadata
    [index: string]: string;
  }
  attachments: Record<string, string> | EvidenceAssetAttachment[];
  assets: string[] | EvidenceAssetAttachment[];
  issues: IssueURL[],
  findings?: IncidentFinding[];
}

export interface IncidentFinding {
  id: string;
  url: string;
  due_date: string;
  first_found?: string;
  severity: ("high", "medium", "low", "critical, "informational");
  has_exempt: boolean;
  found_status: ("new", "existing", "autoclosed", "readonly");
}

export interface EvidenceAssetAttachment {
  url: string; // hash of the asset or attachment
  hash: string; // complete url of the asset or attachment
  uri?: string; // name of the asset
}

interface Asset {
    version: 1;
    id: SHA256;
    uri: AssetURI;
    date: string;
    type: 'commit' | 'image' | 'generic';
    origin: {
      // any IDs can be used to determine asset origin, see example
      [index: string]: string;
    },
    details: Record<string, string>,

    // Assets can relate to each other, for example
    // an Image Asset can relate to the Git Commit Asset
    // it was built from on code level
    related: SHA256[];
}

Exemple

Exemple d'actif v2

{
  "version": "1",
  "id": "cdd3ee20188d2f5bfb7f14bdb9c7fa99b22184ca195d9fa0a953dfbe9b1769cb",
  "uri": "https://github.com/<org-name>/e2e-hello-compliance-app-20220412084808399.git#8c2a65373cb4fd27bccff646e8bdf63d02cae856",
  "origin": {
    "toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/40111714589c4f7099032529b26a7a63:fd3f2bf6-00f1-417f-b1a2-7df894223115::",
    "pipeline_run_id": "a5e89ecc-a413-4dcb-b129-ff870ef3be85",
    "pipeline_id": "66b583d9-3d1b-4b34-9e3a-cb807bf0c5ab"
  },
  "details": {
    "sha": "8c2a65373cb4fd27bccff646e8bdf63d02cae856",
    "repository": "https://github.com/<org-name>/e2e-hello-compliance-app-20220412084808399.git"
  },
  "date": "2022-04-20T09:26:46.226Z",
  "type": "commit",
  "related": [
    "26a0f02126461e6505d5001d50ac71e585c280479a01cc70e36397a784440bf8"
  ]
}

Exemple d'informations collectées v2

{
  "version": "2",
  "id": "3fd209270fbaf46137ec3966affac2a431a835e750301c7c44d583e0e426e29e",
  "date": "2022-04-20T09:33:43.782Z",
  "evidence_type_id": "com.ibm.code_vulnerability_scan",
  "evidence_type_version": "1.0.0",
  "details": {
    "result": "failure",
    "tool": "cra"
  },
  "origin": {
    "toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/779c0808c946b9e15cc2e63013fded8c:68213c68-4794-4d5e-ab50-f33d0d6190e4::",
    "pipeline_id": "c17f18a6-24dd-4949-abb7-2b374f4691b6",
    "pipeline_run_id": "d7a88836-72a1-402b-bb28-701439a543ae",
    "pipeline_run_url": "https://cloud.ibm.com/devops/pipelines/tekton/c17f18a6-24dd-4949-abb7-2b374f4691b6/runs/d7a88836-72a1-402b-bb28-701439a543ae/code-compliance-checks/run-stage/?env_id=ibm:yp:us-south",
    "scope": "117458e26512b0308d93cf6852958e5e875294a982d2b4ea2e9f463b4551a846"
  },
  "assets": [
    {
      "hash": "cdd3ee20188d2f5bfb7f14bdb9c7fa99b22184ca195d9fa0a953dfbe9b1769cb",
      "uri": "https://github.com/<org-name>/e2e-hello-compliance-app-20220412084808399.git#8c2a65373cb4fd27bccff646e8bdf63d02cae856",
      "url": "https://s3.private.us-south.cloud-object-storage.appdomain.cloud/test/assets/cdd3ee20188d2f5bfb7f14bdb9c7fa99b22184ca195d9fa0a953dfbe9b1769cb/index.json"
    }
  ],
  "issues": [
    "https://github.com/<org-name>/e2e-compliance-incident-issues-20220412084808401/issues/1",
    "https://github.com/<org-name>/e2e-compliance-incident-issues-20220412084808401/issues/2",
    "https://github.com/<org-name>/e2e-compliance-incident-issues-20220412084808401/issues/3",
  ],
  "findings": [
    {
      "id": "CVE-2022-42011",
      "due_date": "2024-04-20",
      "severity": "medium",
      "first_found": "2024-03-06",
      "url": "https://github.com/<org-name>/e2e-compliance-incident-issues-20220412084808401/issues/3",
      "found_status": "new",
      "has_exempt": true
    },
    {
      "id": "CVE-2022-42010",
      "due_date": "2024-04-20",
      "severity": "medium",
      "first_found": "2024-03-06",
      "url": "https://github.com/<org-name>/e2e-compliance-incident-issues-20220412084808401/issues/1",
      "found_status": "existing",
      "has_exempt": false
    },
    {
      "id": "CVE-2023-34969",
      "due_date": "2024-04-20",
      "severity": "medium",
      "first_found": "2024-03-06",
      "url": "https://github.com/<org-name>/e2e-compliance-incident-issues-20220412084808401/issues/2",
      "found_status": "existing",
      "has_exempt": true
    }
  ],
  "attachments": [
    {
      "hash": "9a841ef856a5de813dbe440b102b9bff3ca1831630292cff7323c557704f386b",
      "url": "https://s3.private.us-south.cloud-object-storage.appdomain.cloud/test/assets/9a841ef856a5de813dbe440b102b9bff3ca1831630292cff7323c557704f386b/index.json"
    }
  ]
}

Récapitulatif des informations collectées v2

Le pipeline DevSecOps crée un document récapitulant les preuves. Ce document contient les preuves les plus récentes créées lors de chaque intégration continue qui déploie une image, ainsi que les preuves créées lors du déploiement lui-même. Le récapitulatif est créé pour la demande de changement requise pour déployer une étape.

interface Summary {
  version: '2.0';                // schema version
  date: string;                  // ISO-8601, UTC, ie. YYYY-MM-DDThh:mm:ssZ
  toolchain_crn: string;         // CRN of the toolchain that generated the summary
  pipeline_id: string;           // ID of the pipeline that generated the summary
  pipeline_run_id: string;       // ID of the pipeline run that generated the summary
  evidences: Evidence[];
}

Ce récapitulatif n'effectue aucune agrégation de résultats. Il s'agit des données brutes des preuves d' v2 s collectées, telles qu'elles ont été trouvées pour les actifs liés à une demande de modification.