BuildOccurrence

import type { BuildOccurrence } from "https://googleapis.deno.dev/v1/containeranalysis:v1.ts";

Details of a build occurrence.

interface BuildOccurrence {

intotoProvenance?: InTotoProvenance;

inTotoSlsaProvenanceV1?: InTotoSlsaProvenanceV1;

intotoStatement?: InTotoStatement;

provenance?: BuildProvenance;

provenanceBytes?: string;

}

§Properties

intotoProvenance?: InTotoProvenance

[src]

Deprecated. See InTotoStatement for the replacement. In-toto Provenance representation as defined in spec.

inTotoSlsaProvenanceV1?: InTotoSlsaProvenanceV1

[src]

In-Toto Slsa Provenance V1 represents a slsa provenance meeting the slsa spec, wrapped in an in-toto statement. This allows for direct jsonification of a to-spec in-toto slsa statement with a to-spec slsa provenance.

intotoStatement?: InTotoStatement

[src]

In-toto Statement representation as defined in spec. The intoto_statement can contain any type of provenance. The serialized payload of the statement can be stored and signed in the Occurrence's envelope.

provenance?: BuildProvenance

[src]

The actual provenance for the build.

provenanceBytes?: string

[src]

Serialized JSON representation of the provenance, used in generating the build signature in the corresponding build note. After verifying the signature, provenance_bytes can be unmarshalled and compared to the provenance to confirm that it is unchanged. A base64-encoded string representation of the provenance bytes is used for the signature in order to interoperate with openssl which expects this format for signature verification. The serialized form is captured both to avoid ambiguity in how the provenance is marshalled to json as well to prevent incompatibilities with future changes.