Nachweis

Die Erfassung von Nachweisen ist einer der wesentlichen Aspekte der DevSecOps-Referenzarchitektur. Der Compliance-Nachweis erstellt den Prüfpfad, der von Prüfern während eines Compliance-Audits untersucht wird. Eines der Ziele von DevSecOps ist die automatisierte Nachweisgenerierung und -speicherung in überprüfbaren Nachweissegmenten.

Die Art und Weise, wie die Pipelines von DevSecOps mit Beweisen umgehen (Dateiformat und Schließfachstruktur), ist sehr unterschiedlich:

v2-Angaben (assetbasierte Angaben)

Nachweiserstellung

Nachweise unterscheiden sich von Artefakten, die durch Schritte in Pipelinephasen erstellt werden (z. B. Einheitentestergebnisse oder XML- bzw. JSON-Dateien). Jede Task muss an mehrere Tools berichten, die Nachweise verarbeiten, beispielsweise durch das Erstellen, Formatieren und Speichern von Nachweisen.

Jeder generischer Test-, Prüf- oder Suchlauf kann in einer Pipelinephase einen Nachweis mithilfe der Schritte in DevSecOps-Tools oder -Pipelines erzeugen, die in der folgenden Abbildung dargestellte sind. Die Tools von DevSecOps müssen in der Lage sein, das Ergebnis der Aufgabe zu empfangen, den Beweis zu erstellen und ihn dann im Asservatenschrank zu speichern.

Das Nachweisformat enthält das Ergebnis der Task (bestanden oder fehlgeschlagen), Links zu den erstellten Artefakten sowie Links zu jedem etwaigen Vorfallproblem, das auf der Basis des Taskergebnisses erstellt wird.

Schwerpunkt dieser Tools ist ausschließlich die Nachweiserfassung; das Verhalten Ihres Buildprozesses wird von ihnen nicht geändert. Die DevSecOps-Referenzpipeline wird aufgrund von fehlgeschlagenen Taskergebnissen nicht unterbrochen. Ein Image kann mit fehlgeschlagenen Tests und Sicherheitslücken erstellt und bereitgestellt werden, wenn Nachweise der Prüfungen und Fehler vorhanden sind, das Team benachrichtigt wird, eine Änderungsanforderung, die während der Bereitstellung erstellt wird, einen Nachweis dieser Probleme enthält und die Änderungsanforderung manuell genehmigt wird.

Nachweisablauf

Das folgende Diagramm zeigt, wie die Nachweise gehandhabt werden und wie sie die Phasen der kontinuierlichen Integration und der kontinuierlichen Bereitstellung durchlaufen.

Jeder Nachweisteil, der in den einzelnen Phasen der DevOps-Architektur erfasst wird, wird in überprüfbaren Nachweisaufbewahrungssegmenten gespeichert. Dieser Nachweis wird während der Bereitstellung zur Erstellung einer Nachweiszusammenfassung erfasst, die am Ende der Bereitstellungsausführung in der Nachweisaufbewahrung gespeichert wird.

Die Nachweiszusammenfassung ist der Änderungsanforderung zugeordnet, die an den Änderungsanforderungsspeicher gesendet wird. Während einer manuellen Genehmigung der Änderungsanforderung hat der Genehmiger Kenntnis von allen etwaigen Problemen, die während des Builds festgestellt werden.

v2-Angaben (aktuelles Format)

v2-Angabensperre

Die Beweise werden in einer flachen Hierarchie gespeichert, in der jedes Beweisstück durch seinen eigenen SHA256 Hash identifiziert wird, was einen Integritätsschutz bietet (d.h. jede Änderung des Beweismaterials kann erkannt werden). Da jedes Beweisstück mit einem oder mehreren Assets verbunden ist, ermitteln die Algorithmen zur Beweiszusammenfassung die relevanten Beweise auf der Grundlage der Assets.

Die einzige Hierarchie ist die Typendifferenzierung und einige Hashgruppierungen ähnlich der Struktur von Git-Hashobjekten.

Beispiel

.
└── 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

Angabensammlung v2

Die v2-Angaben müssen so nah wie möglich an dem Prozess erfasst werden, der das Ergebnis für eine Angabe erstellt hat. Nach jeder Scanausführung, z. B. nach jedem Test.

Zum Sammeln von Beweisen kann das Skript „Collect-Evidence“ in den DevSecOps-Pipelines verwendet werden.

Angabenformat v2

Ein Teil der Angaben stellt das Ergebnis eines Scans, Tests usw. dar. Die Angaben sind immer mit mindestens einem Asset verbunden. Mehrere Assets sind zulässig, z. B. eine einzelne End-to-End-Testsuite, die wahrscheinlich mehrere Assets zusammen testet.

Ein Asset stellt etwas dar, das Sie testen, scannen usw. können, z. B. ein Git commit in einem Repository oder ein Docker image oder ein beliebiges generic Asset mit einem URI.

Die Typen Evidence und Asset stellen das Schema der Sperrenelemente v2 dar: 'evidence' und 'asset '. Das Schema verwendet zwar die Typescript-Syntax, kann aber in ein JSON-Schema konvertiert werden.

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[];
}

Beispiel

Beispielasset 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"
  ]
}

Beispiel für v2-Angaben

{
  "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"
    }
  ]
}

Zusammenfassung der v2-Angaben

Die DevSecOps-Pipeline erstellt ein Dokument mit einer Zusammenfassung des Nachweises. Dieses Dokument enthält die neuesten Nachweise, die während der einzelnen kontinuierlichen Integrations-Builds, die ein Image bereitstellen, erstellt werden, sowie die Nachweise, die während der Bereitstellung selbst erstellt werden. Die Zusammenfassung wird für die Änderungsanforderung erstellt, die zum Implementieren einer beliebigen Phase erforderlich ist.

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[];
}

Diese Zusammenfassung führt keine Ergebnisaggregation durch. Es handelt sich um die Rohdaten der gesammelten Nachweise für „ v2 “, wie sie für Assets gefunden wurden, die mit einem Änderungsantrag in Zusammenhang stehen.