You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| Artifact | An immutable blob of data; primarily refers to software, but SLSA can be used for any artifact. | A file, a git commit, a directory of files (serialized in some way), a container image, a firmware image.
45
-
| Attestation | An authenticated statement (metadata) about a software artifact or collection of software artifacts. | A signed [SLSA Provenance] file.
46
-
| Source | Artifact that was directly authored or reviewed by persons, without modification. It is the beginning of the supply chain; we do not trace the provenance back any further. | Git commit (source) hosted on GitHub (platform).
47
-
| [Build] | Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs. | .travis.yml (process) run by Travis CI (platform).
48
-
| [Package] | Artifact that is "published" for use by others. In the model, it is always the output of a build process, though that build process can be a no-op. | Docker image (package) distributed on DockerHub (platform). A ZIP file containing source code is a package, not a source, because it is built from some other source, such as a git commit.
49
-
| Dependency | Artifact that is an input to a build process but that is not a source. In the model, it is always a package. | Alpine package (package) distributed on Alpine Linux (platform).
50
-
51
-
[build]: #build-model
52
-
[package]: #package-model
53
-
[SLSA Provenance]: /provenance/v1
54
-
55
-
### Roles
56
-
57
-
Throughout the specification, you will see reference to the following roles
58
-
that take part in the software supply chain. Note that in practice a role may
59
-
be filled by more than one person or an organization. Similarly, a person or
60
-
organization may act as more than one role in a particular software supply
61
-
chain.
62
-
63
-
| Role | Description | Examples
64
-
| --- | --- | ---
65
-
| Producer | A party who creates software and provides it to others. Producers are often also consumers. | An open source project's maintainers. A software vendor.
66
-
| Verifier | A party who inspect an artifact's provenance to determine the artifact's authenticity. | A business's software ingestion system. A programming language ecosystem's package registry.
67
-
| Consumer | A party who uses software provided by a producer. The consumer may verify provenance for software they consume or delegate that responsibility to a separate verifier. | A developer who uses open source software distributions. A business that uses a point of sale system.
68
-
| Infrastructure provider | A party who provides software or services to other roles. | A package registry's maintainers. A build platform's maintainers.
@@ -177,176 +138,6 @@ A typical build environment will go through the following lifecycle:
177
138
4.*Build execution*: Finally, the build agent within the environment executes
178
139
the tenant's build definition.
179
140
180
-
### Package model
181
-
182
-
Software is distributed in identifiable units called <dfn>packages</dfn>
183
-
according to the rules and conventions of a <dfn>package ecosystem</dfn>.
184
-
Examples of formal ecosystems include [Python/PyPA](https://www.pypa.io),
185
-
[Debian/Apt](https://wiki.debian.org/DebianRepository/Format), and
186
-
[OCI](https://github.com/opencontainers/distribution-spec), while examples of
187
-
informal ecosystems include links to files on a website or distribution of
188
-
first-party software within a company.
189
-
190
-
Abstractly, a consumer locates software within an ecosystem by asking a
191
-
<dfn>package registry</dfn> to resolve a mutable <dfn>package name</dfn> into an
192
-
immutable <dfn>package artifact</dfn>.[^label] To <dfn>publish</dfn> a package
193
-
artifact, the software producer asks the registry to update this mapping to
194
-
resolve to the new artifact. The registry represents the entity or entities with
195
-
the power to alter what artifacts are accepted by consumers for a given package
196
-
name. For example, if consumers only accept packages signed by a particular
197
-
public key, then it is access to that public key that serves as the registry.
198
-
199
-
The package name is the primary security boundary within a package ecosystem.
200
-
Different package names represent materially different pieces of
201
-
software---different owners, behaviors, security properties, and so on.
202
-
Therefore, **the package name is the primary unit being protected in SLSA**.
203
-
It is the primary identifier to which consumers attach expectations.
204
-
205
-
[^label]: This resolution might include a version number, label, or some other
206
-
selector in addition to the package name, but that is not important to SLSA.
207
-
208
-
| Term | Description
209
-
| ---- | -----------
210
-
| Package | An identifiable unit of software intended for distribution, ambiguously meaning either an "artifact" or a "package name". Only use this term when the ambiguity is acceptable or desirable.
211
-
| Package artifact | A file or other immutable object that is intended for distribution.
212
-
| Package ecosystem | A set of rules and conventions governing how packages are distributed, including how clients resolve a package name into one or more specific artifacts.
213
-
| Package manager client | Client-side tooling to interact with a package ecosystem.
214
-
| Package name | <p>The primary identifier for a mutable collection of artifacts that all represent different versions of the same software. This is the primary identifier that consumers use to obtain the software.<p>A package name is specific to an ecosystem + registry, has a maintainer, is more general than a specific hash or version, and has a "correct" source location. A package ecosystem may group package names into some sort of hierarchy, such as the Group ID in Maven, though SLSA does not have a special term for this.
215
-
| Package registry | An entity responsible for mapping package names to artifacts within a packaging ecosystem. Most ecosystems support multiple registries, usually a single global registry and multiple private registries.
216
-
| Publish [a package] | Make an artifact available for use by registering it with the package registry. In technical terms, this means associating an artifact to a package name. This does not necessarily mean making the artifact fully public; an artifact may be published for only a subset of users, such as internal testing or a closed beta.
217
-
218
-
<details><summary>Ambiguous terms to avoid</summary>
219
-
220
-
-*Package repository:* Could mean either package registry or package name,
221
-
depending on the ecosystem. To avoid confusion, we always use "repository"
222
-
exclusively to mean "source repository", where there is no ambiguity.
223
-
-*Package manager* (without "client"): Could mean either package ecosystem,
224
-
package registry, or client-side tooling.
225
-
226
-
</details>
227
-
228
-
### Mapping to real-world ecosystems
229
-
230
-
Most real-world ecosystems fit the package model above but use different terms.
231
-
The table below attempts to document how various ecosystems map to the SLSA
232
-
Package model. There are likely mistakes and omissions; corrections and
233
-
additions are welcome!
234
-
235
-
<!-- Please keep this list sorted alphabetically within each section. -->
0 commit comments