CINXE.COM

<!DOCTYPE html> <html lang="en"><head> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="generator" content="Jekyll v3.9.5" /> <meta property="og:title" content="Terminology" /> <meta property="og:locale" content="en_US" /> <meta name="description" content="Before diving into the SLSA specification levels, we need to establish a core set of terminology and models to describe what we’re protecting." /> <meta property="og:description" content="Before diving into the SLSA specification levels, we need to establish a core set of terminology and models to describe what we’re protecting." /> <meta property="og:site_name" content="SLSA" /> <meta property="og:image" content="/images/icons/android-chrome-192x192.png" /> <meta property="og:type" content="website" /> <meta name="twitter:card" content="summary_large_image" /> <meta property="twitter:image" content="/images/icons/android-chrome-192x192.png" /> <meta property="twitter:title" content="Terminology" /> <script type="application/ld+json"> {"@context":"https://schema.org","@type":"WebPage","description":"Before diving into the SLSA specification levels, we need to establish a core set of terminology and models to describe what we’re protecting.","headline":"Terminology","image":"/images/icons/android-chrome-192x192.png","publisher":{"@type":"Organization","logo":{"@type":"ImageObject","url":"/images/icons/android-chrome-512x512.png"}},"url":"/spec/v1.0/terminology"}</script>  <link rel="stylesheet" href="/vendor/tailwindcss-2.2.19/tailwind.min.css"> <link rel="stylesheet" href="/assets/main.css"> <link rel="apple-touch-icon" sizes="180x180" href="/images/icons/apple-touch-icon.png"> <link rel="icon" type="image/png" sizes="32x32" href="/images/icons/favicon-32x32.png"> <link rel="icon" type="image/png" sizes="16x16" href="/images/icons/favicon-16x16.png"> <link rel="icon" type="image/png" sizes="16x16" href="/images/icons/favicon-16x16.png"> <link rel="icon" type="image/x-icon" href="/images/icons/favicon.ico"> <link rel="mask-icon" href="/images/icons/safari-pinned-tab.svg" color="#5bbad5"> <meta name="msapplication-TileColor" content="#da532c" /> <meta name="msapplication-square150x150logo" content="/images/icons/mstile-150x150.png" /> <meta name="theme-color" content="#ffffff" /> <title>SLSA • Terminology</title> <link rel="stylesheet" href="/fonts/inter/inter.css"> <link rel="stylesheet" href="/fonts/ibm_plex/IBMPlexMono-Regular.css"> <link rel="stylesheet" href="/fonts/prodigy/ProdigySans.css"> <script src="/vendor/swiper-6.8.4/swiper-bundle.min.js"></script> <link rel="stylesheet" href="/vendor/swiper-6.8.4/swiper-bundle.min.css"> <script defer src="/vendor/alpinejs-3.10.2/cdn.min.js"></script><link type="application/atom+xml" rel="alternate" href="/feed.xml" title="SLSA" /></head> <body x-data="{navOpen: false}" x-init="$refs.body.style.setProperty('--scrollbar-width', `${window.innerWidth - document.body.offsetWidth}px`)" x-ref="body" ><aside class="site-aside flex flex-col flex-none" :class="{'is-open': navOpen}" > <div class="aside-header p-5 flex justify-between items-center show-laptop"> <a rel="author" href="/" class="logo block"> <img class="logo-white" src="/images/logo.svg" alt="SLSA logo" /> </a> <a class="desktop-github-icon" href="https://github.com/slsa-framework/slsa" target="_blank"> <svg width="22" height="22" viewBox="0 0 22 22" fill="currentColor" xmlns="http://www.w3.org/2000/svg"> <path fill-rule="evenodd" clip-rule="evenodd" d="M11.2344 0.150879C5.28641 0.150879 0.468811 4.96848 0.468811 10.9165C0.468811 15.6803 3.55046 19.7039 7.82978 21.1303C8.36806 21.2245 8.56991 20.9016 8.56991 20.619C8.56991 20.3633 8.55646 19.5155 8.55646 18.6139C5.8516 19.1118 5.15184 17.9545 4.93653 17.3489C4.81541 17.0394 4.29059 16.084 3.83306 15.8283C3.45626 15.6264 2.91798 15.1285 3.8196 15.1151C4.66739 15.1016 5.27295 15.8956 5.47481 16.2185C6.44371 17.8468 7.99126 17.3893 8.61028 17.1067C8.70448 16.4069 8.98708 15.9359 9.29659 15.6668C6.90125 15.3977 4.39825 14.4691 4.39825 10.3513C4.39825 9.18051 4.81541 8.21161 5.50172 7.45802C5.39407 7.18888 5.01727 6.08541 5.60938 4.60514C5.60938 4.60514 6.51099 4.32254 8.56991 5.70861C9.43116 5.46639 10.3462 5.34527 11.2613 5.34527C12.1764 5.34527 13.0914 5.46639 13.9527 5.70861C16.0116 4.30909 16.9132 4.60514 16.9132 4.60514C17.5053 6.08541 17.1285 7.18888 17.0209 7.45802C17.7072 8.21161 18.1244 9.16706 18.1244 10.3513C18.1244 14.4826 15.6079 15.3977 13.2126 15.6668C13.6028 16.0032 13.9392 16.6492 13.9392 17.6584C13.9392 19.0983 13.9258 20.2556 13.9258 20.619C13.9258 20.9016 14.1276 21.238 14.6659 21.1303C16.8031 20.4088 18.6602 19.0353 19.9758 17.2031C21.2915 15.3708 21.9994 13.1721 22 10.9165C22 4.96848 17.1824 0.150879 11.2344 0.150879Z" /> </svg> </a> </div> <div class="aside-content px-5 py-1 flex-1 overflow-auto"> <select id="redirectSelect.show-laptop" class="select-dropdown p-1 mx-1 my-4 text-black opacity-80 show-laptop border-gray-400"> <option value="/spec/v1.1/terminology" class="inline-block">Version 1.1 RC</option> <option selected value="/spec/v1.0/terminology" class="inline-block">Version 1.0</option> <option value="/spec/v0.1/terminology" class="inline-block">Version 0.1</option> <option value="/spec/draft/terminology" class="inline-block">Working Draft</option> </select> <script> var selectEl = document.getElementById('redirectSelect.show-laptop'); selectEl.onchange = function(){ var goto = this.value; window.location = goto; }; </script> <nav class="site-nav"><ul><li> <a class="nav-link" href="/spec/v1.0/"> Overview </a> </li><li> <span class="section-title">Understanding SLSA</span> <ul><li> <a class="nav-link" href="/spec/v1.0/whats-new"> What's new in v1.0 </a> </li><li> <a class="nav-link" href="/spec/v1.0/about"> About SLSA </a> </li><li> <a class="nav-link" href="/spec/v1.0/threats-overview"> Supply chain threats </a> </li><li> <a class="nav-link" href="/spec/v1.0/use-cases"> Use cases </a> </li><li> <a class="nav-link" href="/spec/v1.0/principles"> Guiding principles </a> </li><li> <a class="nav-link" href="/spec/v1.0/faq"> FAQ </a> </li><li> <a class="nav-link" href="/spec/v1.0/future-directions"> Future directions </a> </li> </ul> </li><li> <span class="section-title">Core specification</span> <ul><li> <a class="nav-link is-active" href="/spec/v1.0/terminology"> Terminology </a> </li><li> <a class="nav-link" href="/spec/v1.0/levels"> Security levels </a> </li><li> <a class="nav-link" href="/spec/v1.0/requirements"> Producing artifacts </a> </li><li> <a class="nav-link" href="/spec/v1.0/distributing-provenance"> Distributing provenance </a> </li><li> <a class="nav-link" href="/spec/v1.0/verifying-artifacts"> Verifying artifacts </a> </li><li> <a class="nav-link" href="/spec/v1.0/verifying-systems"> Verifying build platforms </a> </li><li> <a class="nav-link" href="/spec/v1.0/threats"> Threats & mitigations </a> </li> </ul> </li><li> <span class="section-title">Attestation formats</span> <ul><li> <a class="nav-link" href="/attestation-model"> General model </a> </li><li> <a class="nav-link" href="/spec/v1.0/provenance"> Provenance </a> </li><li> <a class="nav-link" href="/spec/v1.0/verification_summary"> Verification Summary </a> </li> </ul> </li><li> <span class="section-title">How to SLSA</span> <ul><li> <a class="nav-link" href="/get-started"> For developers </a> </li><li> <a class="nav-link" href="/how-to-orgs"> For organizations </a> </li><li> <a class="nav-link" href="/how-to-infra"> For infrastructure providers </a> </li> </ul> </li><li> <a class="nav-link" href="/spec-stages"> Specification stages </a> </li><li> <a class="nav-link" href="/community"> Community </a> </li><li> <a class="nav-link" href="/blog"> Blog </a> </li><li> <a class="nav-link" href="/spec/v1.0/onepage"> Single-page view </a> </li> </ul> </nav> </div> </aside> <div class="site-main"> <header class="site-header flex-none" x-data="{ fixed: false, hidden: false, lastPos: window.scrollY, scrolledPast: false }" x-ref="navbar" x-on:scroll.window=" fixed = window.scrollY > lastPos ? window.scrollY >= $refs.navbar.offsetHeight : window.scrollY > 0; hidden = fixed && window.scrollY > lastPos; if (window.scrollY > $refs.navbar.offsetHeight && !scrolledPast) { setTimeout(() => $refs.navbar.classList.add('is-scrolled-past'), 500); scrolledPast = true; } else if (window.scrollY === 0) { $refs.navbar.classList.remove('is-scrolled-past'); scrolledPast = false; } lastPos = window.scrollY; " x-bind:class="{ 'is-fixed': fixed, 'is-hidden': hidden, 'menu-open': navOpen }" > <div class="site-header-inner h-full flex items-center gap-5" > <button x-on:click="navOpen = !navOpen" :class="{ 'active': navOpen }" class="mobile-menu-button inline-block hide-laptop"> <span></span> <span></span> <span></span> </button> <a rel="author" href="/" class="logo block"> <img class="logo-white" src="/images/logo.svg" alt="SLSA logo" /> </a> <select id="redirectSelect.hide-laptop" class="select-dropdown p-1 mx-1 my-4 text-black opacity-80 hide-laptop border-gray-400"> <option value="/spec/v1.1/terminology" class="inline-block">Version 1.1 RC</option> <option selected value="/spec/v1.0/terminology" class="inline-block">Version 1.0</option> <option value="/spec/v0.1/terminology" class="inline-block">Version 0.1</option> <option value="/spec/draft/terminology" class="inline-block">Working Draft</option> </select> <script> var selectEl = document.getElementById('redirectSelect.hide-laptop'); selectEl.onchange = function(){ var goto = this.value; window.location = goto; }; </script> <a class="desktop-github-icon ml-auto" href="https://github.com/slsa-framework/slsa" target="_blank"> <svg width="22" height="22" viewBox="0 0 22 22" fill="currentColor" xmlns="http://www.w3.org/2000/svg"> <path fill-rule="evenodd" clip-rule="evenodd" d="M11.2344 0.150879C5.28641 0.150879 0.468811 4.96848 0.468811 10.9165C0.468811 15.6803 3.55046 19.7039 7.82978 21.1303C8.36806 21.2245 8.56991 20.9016 8.56991 20.619C8.56991 20.3633 8.55646 19.5155 8.55646 18.6139C5.8516 19.1118 5.15184 17.9545 4.93653 17.3489C4.81541 17.0394 4.29059 16.084 3.83306 15.8283C3.45626 15.6264 2.91798 15.1285 3.8196 15.1151C4.66739 15.1016 5.27295 15.8956 5.47481 16.2185C6.44371 17.8468 7.99126 17.3893 8.61028 17.1067C8.70448 16.4069 8.98708 15.9359 9.29659 15.6668C6.90125 15.3977 4.39825 14.4691 4.39825 10.3513C4.39825 9.18051 4.81541 8.21161 5.50172 7.45802C5.39407 7.18888 5.01727 6.08541 5.60938 4.60514C5.60938 4.60514 6.51099 4.32254 8.56991 5.70861C9.43116 5.46639 10.3462 5.34527 11.2613 5.34527C12.1764 5.34527 13.0914 5.46639 13.9527 5.70861C16.0116 4.30909 16.9132 4.60514 16.9132 4.60514C17.5053 6.08541 17.1285 7.18888 17.0209 7.45802C17.7072 8.21161 18.1244 9.16706 18.1244 10.3513C18.1244 14.4826 15.6079 15.3977 13.2126 15.6668C13.6028 16.0032 13.9392 16.6492 13.9392 17.6584C13.9392 19.0983 13.9258 20.2556 13.9258 20.619C13.9258 20.9016 14.1276 21.238 14.6659 21.1303C16.8031 20.4088 18.6602 19.0353 19.9758 17.2031C21.2915 15.3708 21.9994 13.1721 22 10.9165C22 4.96848 17.1824 0.150879 11.2344 0.150879Z" /> </svg> </a> </div> </header> <main class="site-clamp" aria-label="Content"> <header class="content-header"> <h1 class="mb-16">Terminology</h1> </header> <div class="site-content has-toc"> <aside class="table-of-contents flex flex-col"> <div class="rounded-lg p-4 border border-gray-400 mb-4"> Status: <a href="/spec-stages" style="display: inline">Approved</a> </div> <div class="flex-auto rounded-lg p-4 border border-gray-400 overflow-auto"> <p class="header-small uppercase">On this page</p> <ul><li><a href="#software-supply-chain">Software supply chain</a><ul><li><a href="#roles">Roles</a></li><li><a href="#build-model">Build model</a></li><li><a href="#package-model">Package model</a></li><li><a href="#mapping-to-real-world-ecosystems">Mapping to real-world ecosystems</a></li><li><a href="#verification-model">Verification model</a></li></ul></li></ul> </div> </aside> <div class="content markdown">  <p>Before diving into the <a href="/spec/v1.0/levels">SLSA Levels</a>, we need to establish a core set of terminology and models to describe what we’re protecting.</p> <h2 id="software-supply-chain">Software supply chain</h2> <p>SLSA’s framework addresses every step of the software supply chain - the sequence of steps resulting in the creation of an artifact. We represent a supply chain as a <a href="https://en.wikipedia.org/wiki/Directed_acyclic_graph">directed acyclic graph</a> of sources, builds, dependencies, and packages. One artifact’s supply chain is a combination of its dependencies’ supply chains plus its own sources and builds.</p> <p><img src="/spec/v1.0/images/supply-chain-model.svg" alt="Software Supply Chain Model" /></p> <table> <thead> <tr> <th>Term</th> <th>Description</th> <th>Example</th> </tr> </thead> <tbody> <tr> <td>Artifact</td> <td>An immutable blob of data; primarily refers to software, but SLSA can be used for any artifact.</td> <td>A file, a git commit, a directory of files (serialized in some way), a container image, a firmware image.</td> </tr> <tr> <td>Attestation</td> <td>An authenticated statement (metadata) about a software artifact or collection of software artifacts.</td> <td>A signed <a href="/provenance/v1">SLSA Provenance</a> file.</td> </tr> <tr> <td>Source</td> <td>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.</td> <td>Git commit (source) hosted on GitHub (platform).</td> </tr> <tr> <td><a href="#build-model">Build</a></td> <td>Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs.</td> <td>.travis.yml (process) run by Travis CI (platform).</td> </tr> <tr> <td><a href="#package-model">Package</a></td> <td>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.</td> <td>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.</td> </tr> <tr> <td>Dependency</td> <td>Artifact that is an input to a build process but that is not a source. In the model, it is always a package.</td> <td>Alpine package (package) distributed on Alpine Linux (platform).</td> </tr> </tbody> </table> <h3 id="roles">Roles</h3> <p>Throughout the specification, you will see reference to the following roles that take part in the software supply chain. Note that in practice a role may be filled by more than one person or an organization. Similarly, a person or organization may act as more than one role in a particular software supply chain.</p> <table> <thead> <tr> <th>Role</th> <th>Description</th> <th>Examples</th> </tr> </thead> <tbody> <tr> <td>Producer</td> <td>A party who creates software and provides it to others. Producers are often also consumers.</td> <td>An open source project’s maintainers. A software vendor.</td> </tr> <tr> <td>Verifier</td> <td>A party who inspect an artifact’s provenance to determine the artifact’s authenticity.</td> <td>A business’s software ingestion system. A programming language ecosystem’s package registry.</td> </tr> <tr> <td>Consumer</td> <td>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.</td> <td>A developer who uses open source software distributions. A business that uses a point of sale system.</td> </tr> <tr> <td>Infrastructure provider</td> <td>A party who provides software or services to other roles.</td> <td>A package registry’s maintainers. A build platform’s maintainers.</td> </tr> </tbody> </table> <h3 id="build-model">Build model</h3> <p align="center"><img src="images/build-model.svg" alt="Model Build"></p> <p>We model a build as running on a multi-tenant <em>build platform</em>, where each execution is independent.</p> <ol> <li>A tenant invokes the build by specifying <em>external parameters</em> through an <em>interface</em>, either directly or via some trigger. Usually, at least one of these external parameters is a reference to a <em>dependency</em>. (External parameters are literal values while dependencies are artifacts.)</li> <li>The build platform’s <em>control plane</em> interprets these external parameters, fetches an initial set of dependencies, initializes a <em>build environment</em>, and then starts the execution within that environment.</li> <li>The build then performs arbitrary steps, which might include fetching additional dependencies, and then produces one or more <em>output</em> artifacts. The steps within the build environment are under the tenant’s control. The build platform isolates build environments from one another to some degree (which is measured by the SLSA Build Level).</li> <li>Finally, for SLSA Build L2+, the control plane outputs <em>provenance</em> describing this whole process.</li> </ol> <p>Notably, there is no formal notion of “source” in the build model, just external parameters and dependencies. Most build platforms have an explicit “source” artifact to build from, which is often a git repository; in the build model, the reference to this artifact is an external parameter while the artifact itself is a dependency.</p> <p>For examples of how this model applies to real-world build platforms, see <a href="/provenance/v1#index-of-build-types">index of build types</a>.</p> <table> <thead> <tr> <th>Primary Term</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>Platform</td> <td>System that allows tenants to run builds. Technically, it is the transitive closure of software and services that must be trusted to faithfully execute the build. It includes software, hardware, people, and organizations.</td> </tr> <tr> <td>Admin</td> <td>A privileged user with administrative access to the platform, potentially allowing them to tamper with builds or the control plane.</td> </tr> <tr> <td>Tenant</td> <td>An untrusted user that builds an artifact on the platform. The tenant defines the build steps and external parameters.</td> </tr> <tr> <td>Control plane</td> <td>Build platform component that orchestrates each independent build execution and produces provenance. The control plane is managed by an admin and trusted to be outside the tenant’s control.</td> </tr> <tr> <td>Build</td> <td>Process that converts input sources and dependencies into output artifacts, defined by the tenant and executed within a single build environment on a platform.</td> </tr> <tr> <td>Steps</td> <td>The set of actions that comprise a build, defined by the tenant.</td> </tr> <tr> <td>Build environment</td> <td>The independent execution context in which the build runs, initialized by the control plane. In the case of a distributed build, this is the collection of all such machines/containers/VMs that run steps.</td> </tr> <tr> <td>Build caches</td> <td>An intermediate artifact storage managed by the platform that maps intermediate artifacts to their explicit inputs. A build may share build caches with any subsequent build running on the platform.</td> </tr> <tr> <td>External parameters</td> <td>The set of top-level, independent inputs to the build, specified by a tenant and used by the control plane to initialize the build.</td> </tr> <tr> <td>Dependencies</td> <td>Artifacts fetched during initialization or execution of the build process, such as configuration files, source artifacts, or build tools.</td> </tr> <tr> <td>Outputs</td> <td>Collection of artifacts produced by the build.</td> </tr> <tr> <td>Provenance</td> <td>Attestation (metadata) describing how the outputs were produced, including identification of the platform and external parameters.</td> </tr> </tbody> </table> <details><summary>Ambiguous terms to avoid</summary> <ul> <li><em>Build recipe:</em> Could mean <em>external parameters,</em> but may include concrete steps of how to perform a build. To avoid implementation details, we don’t define this term, but always use “external parameters” which is the interface to a build platform. Similar terms are <em>build configuration source</em> and <em>build definition</em>.</li> <li><em>Builder:</em> Usually means <em>build platform</em>, but might be used for <em>build environment</em>, the user who invoked the build, or a build tool from <em>dependencies</em>. To avoid confusion, we always use “build platform”. The only exception is in the <a href="/provenance/v1">provenance</a>, where <code>builder</code> is used as a more concise field name.</li> </ul> </details> <h3 id="package-model">Package model</h3> <p>Software is distributed in identifiable units called <dfn>packages</dfn> according to the rules and conventions of a <dfn>package ecosystem</dfn>. Examples of formal ecosystems include <a href="https://www.pypa.io">Python/PyPA</a>, <a href="https://wiki.debian.org/DebianRepository/Format">Debian/Apt</a>, and <a href="https://github.com/opencontainers/distribution-spec">OCI</a>, while examples of informal ecosystems include links to files on a website or distribution of first-party software within a company.</p> <p>Abstractly, a consumer locates software within an ecosystem by asking a <dfn>package registry</dfn> to resolve a mutable <dfn>package name</dfn> into an immutable <dfn>package artifact</dfn>.<sup class="footnote-ref"><a href="#fn1" id="fnref1">1</a></sup> To <dfn>publish</dfn> a package artifact, the software producer asks the registry to update this mapping to resolve to the new artifact. The registry represents the entity or entities with the power to alter what artifacts are accepted by consumers for a given package name. For example, if consumers only accept packages signed by a particular public key, then it is access to that public key that serves as the registry.</p> <p>The package name is the primary security boundary within a package ecosystem. Different package names represent materially different pieces of software—different owners, behaviors, security properties, and so on. Therefore, <strong>the package name is the primary unit being protected in SLSA</strong>. It is the primary identifier to which consumers attach expectations.</p> <table> <thead> <tr> <th>Term</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>Package</td> <td>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.</td> </tr> <tr> <td>Package artifact</td> <td>A file or other immutable object that is intended for distribution.</td> </tr> <tr> <td>Package ecosystem</td> <td>A set of rules and conventions governing how packages are distributed, including how clients resolve a package name into one or more specific artifacts.</td> </tr> <tr> <td>Package manager client</td> <td>Client-side tooling to interact with a package ecosystem.</td> </tr> <tr> <td>Package name</td> <td><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.</td> </tr> <tr> <td>Package registry</td> <td>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.</td> </tr> <tr> <td>Publish [a package]</td> <td>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.</td> </tr> </tbody> </table> <details><summary>Ambiguous terms to avoid</summary> <ul> <li><em>Package repository:</em> Could mean either package registry or package name, depending on the ecosystem. To avoid confusion, we always use “repository” exclusively to mean “source repository”, where there is no ambiguity.</li> <li><em>Package manager</em> (without “client”): Could mean either package ecosystem, package registry, or client-side tooling.</li> </ul> </details> <h3 id="mapping-to-real-world-ecosystems">Mapping to real-world ecosystems</h3> <p>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!</p>  <table> <tr> <th>Package ecosystem <th>Package registry <th>Package name <th>Package artifact <tr> <td colspan=4><em>Languages</em> <tr> <td><a href="https://doc.rust-lang.org/cargo/appendix/glossary.html">Cargo</a> (Rust) <td><a href="https://doc.rust-lang.org/cargo/appendix/glossary.html#registry">Registry</a> <td><a href="https://doc.rust-lang.org/cargo/appendix/glossary.html#crate">Crate name</a> <td><a href="https://doc.rust-lang.org/cargo/appendix/glossary.html#artifact">Artifact</a> <tr> <td><a href="http://neilb.org/2015/09/05/cpan-glossary.html">CPAN</a> (Perl) <td>Upload server <td>Distribution <td>Release (or Distribution) <tr> <td><a href="https://go.dev/ref/mod">Go</a> <td><a href="https://go.dev/ref/mod#glos-module-proxy">Module proxy</a> <td><a href="https://go.dev/ref/mod#glos-module-path">Module path</a> <td><a href="https://go.dev/ref/mod#glos-module">Module</a> <tr> <td><a href="https://maven.apache.org/glossary">Maven</a> (Java) <td>Repository <td>Group ID + Artifact ID <td>Artifact <tr> <td><a href="https://www.npmjs.com/">npm</a> (JavaScript) <td><a href="https://docs.npmjs.com/about-the-public-npm-registry">Registry</a> <td><a href="https://docs.npmjs.com/package-name-guidelines">Package Name</a> <td><a href="https://docs.npmjs.com/about-packages-and-modules">Package</a> <tr> <td><a href="https://docs.microsoft.com/en-us/nuget/nuget-org/overview-nuget-org">NuGet</a> (C#) <td>Host <td>Project <td>Package <tr> <td><a href="https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-name-convention">PyPA</a> (Python) <td><a href="https://packaging.python.org/en/latest/glossary/#term-Package-Index">Index</a> <td><a href="https://packaging.python.org/en/latest/glossary/#term-Project">Project Name</a> <td><a href="https://packaging.python.org/en/latest/glossary/#term-Distribution-Package">Distribution</a> <tr> <td colspan=4><em>Operating systems</em> <tr> <td><a href="https://wiki.debian.org/Teams/Dpkg">Dpkg </a> (e.g. Debian) <td><em>?</em> <td>Package name <td>Package <tr> <td><a href="https://docs.flatpak.org/en/latest/introduction.html#terminology">Flatpak</a> <td>Repository <td>Application <td>Bundle <tr> <td><a href="https://docs.brew.sh/Manpage">Homebrew</a> (e.g. Mac) <td>Repository (Tap) <td>Package name (Formula) <td>Binary package (Bottle) <tr> <td><a href="https://wiki.archlinux.org/title/Pacman">Pacman</a> (e.g. Arch) <td>Repository <td>Package name <td>Package <tr> <td><a href="https://rpm.org">RPM</a> (e.g. Red Hat) <td>Repository <td>Package name <td>Package <tr> <td><a href="https://nixos.org/manual/nix">Nix</a> (e.g. <a href="https://nixos.org/">NixOS</a>) <td>Repository (e.g. <a href="https://github.com/NixOS/nixpkgs">Nixpkgs</a>) or <a href="https://nixos.org/manual/nix/stable/glossary.html#gloss-binary-cache">binary cache</a> <td><a href="https://nixos.org/manual/nix/stable/language/derivations.html">Derivation name</a> <td><a href="https://nixos.org/manual/nix/stable/language/derivations.html">Derivation</a> or <a href="https://nixos.org/manual/nix/stable/glossary.html#gloss-store-object">store object</a> <tr> <td colspan=4><em>Storage systems</em> <tr> <td><a href="https://cloud.google.com/storage/docs/key-terms">GCS</a> <td><em>n/a</em> <td>Object name <td>Object <tr> <td><a href="https://github.com/opencontainers/distribution-spec/blob/main/spec.md#definitions">OCI</a>/Docker <td>Registry <td>Repository <td>Object <tr> <td colspan=4><em>Meta</em> <tr> <td><a href="https://deps.dev/glossary">deps.dev</a>: <a href="https://deps.dev/glossary#system">System</a> <td><a href="https://deps.dev/glossary#packaging-authority">Packaging authority</a> <td><a href="https://deps.dev/glossary#package">Package</a> <td><em>n/a</em> <tr> <td><a href="https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst">purl</a>: type <td>Namespace <td>Name <td><em>n/a</em> </table> <p>Notes:</p> <ul> <li>Go 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 <em>module proxy</em>. 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 <em>checksum database</em> guarantees that all clients receive the same artifact for a given URL.</li> </ul> <h3 id="verification-model">Verification model</h3> <p>Verification in SLSA is performed in two ways. Firstly, the build platform is certified to ensure conformance with the requirements at the level claimed by the build platform. This certification should happen on a recurring cadence with the outcomes published by the platform operator for their users to review and make informed decisions about which builders to trust.</p> <p>Secondly, artifacts are verified to ensure they meet the producer defined expectations of where the package source code was retrieved from and on what build platform the package was built.</p> <p><img src="/spec/v1.0/images/verification-model.svg" alt="Verification Model" /></p> <table> <thead> <tr> <th>Term</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>Expectations</td> <td>A set of constraints on the package’s provenance metadata. The package producer sets expectations for a package, whether explicitly or implicitly.</td> </tr> <tr> <td>Provenance verification</td> <td>Artifacts are verified by the package ecosystem to ensure that the package’s expectations are met before the package is used.</td> </tr> <tr> <td>Build platform certification</td> <td><a href="/spec/v1.0/verifying-systems">Build platforms are certified</a> for their conformance to the SLSA requirements at the stated level.</td> </tr> </tbody> </table> <p>The examples below suggest some ways that expectations and verification may be implemented for different, broadly defined, package ecosystems.</p> <details><summary>Example: Small software team</summary> <table> <thead> <tr> <th>Term</th> <th>Example</th> </tr> </thead> <tbody> <tr> <td>Expectations</td> <td>Defined by the producer’s security personnel and stored in a database.</td> </tr> <tr> <td>Provenance verification</td> <td>Performed automatically on cluster nodes before execution by querying the expectations database.</td> </tr> <tr> <td>Build platform certification</td> <td>The build platform implementer follows secure design and development best practices, does annual penetration testing exercises, and self-certifies their conformance to SLSA requirements.</td> </tr> </tbody> </table> </details> <details><summary>Example: Open source language distribution</summary> <table> <thead> <tr> <th>Term</th> <th>Example</th> </tr> </thead> <tbody> <tr> <td>Expectations</td> <td>Defined separately for each package and stored in the package registry.</td> </tr> <tr> <td>Provenance verification</td> <td>The language distribution registry verifies newly uploaded packages meet expectations before publishing them. Further, the package manager client also verifies expectations prior to installing packages.</td> </tr> <tr> <td>Build platform certification</td> <td>Performed by the language ecosystem packaging authority.</td> </tr> </tbody> </table> </details> <section class="footnotes"> <ol> <li id="fn1"> <p>This resolution might include a version number, label, or some other selector in addition to the package name, but that is not important to SLSA. <a href="#fnref1" class="footnote-backref">↩</a></p> </li> </ol> </section> <div class="mt-10 pt-10 border-t flex flex-col sm:flex-row space-between gap-5"> <a href="/spec/v1.0/future-directions" class="border rounded px-4 py-2 text-left">&lsaquo; Future directions</a> <a href="/spec/v1.0/levels" class="sm:ml-auto border rounded px-4 py-2 text-right">Security levels &rsaquo;</a> </div> </div> </div> </main><footer class="site-footer flex-none h-card text-white"> <div class="site-clamp py-4 flex flex-wrap items-start justify-between w-full"> <div class="w-full md:w-1/3 mb-8 md:mb-0"> <p><strong>SLSA is a cross-industry collaboration.</strong><br> © 2024 The Linux Foundation, under the terms of the <a href="https://github.com/slsa-framework/governance">Community Specification License 1.0</a></p> </div> <div class="w-full md:w-1/3 mb-8 md:mb-0"> <p><strong>Privacy statement</strong><br> We use <a href="https://goatcounter.com">GoatCounter</a> to help us improve our website by collecting and reporting information on how it's used. We do not store advertising or tracking cookies. The information we collect does not identify anyone and does not track an individual's use of the site.</p> </div> <div class="w-full md:w-1/4 mb-8 md:mb-0 flex md:justify-end"> <p> <a href="https://github.com/slsa-framework/slsa/blob/089d120f336c9acf4d16af1fd889a26b0d7c372a/docs/spec/v1.0/terminology.md?plain=1" target="_blank" class="flex gap-4 h5 font-normal"> View source on GitHub <svg width="22" height="22" viewBox="0 0 22 22" fill="none" xmlns="http://www.w3.org/2000/svg"> <path fill-rule="evenodd" clip-rule="evenodd" d="M11.2344 0.150879C5.28641 0.150879 0.468811 4.96848 0.468811 10.9165C0.468811 15.6803 3.55046 19.7039 7.82978 21.1303C8.36806 21.2245 8.56991 20.9016 8.56991 20.619C8.56991 20.3633 8.55646 19.5155 8.55646 18.6139C5.8516 19.1118 5.15184 17.9545 4.93653 17.3489C4.81541 17.0394 4.29059 16.084 3.83306 15.8283C3.45626 15.6264 2.91798 15.1285 3.8196 15.1151C4.66739 15.1016 5.27295 15.8956 5.47481 16.2185C6.44371 17.8468 7.99126 17.3893 8.61028 17.1067C8.70448 16.4069 8.98708 15.9359 9.29659 15.6668C6.90125 15.3977 4.39825 14.4691 4.39825 10.3513C4.39825 9.18051 4.81541 8.21161 5.50172 7.45802C5.39407 7.18888 5.01727 6.08541 5.60938 4.60514C5.60938 4.60514 6.51099 4.32254 8.56991 5.70861C9.43116 5.46639 10.3462 5.34527 11.2613 5.34527C12.1764 5.34527 13.0914 5.46639 13.9527 5.70861C16.0116 4.30909 16.9132 4.60514 16.9132 4.60514C17.5053 6.08541 17.1285 7.18888 17.0209 7.45802C17.7072 8.21161 18.1244 9.16706 18.1244 10.3513C18.1244 14.4826 15.6079 15.3977 13.2126 15.6668C13.6028 16.0032 13.9392 16.6492 13.9392 17.6584C13.9392 19.0983 13.9258 20.2556 13.9258 20.619C13.9258 20.9016 14.1276 21.238 14.6659 21.1303C16.8031 20.4088 18.6602 19.0353 19.9758 17.2031C21.2915 15.3708 21.9994 13.1721 22 10.9165C22 4.96848 17.1824 0.150879 11.2344 0.150879Z" fill="white"/> </svg> </a> <br> This site is powered by <a href="https://www.netlify.com">Netlify</a> </p> </div> </div> <div class="site-clamp py-4 flex items-start justify-between w-full mb-16 md:mb-0"> <a rel="author" href="/"><img src="/images/logo.svg" alt="SLSA logo" /></a> </div> </footer> </div> </body> </html>