Modules§

Structs§

  • An alias to a repo revision.
  • Artifact describes a build product.
  • Note kind that represents a logical attestation “role” or “authority”. For example, an organization might have one Authority for “QA” and one for “build”. This note is intended to act strictly as a grouping mechanism for the attached occurrences (Attestations). This grouping mechanism also provides a security boundary, since IAM ACLs gate the ability for a principle to attach an occurrence to a given note. It also provides a single point of lookup to find all attached attestation occurrences, even if they don’t all live in the same project.
  • Occurrence that represents a single “attestation”. The authenticity of an attestation can be verified using the attached signature. If the verifier trusts the public key of the signer, then verifying the signature is sufficient to establish trust. In this circumstance, the authority to which this attestation is attached is primarily useful for lookup (how to find this attestation if you already know the authority and artifact to be verified) and intent (for which authority this attestation was intended to sign.
  • Request to create notes in batch.
  • Response for creating notes in batch.
  • Request to create occurrences in batch.
  • Response for creating occurrences in batch.
  • Note holding the version of the provider’s builder and the signature of the provenance message in the build details occurrence.
  • Details of a build occurrence.
  • Provenance of a build. Contains all information needed to verify the full details about the build from source to completion.
  • A CloudRepoSourceContext denotes a particular revision in a Google Cloud Source Repo.
  • Command describes a step performed as part of the build pipeline.
  • Indicates that the builder claims certain fields in this message to be complete.
  • An indication that the compliance checks in the associated ComplianceNote were not satisfied for particular resources or a specified reason.
  • Describes the CIS benchmark version that is applicable to a given OS and os version.
  • Request to create a new note.
  • Request to create a new occurrence.
  • Common Vulnerability Scoring System version 3. For details, see https://www.first.org/cvss/specification-document
  • Common Vulnerability Scoring System. For details, see https://www.first.org/cvss/specification-document This is a message we will try to use for storing various versions of CVSS rather than making a separate proto for storing a specific version.
  • Request to delete a note.
  • Request to delete an occurrence.
  • An artifact that can be deployed in some runtime.
  • The period during which some deployable was active in a runtime.
  • Digest information.
  • A note that indicates a type of analysis a provider would perform. This note exists in a provider’s project. A Discovery occurrence is created in a consumer’s project at the start of analysis.
  • Provides information about the analysis status of a discovered resource.
  • This represents a particular channel of distribution for a given package. E.g., Debian’s jessie-backports dpkg mirror.
  • Deprecated. Prefer to use a regular Occurrence, and populate the Envelope at the top level of the Occurrence.
  • MUST match https://github.com/secure-systems-lab/dsse/blob/master/envelope.proto. An authenticated message of arbitrary type.
  • Container message for hashes of byte content of files, used in source messages to verify integrity of source input to the build.
  • Indicates the location at which a package was found.
  • A set of properties that uniquely identify a given Docker image.
  • A SourceContext referring to a Gerrit project.
  • Request to get a note.
  • Request to get the note to which the specified occurrence is attached.
  • Request to get an occurrence.
  • A GitSourceContext denotes a particular revision in a third party Git repository (e.g., GitHub).
  • Container message for hash values.
  • Basis describes the base image portion (Note) of the DockerImage relationship. Linked occurrences are derived from this or an equivalent image via: FROM <Basis.resource_url> Or an equivalent reference, e.g., a tag of the resource_url.
  • Details of the derived image portion of the DockerImage relationship. This image would be produced from a Dockerfile with FROM <DockerImage.Basis in attached Note>.
  • Spec defined at https://github.com/in-toto/attestation/tree/main/spec#statement The serialized InTotoStatement will be stored as Envelope.payload. Envelope.payloadType is always “application/vnd.in-toto+json”.
  • Layer holds metadata specific to a layer of a Docker image.
  • License information.
  • Request to list occurrences for a note.
  • Response for listing occurrences for a note.
  • Request to list notes.
  • Response for listing notes.
  • Request to list occurrences.
  • Response for listing occurrences.
  • An occurrence of a particular package installation found within a system’s filesystem. E.g., glibc was found in /var/lib/dpkg/status.
  • Other properties of the build.
  • Details about files that caused a compliance check to fail.
  • A type of analysis that can be done for a resource.
  • An instance of an analysis type that has been found on a resource.
  • PackageNote represents a particular package version.
  • Details on how a particular software package was installed on a system.
  • Selects a repo using a Google Cloud Platform project ID (e.g., winged-cargo-31) and a repo name within that project.
  • Steps taken to build the artifact. For a TaskRun, typically each container corresponds to one step in the recipe.
  • Metadata for any related URL information.
  • A unique identifier for a Cloud Repo.
  • The actual payload that contains the SBOM Reference data. The payload follows the intoto statement specification. See https://github.com/in-toto/attestation/blob/main/spec/v1.0/statement.md for more details.
  • A predicate which describes the SBOM being referenced.
  • The note representing an SBOM reference.
  • The occurrence representing an SBOM reference as applied to a specific resource. The occurrence follows the DSSE specification. See https://github.com/secure-systems-lab/dsse/blob/master/envelope.md for more details.
  • Verifiers (e.g. Kritis implementations) MUST verify signatures with respect to the trust anchors defined in policy (e.g. a Kritis policy). Typically this means that the verifier has been configured with a map from public_key_id to public key material (and any required parameters, e.g. signing algorithm).
  • See full explanation of fields at slsa.dev/provenance/v0.2.
  • Source describes the location of the source used for the build.
  • A SourceContext is a reference to a tree of files. A SourceContext together with a path point to a unique revision of a single file or directory.
  • Request to update a note.
  • Request to update an occurrence.
  • The Upgrade Distribution represents metadata about the Upgrade for each operating system (CPE). Some distributions have additional metadata around updates, classifying them into various categories and severities.
  • An Upgrade Note represents a potential upgrade of a package to a given version. For each package version combination (i.e. bash 4.0, bash 4.1, bash 4.1.2), there will be an Upgrade Note. For Windows, windows_update field represents the information related to the update.
  • An Upgrade Occurrence represents that a specific resource_url could install a specific upgrade. This presence is supplied via local sources (i.e. it is present in the mirror and the running system has noticed its availability). For Windows, both distribution and windows_update contain information for the Windows update.
  • Version contains structured information about the version of a package.
  • A single VulnerabilityAssessmentNote represents one particular product’s vulnerability assessment for one CVE.
  • A security vulnerability that can be found in resources.
  • An occurrence of a severity vulnerability on a resource.
  • Windows Update represents the metadata about the update for the Windows operating system. The fields in this message come from the Windows Update API documented at https://docs.microsoft.com/en-us/windows/win32/api/wuapi/nn-wuapi-iupdate.

Enums§

  • Instruction set architectures supported by various package managers.
  • CVSS Version.
  • Kind represents the kinds of notes supported.
  • Note provider assigned severity/impact ranking.