diff --git a/docs/spec/draft/att-build-provenance.md b/docs/spec/draft/att-build-provenance.md new file mode 100644 index 000000000..a6f731728 --- /dev/null +++ b/docs/spec/draft/att-build-provenance.md @@ -0,0 +1,617 @@ +--- +title: Attestation format: Build Provenance +description: Description of SLSA build provenance specification for verifying where, when, and how something was produced. +layout: standard +--- + +# {Attestation format: Build Provenance} + +To trace software back to the source and define the moving parts in a complex +supply chain, provenance needs to be there from the very beginning. It's the +verifiable information about software artifacts describing where, when, and how +something was produced. For higher SLSA levels and more resilient integrity +guarantees, provenance requirements are stricter and need a deeper, more +technical understanding of the predicate. + +This page use the following predicate type within the [in-toto +attestation] framework: + +```json +"predicateType": "https://slsa.dev/provenance/v1" +``` + +> **Note**: Always use the above string for `predicateType` rather than what is +> in the URL bar. The `predicateType` URI will always resolve to the latest +> minor version of this specification. See [parsing rules](#parsing-rules) for +> more information. + +The above predicate is the RECOMMENDED way to satisfy the SLSA v1.0 [provenance +requirements](requirements#provenance-generation). + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). + +## Purpose of provenance + +Provenance describes how an artifact or set of artifacts was produced so that: + +- Consumers of the provenance can verify that the artifact was built according + to expectations. +- Others can rebuild the artifact, if desired. + +## Build provenance attestation model + +Provenance is an attestation that a particular build platform produced a set of +software artifacts through execution of the `buildDefinition`. + +![Build Model](images/provenance-model.svg) + +> **Note:** This diagram depicts how the SLSA Provenance format is structured. It +> elaborates on the [SLSA Build Model](terminology#build-model) but only applies +> to the SLSA Provenance format specifically and not to builds in general. + +### How the build creates provenance + +- Each build runs as an independent process on a multi-tenant build platform. + The `builder.id` identifies this platform, representing the transitive + closure of all entities that are [trusted] to faithfully run the build and + record the provenance. + + > **Note**: The same model can be used for platform-less or single-tenant build platforms. + + - The build platform implementer SHOULD define a security model for the build + platform in order to clearly identify the platform's boundaries, actors, + and interfaces. This model SHOULD then be used to identify the transitive + closure of the trusted build platform for the `builder.id` as well as the + trusted control plane. + +- The build process is defined by a parameterized template, identified by + `buildType`. This encapsulates the process that ran, regardless of what + platform ran it. Often the build type is specific to the build platform + because most build platforms have their own unique interfaces. + +- All top-level, independent inputs are captured by the parameters to the + template. There are two types of parameters: + + - `externalParameters`: the external interface to the build. In SLSA, + these values are untrusted; they MUST be included in the provenance and + MUST be verified downstream. + + - `internalParameters`: set internally by the platform. In SLSA, these + values are trusted because the platform is trusted; they are OPTIONAL + and need not be verified downstream. They MAY be included to enable + reproducible builds, debugging, or incident response. + +- All artifacts fetched during initialization or execution of the build + process are considered dependencies, including those referenced directly by + parameters. The `resolvedDependencies` captures these dependencies, if + known. For example, a build that takes a git repository URI as a parameter + might record the specific git commit that the URI resolved to as a + dependency. + +- During execution, the build process might communicate with the build + platform's control plane and/or build caches. This communication is not + captured directly in the provenance, but is instead implied by `builder.id` + and subject to [SLSA Requirements](requirements.md). Such + communication SHOULD NOT influence the definition of the build; if it does, + it SHOULD go in `resolvedDependencies` instead. + +- Finally, the build process outputs one or more artifacts, identified by + `subject`. + +For concrete examples, see [index of build types](#index-of-build-types). + +### Provenance parsing best practices + +The predicate used in this page follows the in-toto attestation [parsing rules]: + +- Consumers MUST ignore unrecognized fields unless otherwise noted. +- The `predicateType` URI includes the major version number and will always + change whenever there is a backwards incompatible change. +- Minor version changes are always backwards compatible and "monotonic." + Such changes do not update the `predicateType`. +- Unset, null, and empty field values MUST be interpreted equivalently. + +## Build provenance schema definitions + +This schema defines the fields of the build provenance attestation. + +### Summary + +**Note:** This summary (in cue) is informative. In the event of a +disagreement with the text description, the text is authoritative.* + + + +```javascript +{% include_relative schema/provenance.cue %} +``` + +
+Protocol buffer schema + +**Note:** This summary (in protobuf) is informative. In the event of a +disagreement with the text description, the text is authoritative.* + +Link: [provenance.proto](schema/provenance.proto) + +**Note:** This protobuf definition prioritizes being a human-readable summary +of the schema for readers of the specification. A version of the protobuf +definition useful for code generation is maintained in the +[in-toto attestation] repository.* + +```proto +{% include_relative schema/provenance.proto %} +``` + +
+ +### Provenance + +**Note:** This section describes the fields within `predicate`. For a description +of the other top-level fields, such as `subject`, see [Statement].* + +[Provenance]: #provenance + +REQUIRED for SLSA Build L1: `buildDefinition`, `runDetails` + + +
FieldTypeDescription + +
buildDefinition +BuildDefinition + +The input to the build. The accuracy and completeness are implied by +`runDetails.builder.id`. + +
runDetails +RunDetails + +Details specific to this particular execution of the build. + +
+ +### BuildDefinition + +[BuildDefinition]: #builddefinition + +REQUIRED for SLSA Build L1: `buildType`, `externalParameters` + + +
FieldTypeDescription + +
buildType +string (TypeURI) + +Identifies the template for how to perform the build and interpret the +parameters and dependencies. + +The URI SHOULD resolve to a human-readable specification that includes: overall +description of the build type; schema for `externalParameters` and +`internalParameters`; unambiguous instructions for how to initiate the build given +this BuildDefinition, and a complete example. Example: +https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1 + +
externalParameters +object + +The parameters that are under external control, such as those set by a user or +tenant of the build platform. They MUST be complete at SLSA Build L3, meaning that +there is no additional mechanism for an external party to influence the +build. (At lower SLSA Build levels, the completeness MAY be best effort.) + +The build platform SHOULD be designed to minimize the size and complexity of +`externalParameters`, in order to reduce fragility and ease [verification]. +Consumers SHOULD have an expectation of what "good" looks like; the more +information that they need to check, the harder that task becomes. + +Verifiers SHOULD reject unrecognized or unexpected fields within +`externalParameters`. + +
internalParameters +object + +The parameters that are under the control of the entity represented by +`builder.id`. The primary intention of this field is for debugging, incident +response, and vulnerability management. The values here MAY be necessary for +reproducing the build. There is no need to [verify][Verification] these +parameters because the build platform is already trusted, and in many cases it is +not practical to do so. + +
resolvedDependencies +array (ResourceDescriptor) + +Unordered collection of artifacts needed at build time. Completeness is best +effort, at least through SLSA Build L3. For example, if the build script +fetches and executes "example.com/foo.sh", which in turn fetches +"example.com/bar.tar.gz", then both "foo.sh" and "bar.tar.gz" SHOULD be +listed here. + +
+ +The BuildDefinition describes all of the inputs to the build. It SHOULD contain +all the information necessary and sufficient to initialize the build and begin +execution. + +The `externalParameters` and `internalParameters` are the top-level inputs to the +template, meaning inputs not derived from another input. Each is an arbitrary +JSON object, though it is RECOMMENDED to keep the structure simple with string +values to aid verification. The same field name SHOULD NOT be used for both +`externalParameters` and `internalParameters`. + +The parameters SHOULD only contain the actual values passed in through the +interface to the build platform. Metadata about those parameter values, +particularly digests of artifacts referenced by those parameters, SHOULD instead +go in `resolvedDependencies`. The documentation for `buildType` SHOULD explain +how to convert from a parameter to the dependency `uri`. For example: + +```json +"externalParameters": { + "repository": "https://github.com/octocat/hello-world", + "ref": "refs/heads/main" +}, +"resolvedDependencies": [{ + "uri": "git+https://github.com/octocat/hello-world@refs/heads/main", + "digest": {"gitCommit": "7fd1a60b01f91b314f59955a4e4d4e80d8edf11d"} +}] +``` + +Guidelines: + +- Maximize the amount of information that is implicit from the meaning of + `buildType`. In particular, any value that is boilerplate and the same + for every build SHOULD be implicit. + +- Reduce parameters by moving configuration to input artifacts whenever + possible. For example, instead of passing in compiler flags via an external + parameter that has to be [verified][Verification] separately, require the + flags to live next to the source code or build configuration so that + verifying the latter automatically verifies the compiler flags. + +- In some cases, additional external parameters might exist that do not impact + the behavior of the build, such as a deadline or priority. These extra + parameters SHOULD be excluded from the provenance after careful analysis + that they indeed pose no security impact. + +- If possible, architect the build platform to use this definition as its + sole top-level input, in order to guarantee that the information is + sufficient to run the build. + +- When build configuration is evaluated client-side before being sent to the + server, such as transforming version-controlled YAML into ephemeral JSON, + some solution is needed to make [verification] practical. Consumers need a + way to know what configuration is expected and the usual way to do that is + to map it back to version control, but that is not possible if the server + cannot verify the configuration's origins. Possible solutions: + + - (RECOMMENDED) Rearchitect the build platform to read configuration + directly from version control, recording the server-verified URI in + `externalParameters` and the digest in `resolvedDependencies`. + + - Record the digest in the provenance[^digest-param] and use a separate + provenance attestation to link that digest back to version control. In + this solution, the client-side evaluation is considered a separate + "build" that SHOULD be independently secured using SLSA, though securing + it can be difficult since it usually runs on an untrusted workstation. + +- The purpose of `resolvedDependencies` is to facilitate recursive analysis of + the software supply chain. Where practical, it is valuable to record the + URI and digest of artifacts that, if compromised, could impact the build. At + SLSA Build L3, completeness is considered "best effort". + +[^digest-param]: The `externalParameters` SHOULD reflect reality. If clients + send the evaluated configuration object directly to the build server, record + the digest directly in `externalParameters`. If clients upload the + configuration object to a temporary storage location and send that location + to the build server, record the location in `externalParameters` as a URI + and record the `uri` and `digest` in `resolvedDependencies`. + +### RunDetails + +[RunDetails]: #rundetails + +REQUIRED for SLSA Build L1: `builder` + + +
FieldTypeDescription + +
builder +Builder + +Identifies the build platform that executed the invocation, which is trusted to +have correctly performed the operation and populated this provenance. + +
metadata +BuildMetadata + +Metadata about this particular execution of the build. + +
byproducts +array (ResourceDescriptor) + +Additional artifacts generated during the build that are not considered +the "output" of the build but that might be needed during debugging or +incident response. For example, this might reference logs generated during +the build and/or a digest of the fully evaluated build configuration. + +In most cases, this SHOULD NOT contain all intermediate files generated during +the build. Instead, this SHOULD only contain files that are likely to be useful +later and that cannot be easily reproduced. + +
+ +### Builder + +[Builder]: #builder + +REQUIRED for SLSA Build L1: `id` + + +
FieldTypeDescription + +
id +string (TypeURI) + +URI indicating the transitive closure of the trusted build platform. This is +[intended](verifying-artifacts#step-1-check-slsa-build-level) +to be the sole determiner of the SLSA Build level. + +If a build platform has multiple modes of operations that have differing +security attributes or SLSA Build levels, each mode MUST have a different +`builder.id` and SHOULD have a different signer identity. This is to minimize +the risk that a less secure mode compromises a more secure one. + +The `builder.id` URI SHOULD resolve to documentation explaining: + +- The scope of what this ID represents. +- The claimed SLSA Build level. +- The accuracy and completeness guarantees of the fields in the provenance. +- Any fields that are generated by the tenant-controlled build process and not + verified by the trusted control plane, except for the `subject`. +- The interpretation of any extension fields. + +
builderDependencies +array (ResourceDescriptor) + +Dependencies used by the orchestrator that are not run within the workload +and that do not affect the build, but might affect the provenance generation +or security guarantees. + +
version +map (string→string) + +Map of names of components of the build platform to their version. + +
+ +The build platform, or builder for short, represents the transitive +closure of all the entities that are, by necessity, [trusted] to faithfully run +the build and record the provenance. This includes not only the software but the +hardware and people involved in running the service. For example, a particular +instance of [Tekton](https://tekton.dev/) could be a build platform, while +Tekton itself is not. For more info, see [Build +model](terminology#build-model). + +The `id` MUST reflect the trust base that consumers care about. How detailed to +be is a judgement call. For example, GitHub Actions supports both GitHub-hosted +runners and self-hosted runners. The GitHub-hosted runner might be a single +identity because it's all GitHub from the consumer's perspective. Meanwhile, +each self-hosted runner might have its own identity because not all runners are +trusted by all consumers. + +Consumers MUST accept only specific signer-builder pairs. For example, "GitHub" +can sign provenance for the "GitHub Actions" builder, and "Google" can sign +provenance for the "Google Cloud Build" builder, but "GitHub" cannot sign for +the "Google Cloud Build" builder. + +Design rationale: The builder is distinct from the signer in order to support +the case where one signer generates attestations for more than one builder, as +in the GitHub Actions example above. The field is REQUIRED, even if it is +implicit from the signer, to aid readability and debugging. It is an object to +allow additional fields in the future, in case one URI is not sufficient. + +### BuildMetadata + +[BuildMetadata]: #buildmetadata + +REQUIRED: (none) + + +
FieldTypeDescription + +
invocationId +string + +Identifies this particular build invocation, which can be useful for finding +associated logs or other ad-hoc analysis. The exact meaning and format is +defined by `builder.id`; by default it is treated as opaque and case-sensitive. +The value SHOULD be globally unique. + +
startedOn +string (Timestamp) + +The timestamp of when the build started. + +
finishedOn +string (Timestamp) + +The timestamp of when the build completed. + +
+ +### Extension fields + +[Extension fields]: #extension-fields + +Implementations MAY add extension fields to any JSON object to describe +information that is not captured in a standard field. Guidelines: + +- Extension fields SHOULD use names of the form `_`, e.g. + `examplebuilder_isCodeReviewed`. This practice avoids field name collisions + by namespacing each vendor. Non-extension field names never contain an + underscore. +- Extension fields MUST NOT alter the meaning of any other field. In other + words, an attestation with an absent extension field MUST be interpreted + identically to an attestation with an unrecognized (and thus ignored) + extension field. +- Extension fields SHOULD follow the [monotonic principle][parsing rules], + meaning that deleting or ignoring the extension SHOULD NOT turn a DENY + decision into an ALLOW. + +## Verification + +[Verification]: verifying-artifacts + +Please see [Verifying Artifacts][Verification] for a detailed discussion of +provenance verification. + +## Index of build types + +The following is a partial index of build type definitions. Each contains a +complete example predicate. + + + +- [GitHub Actions Workflow (community-maintained)](https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1) +- [Google Cloud Build (community-maintained)](https://slsa-framework.github.io/gcb-buildtypes/triggered-build/v1) + +To add an entry here, please send a pull request on GitHub. + +{ The following sections do not belong in this page of the specification: + + - Migrating fron 0.2 + - Change historyigration + + Does this go in the About this Doc - previous versions? } + +## Migrating from 0.2 + +To migrate from [version 0.2](/provenance/v0.2) (`old`), use the following +pseudocode. The meaning of each field is unchanged unless otherwise noted. + +```javascript +{ + "buildDefinition": { + // The `buildType` MUST be updated for v1.0 to describe how to + // interpret `inputArtifacts`. + "buildType": /* updated version of */ old.buildType, + "externalParameters": + old.invocation.parameters + { + // It is RECOMMENDED to rename "entryPoint" to something more + // descriptive. + "entryPoint": old.invocation.configSource.entryPoint, + // It is OPTIONAL to rename "source" to something more descriptive, + // especially if "source" is ambiguous or confusing. + "source": old.invocation.configSource.uri, + }, + "internalParameters": old.invocation.environment, + "resolvedDependencies": + old.materials + [ + { + "uri": old.invocation.configSource.uri, + "digest": old.invocation.configSource.digest, + } + ] + }, + "runDetails": { + "builder": { + "id": old.builder.id, + "builderDependencies": null, // not in v0.2 + "version": null, // not in v0.2 + }, + "metadata": { + "invocationId": old.metadata.buildInvocationId, + "startedOn": old.metadata.buildStartedOn, + "finishedOn": old.metadata.buildFinishedOn, + }, + "byproducts": null, // not in v0.2 + }, +} +``` + +The following fields from v0.2 are no longer present in v1.0: + +- `entryPoint`: Use `externalParameters[]` instead. +- `buildConfig`: No longer inlined into the provenance. Instead, either: + - If the configuration is a top-level input, record its digest in + `externalParameters["config"]`. + - Else if there is a known use case for knowing the exact resolved + build configuration, record its digest in `byproducts`. An example use + case might be someone who wishes to parse the configuration to look for + bad patterns, such as `curl | bash`. + - Else omit it. +- `metadata.completeness`: Now implicit from `builder.id`. +- `metadata.reproducible`: Now implicit from `builder.id`. + +## Change history + +### v1.0 + +Major refactor to reduce misinterpretation, including a minor change in model. + +- Significantly expanded all documentation. +- Altered the model slightly to better align with real-world build platforms, + align with reproducible builds, and make verification easier. +- Grouped fields into `buildDefinition` vs `runDetails`. +- Renamed: + - `parameters` -> `externalParameters` (slight change in semantics) + - `environment` -> `internalParameters` (slight change in semantics) + - `materials` -> `resolvedDependencies` (slight change in semantics) + - `buildInvocationId` -> `invocationId` + - `buildStartedOn` -> `startedOn` + - `buildFinishedOn` -> `finishedOn` +- Removed: + - `configSource`: No longer special-cased. Now represented as + `externalParameters` + `resolvedDependencies`. + - `buildConfig`: No longer inlined into the provenance. Can be replaced + with a reference in `externalParameters` or `byproducts`, depending on + the semantics, or omitted if not needed. + - `completeness` and `reproducible`: Now implied by `builder.id`. +- Added: + - ResourceDescriptor: `annotations`, `content`, `downloadLocation`, + `mediaType`, `name` + - Builder: `builderDependencies` and `version` + - `byproducts` +- Changed naming convention for extension fields. + +Differences from RC1 and RC2: + +- Renamed `systemParameters` (RC1 + RC2) -> `internalParameters` (final). +- Changed naming convention for extension fields (in RC2). +- Renamed `localName` (RC1) -> `name` (RC2). +- Added `annotations` and `content` (in RC2). + +### v0.2 + +Refactored to aid clarity and added `buildConfig`. The model is unchanged. + +- Replaced `definedInMaterial` and `entryPoint` with `configSource`. +- Renamed `recipe` to `invocation`. +- Moved `invocation.type` to top-level `buildType`. +- Renamed `arguments` to `parameters`. +- Added `buildConfig`, which can be used as an alternative to `configSource` + to validate the configuration. + +### rename: slsa.dev/provenance + +Renamed to "slsa.dev/provenance". + +### v0.1.1 + +- Added `metadata.buildInvocationId`. + +### v0.1 + +Initial version, named "in-toto.io/Provenance" + +[Statement]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/statement.md +[in-toto attestation]: https://github.com/in-toto/attestation +[parsing rules]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/README.md#parsing-rules +[purl]: https://github.com/package-url/purl-spec +[threats]: threats +[trusted]: principles#trust-systems-verify-artifacts +, \ No newline at end of file diff --git a/docs/spec/draft/att-general-model.md b/docs/spec/draft/att-general-model.md new file mode 100644 index 000000000..dc7fea346 --- /dev/null +++ b/docs/spec/draft/att-general-model.md @@ -0,0 +1,157 @@ +--- +title: Software attestations +description: A software attestation is an authenticated statement (metadata) about a software artifact or collection of software artifacts. The primary intended use case is to feed into automated policy engines, such as in-toto and Binary Authorization. This page provides a high-level overview of the attestation model, including standardized terminology, data model, layers, and conventions for software attestations. +layout: specifications +--- + +# {Attestation General Model} + +This page provides a high-level overview of the attestation model, including +standardized terminology, data model, layers, conventions for software +attestations, and formats for different use cases. + +## Overview + +A *software attestation*, not to be confused with a [remote attestation] in +the trusted computing world, is an authenticated statement (metadata) about a +software artifact or collection of software artifacts. The primary intended attestation use case is to feed into automated policy engines, such as [in-toto] and [Binary Authorization]. + +Software attestations are a generalization of raw artifact/code signing. With raw signing, a signature is directly over the artifact (or a hash of the +artifact) and *implies* a single bit of metadata about the artifact, based on +the public key. The exact meaning MUST be negotiated between signer and +verifier, and a new keyset MUST be provisioned for each bit of information. For +example, a signature might denote who produced an artifact, or it might denote +fitness for some purpose, or something else entirely. + +When creating attestation, the metadata is *explicit* and the signature only denotes +who created the attestation (authenticity). A single keyset can express an +arbitrary amount of information, including things that are not possible with +raw signing. For example, an attestation might state exactly how an artifact +was produced, including the build command that was run and all of its +dependencies (as in the case of SLSA [Provenance]). + +## Choosing attestation formats + +This section explains how to choose the attestation format that's best suited +for your situation by considering factors such as intended use and who will be +consuming the attestation. + +### First party use case + +Producers of first-party code might consider the following questions: + +- Will SLSA be used only within our organization? +- Is SLSA's primary use case to manage insider risk? +- Are we developing entirely in a closed-source environment? + +If these are the main considerations, the organization can choose any format +for internal use. To make an external claim of meeting a SLSA level, +there needs to be a way for external users to consume and verify your provenance. +Currently, SLSA recommends using the [SLSA Provenance format] for SLSA +attestations since it is easy to verify using the [Generic SLSA Verifier]. + +### Open source use case + +Producers of open-source code might consider these questions: + +- Is SLSA's primary use case to convey trust in how your code was developed? +- Do you develop software with standard open-source licenses? +- Will the code be consumed by others? + +In these situations, we encourage you to use the [SLSA Provenance format]. The SLSA +Provenance format offers a path towards interoperability and cohesion across the open +source ecosystem. Users can verify any provenance statement in this format +using the [Generic SLSA Verifier]. + +### Closed source, third party use cases + +Producers of closed-source code that is consumed by others might consider +the following questions: + +- Is my code produced for the sole purpose of specific third-party consumers? +- Is SLSA's primary use case to create trust in our organization or to comply with +audits and legal requirements? + +In these situations, you might not want to make all the details of your +provenance available externally. Consider using Verification Summary +Attestations (VSAs) to summarize provenance information in a sanitized way +that's safe for external consumption. For more about VSAs, see the [Verification +Summary Attestation] page. + +## Attestation model + +We define the following model to represent any software attestations, regardless +of format. Not all formats will have all fields or all layers, but to be called +a "software attestation" it MUST fit this general model. (The key words MUST, SHOULD, and MAY are to be interpreted as described in [RFC 2119].) + +### Attestation model + +![Attestation model diagram](/images/attestation_layers.svg) + +### Components and terminology + +The following example is an attestation in English with the components of the +attestation mapped to the component terminology names (and colors from the model diagram above): + +![Attestation model to English mapping](/images/attestation_example_english.svg) + +- **Artifact:** Immutable blob of data described by an attestation, usually + identified by cryptographic content hash. Examples: file content, git + commit, container digest. MAY also include a mutable locator, such as + a package name or URI. +- **Attestation:** Authenticated, machine-readable metadata about one or more + software artifacts. An attestation MUST contain at least: + - **Envelope:** Authenticates the message. At a minimum, it MUST contain: + - **Message:** Content (statement) of the attestation. The message + type SHOULD be authenticated and unambiguous to avoid confusion + attacks. + - **Signature:** Denotes the **attester** who created the attestation. + - **Statement:** Binds the attestation to a particular set of artifacts. + This is a separate layer to allow for predicate-agnostic processing + and storage/lookup. MUST contain at least: + - **Subject:** Identifies which artifacts the predicate applies to. + - **Predicate:** Metadata about the subject. The predicate type SHOULD + be explicit to avoid misinterpretation. + - **Predicate:** Arbitrary metadata in a predicate-specific schema. MAY + contain: + - **Link:** *(repeated)* Reference to a related artifact, such as + build dependency. Effectively forms a [hypergraph] where the + nodes are artifacts and the hyperedges are attestations. It is + helpful for the link to be standardized to allow predicate-agnostic + graph processing. +- **Bundle:** A collection of Attestations, which are usually but not + necessarily related. +- **Storage/Lookup:** Convention for where attesters place attestations and + how verifiers find attestations for a given artifact. + +## Recommended suite of formats + +We recommend a single suite of formats and conventions that work well together +and have desirable security properties. Our hope is to align the industry around +this particular suite because it makes everything easier. We +recognize that other choices MAY be necessary in various cases. + +| Component | Recommendation +| --- | --- +| Envelope | **[DSSE]** (ECDSA over NIST P-256 (or stronger) and SHA-256.) +| Statement | **[in-toto attestations]** +| Predicate | Choose as appropriate, i.e.; [Provenance], [SPDX], [other predicates defined by third-parties]. If none are a good fit, invent a new one +| Bundle | **[JSON Lines]**, see [attestation bundle] +| Storage/Lookup | **TBD** + +[attestation bundle]: https://github.com/in-toto/attestation/blob/main/spec/v1/bundle.md +[Binary Authorization]: https://cloud.google.com/binary-authorization +[DSSE]: https://github.com/secure-systems-lab/dsse/ +[Generic SLSA Verifier]: https://github.com/slsa-framework/slsa-verifier +[hypergraph]: https://en.wikipedia.org/wiki/Hypergraph +[in-toto]: https://in-toto.io +[in-toto attestations]: https://github.com/in-toto/attestation/ +[JSON Lines]: https://jsonlines.org/ +[other predicates defined by third-parties]: https://github.com/in-toto/attestation/issues/98 +[Provenance]: /att-build-provenance +[remote attestation]: https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation +[RFC 2119]: https://tools.ietf.org/html/rfc2119 +[SLSA Provenance format]: /att-provenance +[sigstore/cosign]: https://github.com/sigstore/cosign +[SPDX]: https://github.com/in-toto/attestation/blob/main/spec/predicates/spdx.md +[Verification Summary Attestation]: /att-verification-summary diff --git a/docs/spec/draft/att-provenance.md b/docs/spec/draft/att-provenance.md new file mode 100644 index 000000000..0a93c57eb --- /dev/null +++ b/docs/spec/draft/att-provenance.md @@ -0,0 +1,15 @@ +--- +title: Provenance redirection +description: This page is here to redirect you if the *in-toto attestion* predicate type accidentally sent you to this location +--- + +If you landed here via the +[in-toto attestation](https://github.com/in-toto/attestation) predicate type +`https://slsa.dev/provenance/v1` please see +[Attestation formats: Build provenance](att-build-provenance.md). + +**Note:** this page is here to redirect you if the *in-toto attestion* predicate type accidentally sent you to this location. + + + + diff --git a/docs/spec/draft/att-verification_summary.md b/docs/spec/draft/att-verification_summary.md new file mode 100644 index 000000000..0bc16bf2f --- /dev/null +++ b/docs/spec/draft/att-verification_summary.md @@ -0,0 +1,483 @@ +--- +title: Verification Summary Attestation (VSA) +description: Specification for a verification summary of artifacts by a trusted verifier entity. +layout: standard +--- + +# {Verification Summary Attestation (VSA)} + +This page describes the part of the SLSA specification for verification summaries of artifiacts (VSA) by a trusted verifier entity. It includes three [VSA examples](examples) and a [verified properties](verified-properties) section for what to do when security levels may not be appropriate. + +## Overview + +Verification summary attestations communicate that an artifact has been verified +at a specific SLSA level and provides details about that verification. + +This page used the following predicate type within the [in-toto +attestation] framework: + +```json +"predicateType": "https://slsa.dev/verification_summary/v1" +``` + +> **Note:** Always use the above string for `predicateType` rather than what is +> in the URL bar. The `predicateType` URI will always resolve to the latest +> minor version of this specification. See [parsing rules](#parsing-rules) for +> more information. + +## Purpose of verification + +Verification describes what SLSA level an artifact or set of artifacts was verified at +and other details about the verification process including what SLSA level +the dependencies were verified at. + +This allows software consumers to make a decision about the validity of an +artifact without needing to have access to all of the attestations about the +artifact or all of its transitive dependencies. They can use it to delegate +complex policy decisions to some trusted party and then simply trust that +party's decision regarding the artifact. + +It also allows software producers to keep the details of their build pipeline +confidential while still communicating that some verification has taken place. +This might be necessary for legal reasons (keeping a software supplier +confidential) or for security reasons (not revealing that an embargoed patch has +been included). + +## Attestation verificatiion model + +A Verification Summary Attestation (VSA) is an attestation that some entity +(`verifier`) verified one or more software artifacts (the `subject` of an +in-toto attestation [Statement]) by evaluating the artifact and a `bundle` +of attestations against some `policy`. Users who trust the `verifier` may +assume that the artifacts met the indicated SLSA level without themselves +needing to evaluate the artifact or to have access to the attestations the +`verifier` used to make its determination. + +The VSA also allows consumers to determine the verified levels of +all of an artifact’s _transitive_ dependencies. The verifier does this by +either a) verifying the provenance of each non-source dependency listed in +the [resolvedDependencies](/build-provenance/v1#resolvedDependencies) of the +artifact being verified (recursively) or b) matching the non-source dependency +listed in `resolvedDependencies` (`subject.digest` == +`resolvedDependencies.digest` and, ideally, `vsa.resourceUri` == +`resolvedDependencies.uri`) to a VSA _for that dependency_ and using +`vsa.verifiedLevels` and `vsa.dependencyLevels`. Policy verifiers wishing +to establish minimum requirements on dependencies SLSA levels may use +`vsa.dependencyLevels` to do so. + +## Verification schema definitions + +This schema defines the fields of the VSA. + +```jsonc +// Standard attestation fields: +"_type": "https://in-toto.io/Statement/v1", +"subject": [{ + "name": , + "digest": { } +}], + +// Predicate +"predicateType": "https://slsa.dev/verification_summary/v1", +"predicate": { + "verifier": { + "id": "", + "version": { + "": "", + ... + } + }, + "timeVerified": , + "resourceUri": , + "policy": { + "uri": "", + "digest": { } + } + "inputAttestations": [ + { + "uri": "", + "digest": { } + }, + ... + ], + "verificationResult": "", + "verifiedLevels": [""], + "dependencyLevels": { + "": , + "": , + ... + }, + "slsaVersion": ".", +} +``` + +### VSA parsing best practices + +The predicate used in this page follows the in-toto attestation [parsing rules]. + +- Consumers MUST ignore unrecognized fields. +- The `predicateType` URI includes the major version number and will always + change whenever there is a backwards incompatible change. +- Minor version changes are always backwards compatible and "monotonic." Such + changes do not update the `predicateType`. +- Producers MAY add extension fields using field names that are URIs. + +### Schema fields + +_NOTE: This section describes the fields within `predicate`. For a description +of the other top-level fields, such as `subject`, see [Statement]._ + + +`verifier` _object, required_ + +> Identifies the entity that performed the verification. +> +> The identity MUST reflect the trust base that consumers care about. How +> detailed to be is a judgment call. +> +> Consumers MUST accept only specific (signer, verifier) pairs. For example, +> "GitHub" can sign provenance for the "GitHub Actions" verifier, and "Google" +> can sign provenance for the "Google Cloud Deploy" verifier, but "GitHub" cannot +> sign for the "Google Cloud Deploy" verifier. +> +> The field is required, even if it is implicit from the signer, to aid readability and +> debugging. It is an object to allow additional fields in the future, in case one +> URI is not sufficient. + + +`verifier.id` _string ([TypeURI]), required_ + +> URI indicating the verifier’s identity. + + +`verifier.version` _map (string->string), optional_ + +> Map of names of components of the verification platform to their version. + + +`timeVerified` _string ([Timestamp]), optional_ + +> Timestamp indicating what time the verification occurred. + + +`resourceUri` _string ([ResourceURI]), required_ + +> URI that identifies the resource associated with the artifact being verified. +> +> The `resourceUri` SHOULD be set to the URI from which the producer expects the +> consumer to fetch the artifact for verification. This enables the consumer to +> easily determine the expected value when [verifying](#how-to-verify). If the +> `resourceUri` is set to some other value, the producer MUST communicate the +> expected value, or how to determine the expected value, to consumers through +> an out-of-band channel. + + +`policy` _object ([ResourceDescriptor]), required_ + +> Describes the policy that the `subject` was verified against. +> +> The entry MUST contain a `uri` identifying which policy was applied and +> SHOULD contain a `digest` to indicate the exact version of that policy. + + +`inputAttestations` _array ([ResourceDescriptor]), optional_ + +> The collection of attestations that were used to perform verification. +> Conceptually similar to the `resolvedDependencies` field in [SLSA Provenance]. +> +> This field MAY be absent if the verifier does not support this feature. +> If non-empty, this field MUST contain information on _all_ the attestations +> used to perform verification. +> +> Each entry MUST contain a `digest` of the attestation and SHOULD contains a +> `uri` that can be used to fetch the attestation. + + +`verificationResult` _string, required_ + +> Either “PASSED” or “FAILED” to indicate if the artifact passed or failed the policy verification. + + +`verifiedLevels` _array ([SlsaResult]), required_ + +> Indicates the highest level of each track verified for the artifact (and not +> its dependencies) and any [verified properties](verified-properties) verified +> for the artifact or "FAILED" if policy verification failed. +> +> Users MUST NOT include more than one level per SLSA track. Note that each SLSA +> level implies all levels below it (e.g. `SLSA_BUILD_LEVEL_3` implies +> `SLSA_BUILD_LEVEL_2` and `SLSA_BUILD_LEVEL_1`), so there is no need to +> include more than one level per track. + + +`dependencyLevels` _object, optional_ + +> A count of the dependencies at each SLSA level. +> +> Map from [SlsaResult] to the number of the artifact's _transitive_ dependencies +> that were verified at the indicated level. Absence of a given level of +> [SlsaResult] MUST be interpreted as reporting _0_ dependencies at that level. +> A set but empty `dependencyLevels` object means that the artifact has **no** +> dependency at all, while an unset or null `dependencyLevels` means that the +> verifier makes no claims about the artifact's dependencies. +> +> Users MUST count each dependency only once per SLSA track, at the highest +> level verified. For example, if a dependency meets `SLSA_BUILD_LEVEL_2`, +> you include it with the count for `SLSA_BUILD_LEVEL_2` but not the count for +> `SLSA_BUILD_LEVEL_1`. + + +`slsaVersion` _string, optional_ + +> Indicates the version of the SLSA specification that the verifier used, in the +> form `.`. Example: `1.0`. If unset, the default is an +> unspecified minor version of `1.x`. + +## VSA example + +This is a complete example of a verification summary attestation. + +WARNING: This is just for demonstration purposes. + +```jsonc +"_type": "https://in-toto.io/Statement/v1", +"subject": [{ + "name": "out/example-1.2.3.tar.gz", + "digest": {"sha256": "5678..."} +}], + +// Predicate +"predicateType": "https://slsa.dev/verification_summary/v1", +"predicate": { + "verifier": { + "id": "https://example.com/publication_verifier", + "version": { + "slsa-verifier-linux-amd64": "v2.3.0", + "slsa-framework/slsa-verifier/actions/installer": "v2.3.0" + } + }, + "timeVerified": "1985-04-12T23:20:50.52Z", + "resourceUri": "https://example.com/example-1.2.3.tar.gz", + "policy": { + "uri": "https://example.com/example_tarball.policy", + "digest": {"sha256": "1234..."} + }, + "inputAttestations": [ + { + "uri": "https://example.com/provenances/example-1.2.3.tar.gz.intoto.jsonl", + "digest": {"sha256": "abcd..."} + } + ], + "verificationResult": "PASSED", + "verifiedLevels": ["SLSA_BUILD_LEVEL_3"], + "dependencyLevels": { + "SLSA_BUILD_LEVEL_3": 5, + "SLSA_BUILD_LEVEL_2": 7, + "SLSA_BUILD_LEVEL_1": 1, + }, + "slsaVersion": "1.0" +} +``` +## How to verify attestations + +VSA consumers use VSAs to accomplish goals based on delegated trust. We call the +process of establishing a VSA's authenticity and determining whether it meets +the consumer's goals 'verification'. Goals differ, as do levels of confidence +in VSA producers, so the verification procedure changes to suit its context. +However, there are certain steps that most verification procedures have in +common. + +**Verification MUST include the following steps:** + +1. Verify the signature on the VSA envelope using the preconfigured roots of + trust. This step ensures that the VSA was produced by a trusted producer + and that it hasn't been tampered with. + +2. Verify the statement's `subject` matches the digest of the artifact in + question. This step ensures that the VSA pertains to the intended artifact. + +3. Verify that the `predicateType` is + `https://slsa.dev/verification_summary/v1`. This step ensures that the + in-toto predicate is using this version of the VSA format. + +4. Verify that the `verifier` matches the public key (or equivalent) used to + verify the signature in step 1. This step identifies the VSA producer in + cases where their identity is not implicitly revealed in step 1. + +5. Verify that the value for `resourceUri` in the VSA matches the expected + value. This step ensures that the consumer is using the VSA for the + producer's intended purpose. + +6. Verify that the value for `verificationResult` is `PASSED`. This step + ensures the artifact is suitable for the consumer's purposes. + +7. Verify that `verifiedLevels` contains the expected value. This step ensures + that the artifact is suitable for the consumer's purposes. + +Verification MAY additionally contain the following step: + +1. (Optional) Verify additional fields required to determine whether the VSA + meets your goal. + +Verification mitigates different threats depending on the VSA's contents and the +verification procedure. + +IMPORTANT: A VSA does not protect against compromise of the verifier, such as by +a malicious insider. Instead, VSA consumers SHOULD carefully consider which +verifiers they add to their roots of trust. + +### Additiional examples + +These examples outline the criteria for code signing and security enforcement. + +1. Suppose consumer C wants to delegate to verifier V the decision for whether + to accept artifact A as resource R. Consumer C verifies that: + + - The signature on the VSA envelope using V's public signing key from their + preconfigured root of trust. + + - `subject` is A. + + - `predicateType` is `https://slsa.dev/verification_summary/v1`. + + - `verifier.id` is V. + + - `resourceUri` is R. + + - `slsaResult` is `PASSED`. + + - `verifiedLevels` contains `SLSA_BUILD_LEVEL_UNEVALUATED`. + + **Note:** This example is analogous to traditional code signing. The expected + value for `verifiedLevels` is arbitrary but prenegotiated by the producer and + the consumer. The consumer does not need to check additional fields, as C + fully delegates the decision to V. + +2. Suppose consumer C wants to enforce the rule "Artifact A at resource R must + have a passing VSA from verifier V showing it meets SLSA Build Level 2+." + Consumer C verifies that: + + - The signature on the VSA envelope using V's public signing key from their + preconfigured root of trust. + + - `subject` is A. + + - `predicateType` is `https://slsa.dev/verification_summary/v1`. + + - `verifier.id` is V. + + - `resourceUri` is R. + + - `slsaResult` is `PASSED`. + + - `verifiedLevels` is `SLSA_BUILD_LEVEL_2` or `SLSA_BUILD_LEVEL_3`. + + **Note:** In this example, verifying the VSA mitigates the same threats as + verifying the artifact's SLSA provenance. See + [Verifying artifacts](/spec/v1.0/verifying-artifacts) for details about which + threats are addressed by verifying each SLSA level. + +
+ +## VSA String Result (_SlsaResult (String)_) + +
+ +The result of evaluating an artifact (or set of artifacts) against SLSA +SHOULD be: + +- The [SLSA Track](#tracks) level the referenced artifact qualifies for as +`SLSA__LEVEL_`, or +- `SLSA__LEVEL_UNEVALUATED` if the VSA issuer does not want to + make a claim about the track level an artifact meets, or +- The SLSA [verified property](verified-properties) the referenced artifact + qualifies for. + +For example: + +- `SLSA_BUILD_LEVEL_UNEVALUATED` +- `SLSA_BUILD_LEVEL_0` +- `SLSA_BUILD_LEVEL_3` +- `SLSA_SOURCE_LEVEL_2` +- `SLSA_SOURCE_LEVEL_4` +- `FAILED` (Indicates policy evaluation failed) + + +> **Note:** Each SLSA level implies the levels below it in the same track. +For example, `SLSA_BUILD_LEVEL_3` means (`SLSA_BUILD_LEVEL_1` + +`SLSA_BUILD_LEVEL_2` + `SLSA_BUILD_LEVEL_3`). + +> Users MAY use custom values here but MUST NOT use custom values starting with +`SLSA_`. + +## Verified properties + + + +While SLSA is typically focused on expressing the security state of an artifact +with [levels](principles#simple-levels-with-clear-outcomes), levels may not be +appropriate in all cases. Some software supply chain controls don't fit neatly +within existing SLSA levels or that do may exist with others that users are not +yet able to meet. SLSA Verified Properties allows a common way to express those +properties (and their requirements) without needing to fit them into existing +levels or introduce new tracks. + +These properties MAY be included in the `verifiedLevels` field of +[Verification Summary Attestations (VSA)](att-verification_summary) when the VSA issuer +determines the requirements have been met. + +Insert these two properties into the `verifiedLevels` field of the VSA. + +### SLSA_SOURCE_TWO_PARTY_REVIEWED + +Indicates the source code associated with this artifact has been reviewed by +two trusted persons. This property MUST only be issued in accordance with the +[Source Track](source-requirements)'s +[two-party-review](source-requirements#two-party-review) requirements. + +This property MAY be added at any source level in which an SCS can make this +claim. + +### SLSA_BUILD_REPRODUCED + +Indicates the referenced artifact has been reproduced by two or more builders. + +This property MUST only be issued if the referenced artifact has +[build provenance](build-provenance) from two or more independently +operated [Build Platforms](build-requirements#build-platform) which are +trusted by the VSA issuer. + +{ The following section does not belong in this page of the specification. Should this go in the About this Doc - previous versions?} + +## Change history + +- 1.2: + - Update SlsaResult definition to discuss how to refer to new tracks and + link to [verified properties](verified-properties) for additional SLSA + endorsed values. +- 1.1: + - Changed the `policy` object to recommend that the `digest` field of + the `ResourceDescriptor` is set. + - Added optional `verifier.version` field to record verification tools. + - Added Verification section with examples. + - Made `timeVerified` optional. +- 1.0: + - Replaced `materials` with `resolvedDependencies`. + - Relaxed `SlsaResult` to allow other values. + - Converted to lowerCamelCase for consistency with [SLSA Provenance]. + - Added `slsaVersion` field. +- 0.2: + - Added `resource_uri` field. + - Added optional `input_attestations` field. +- 0.1: Initial version. + +[SLSA Provenance]: /provenance +[SlsaResult]: #slsaresult +[DigestSet]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/digest_set.md +[ResourceURI]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/field_types.md#resourceuri +[ResourceDescriptor]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/resource_descriptor.md +[Statement]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/statement.md +[Timestamp]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/field_types.md#timestamp +[TypeURI]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/field_types.md#TypeURI +[in-toto attestation]: https://github.com/in-toto/attestation +[parsing rules]: https://github.com/in-toto/attestation/blob/7aefca35a0f74a6e0cb397a8c4a76558f54de571/spec/v1/README.md#parsing-rules diff --git a/docs/spec/draft/images/attestation_example_english.svg b/docs/spec/draft/images/attestation_example_english.svg new file mode 100644 index 000000000..3d81225a5 --- /dev/null +++ b/docs/spec/draft/images/attestation_example_english.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/spec/draft/images/attestation_layers.svg b/docs/spec/draft/images/attestation_layers.svg new file mode 100644 index 000000000..7bb50d0c7 --- /dev/null +++ b/docs/spec/draft/images/attestation_layers.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/spec/draft/real-world-examples.md b/docs/spec/draft/real-world-examples.md new file mode 100644 index 000000000..0771f468a --- /dev/null +++ b/docs/spec/draft/real-world-examples.md @@ -0,0 +1,207 @@ +## Mapping to real-world ecosystems + +Most real-world ecosystems fit the package model above but use different terms. +The table below attempts to document how various ecosystems map to the SLSA +Package model. There are likely mistakes and omissions; corrections and +additions are welcome! + + + + + + + + + + + + + + + + + + + + + + + + + + +
Package ecosystem + Package registry + Package name + Package artifact +
Languages +
Cargo (Rust) + Registry + Crate name + Artifact +
CPAN (Perl) + PAUSE + Distribution + Release (or Distribution) +
Go + Module proxy + Module path + Module +
Maven (Java) + Repository + Group ID + Artifact ID + Artifact +
npm (JavaScript) + Registry + Package Name + Package +
NuGet (C#) + Host + Project + Package +
PyPA (Python) + Index + Project Name + Distribution +
Operating systems +
Dpkg (e.g. Debian) + ? + Package name + Package +
Flatpak + Repository + Application + Bundle +
Homebrew (e.g. Mac) + Repository (Tap) + Package name (Formula) + Binary package (Bottle) +
Pacman (e.g. Arch) + Repository + Package name + Package +
RPM (e.g. Red Hat) + Repository + Package name + Package +
Nix (e.g. NixOS) + Repository (e.g. Nixpkgs) or binary cache + Derivation name + Derivation or store object +
Storage systems +
GCS + n/a + Object name + Object +
OCI/Docker + Registry + Repository + Object +
Meta +
deps.dev: System + Packaging authority + Package + n/a +
purl: type + Namespace + Name + n/a +
+ +Notes: + +- [Go](https://go.dev) (golang) uses a significantly different distribution model than other ecosystems. + In Go, the package name is a source repository URL. While clients can fetch + directly from that URL---in which case there is no "package" or + "registry"---they usually fetch a zip file from a *module proxy*. The module + proxy acts as both a builder (by constructing the package artifact from + source) and a registry (by mapping package name to package artifact). People + trust the module proxy because builds are independently reproducible, and a + *checksum database* guarantees that all clients receive the same artifact + for a given URL. + +### Real-world supply chain examples + +Many recent high-profile attacks were consequences of supply chain integrity vulnerabilities, and could have been prevented by SLSA's framework. For example: + + + + + + + + + + + + + + + +
+Threats from +Known example +How SLSA could help +
A +Producer +SpySheriff: Software producer purports to offer anti-spyware software, but that software is actually malicious. +SLSA does not directly address this threat but could make it easier to discover malicious behavior in open source software, by forcing it into the publicly available source code. +For closed source software SLSA does not provide any solutions for malicious producers. +
B +Authoring & reviewing +SushiSwap: Contractor with repository access pushed a malicious commit redirecting cryptocurrency to themself. +Two-person review could have caught the unauthorized change. +
C +Source code management +PHP: Attacker compromised PHP's self-hosted git server and injected two malicious commits. +A better-protected source code system would have been a much harder target for the attackers. +
D +External build parameters +The Great Suspender: Attacker published software that was not built from the purported sources. +A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering. +
E +Build process +SolarWinds: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build. +Higher SLSA Build levels have stronger security requirements for the build platform, making it more difficult for an attacker to forge the SLSA provenance and gain persistence. +
F +Artifact publication +CodeCov: Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly. +Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo. +
G +Distribution channel +Attacks on Package Mirrors: Researcher ran mirrors for several popular package registries, which could have been used to serve malicious packages. +Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo. +
H +Package selection +Browserify typosquatting: Attacker uploaded a malicious package with a similar name as the original. +SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions. +
I +Usage +Default credentials: Attacker could leverage default credentials to access sensitive data. +SLSA does not address this threat. +
N/A +Dependency threats (i.e. A-H, recursively) +event-stream: Attacker controls an innocuous dependency and publishes a malicious binary version without a corresponding update to the source code. +Applying SLSA recursively to all dependencies would prevent this particular vector, because the provenance would indicate that it either wasn't built from a proper builder or that the binary did not match the source. +
+ + + + + + +
+Availability threat +Known example +How SLSA could help +
N/A +Dependency becomes unavailable +Mimemagic: Producer intentionally removes package or version of package from repository with no warning. Network errors or service outages may also make packages unavailable temporarily. +SLSA does not directly address this threat. +
+ +A SLSA level helps give consumers confidence that software has not been tampered +with and can be securely traced back to source—something that is difficult, if +not impossible, to do with most software today. + + \ No newline at end of file