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="Verifying build platforms" /> <meta property="og:locale" content="en_US" /> <meta name="description" content="Guidelines for assessing build platform security." /> <meta property="og:description" content="Guidelines for assessing build platform security." /> <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="Verifying build platforms" /> <script type="application/ld+json"> {"@context":"https://schema.org","@type":"WebPage","description":"Guidelines for assessing build platform security.","headline":"Verifying build platforms","image":"/images/icons/android-chrome-192x192.png","publisher":{"@type":"Organization","logo":{"@type":"ImageObject","url":"/images/icons/android-chrome-512x512.png"}},"url":"/spec/v1.0/verifying-systems"}</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 • Verifying build platforms</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/verifying-systems" class="inline-block">Version 1.1 RC</option> <option selected value="/spec/v1.0/verifying-systems" class="inline-block">Version 1.0</option> <option disabled value="/spec/v0.1/verifying-systems" class="inline-block">Version 0.1</option> <option value="/spec/draft/verifying-systems" 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" 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 is-active" 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/verifying-systems" class="inline-block">Version 1.1 RC</option> <option selected value="/spec/v1.0/verifying-systems" class="inline-block">Version 1.0</option> <option disabled value="/spec/v0.1/verifying-systems" class="inline-block">Version 0.1</option> <option value="/spec/draft/verifying-systems" 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">Verifying build platforms</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="#threats">Threats</a><ul><li><a href="#adversary-goal">Adversary goal</a></li><li><a href="#adversary-profiles">Adversary profiles</a></li></ul></li><li><a href="#build-platform-components">Build platform components</a><ul><li><a href="#external-parameters">External parameters</a></li><li><a href="#control-plane">Control plane</a></li><li><a href="#build-environment">Build environment</a></li><li><a href="#cache">Cache</a></li><li><a href="#output-storage">Output storage</a></li></ul></li><li><a href="#builder-evaluation">Builder evaluation</a></li></ul> </div> </aside> <div class="content markdown"> <p>One of SLSA’s guiding <a href="/spec/v1.0/principles">principles</a> is to “trust platforms, verify artifacts”. However, consumers cannot trust platforms to produce Build L3 artifacts and provenance unless they have some proof that the provenance is <a href="/spec/v1.0/requirements#provenance-unforgeable">unforgeable</a> and the builds are <a href="/spec/v1.0/requirements#isolated">isolated</a>.</p> <p>This page describes the parts of a build platform that consumers SHOULD assess and provides sample questions consumers can ask when assessing a build platform. See also <a href="/spec/v1.0/threats">Threats & mitigations</a> and the <a href="/spec/v1.0/terminology#build-model">build model</a>.</p> <h2 id="threats">Threats</h2> <h3 id="adversary-goal">Adversary goal</h3> <p>The SLSA Build track defends against an adversary whose primary goal is to inject unofficial behavior into a package artifact while avoiding detection. Remember that <a href="/spec/v1.0/verifying-artifacts">verifiers</a> only accept artifacts whose provenance matches expectations. To bypass this, the adversary tries to either (a) tamper with a legitimate build whose provenance already matches expectations, or (b) tamper with an illegitimate build’s provenance to make it match expectations.</p> <p>More formally, if a build with external parameters P would produce an artifact with binary hash X and a build with external parameters P’ would produce an artifact with binary hash Y, they wish to produce provenance indicating a build with external parameters P produced an artifact with binary hash Y.</p> <p>See threats <a href="/spec/v1.0/threats#c-build-from-modified-source">C</a>, <a href="/spec/v1.0/threats#d-use-compromised-dependency">D</a>, <a href="/spec/v1.0/threats#e-compromise-build-process">E</a>, and <a href="/spec/v1.0/threats#f-upload-modified-package">F</a> for examples of specific threats.</p> <p>Note: Platform abuse (e.g. running non-build workloads) and attacks against builder availability are out of scope of this document.</p> <h3 id="adversary-profiles">Adversary profiles</h3> <p>Consumers SHOULD also evaluate the build platform’s ability to defend against the following types of adversaries.</p> <ol> <li>Project contributors, who can: <ul> <li>Create builds on the build platform. These are the adversary’s controlled builds.</li> <li>Modify one or more controlled builds’ external parameters.</li> <li>Modify one or more controlled builds’ environments and run arbitrary code inside those environments.</li> <li>Read the target build’s source repo.</li> <li>Fork the target build’s source repo.</li> <li>Modify a fork of the target build’s source repo and build from it.</li> </ul> </li> <li>Project maintainer, who can: <ul> <li>Do everything listed under “project contributors”.</li> <li>Create new builds under the target build’s project or identity.</li> <li>Modify the target build’s source repo and build from it.</li> <li>Modify the target build’s configuration.</li> </ul> </li> <li>Build platform administrators, who can: <ul> <li>Do everything listed under “project contributors” and “project maintainers”.</li> <li>Run arbitrary code on the build platform.</li> <li>Read and modify network traffic.</li> <li>Access the control plane’s cryptographic secrets.</li> <li>Remotely access build environments (e.g. via SSH).</li> </ul> </li> </ol> <h2 id="build-platform-components">Build platform components</h2> <p>Consumers SHOULD consider at least these five elements of the <a href="/spec/v1.0/terminology#build-model">build model</a> when assessing build platforms for SLSA conformance: external parameters, control plane, build environments, caches, and outputs.</p> <p><img src="/spec/v1.0/images/build-model.svg" alt="image" /></p> <p>The following sections detail these elements of the build model and give prompts for assessing a build platform’s ability to produce SLSA Build L3 provenance. The assessment SHOULD take into account the security model used to identify the transitive closure of the <code>builder.id</code> for the [provenance model], specifically around the platform’s boundaries, actors, and interfaces.</p> <h3 id="external-parameters">External parameters</h3> <p>External parameters are the external interface to the builder and include all inputs to the build process. Examples include the source to be built, the build definition/script to be executed, user-provided instructions to the control plane for how to create the build environment (e.g. which operating system to use), and any additional user-provided strings.</p> <h4 id="prompts-for-assessing-external-parameters">Prompts for assessing external parameters</h4> <ul> <li>How does the control plane process user-provided external parameters? Examples: sanitizing, parsing, not at all</li> <li>Which external parameters are processed by the control plane and which are processed by the build environment?</li> <li>What sort of external parameters does the control plane accept for build environment configuration?</li> <li>How do you ensure that all external parameters are represented in the provenance?</li> <li>How will you ensure that future design changes will not add additional external parameters without representing them in the provenance?</li> </ul> <h3 id="control-plane">Control plane</h3> <p>The control plane is the build platform component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. At SLSA Build L2+ the control plane generates and signs provenance for each build performed on the build platform. The control plane is operated by one or more administrators, who have privileges to modify the control plane.</p> <h4 id="prompts-for-assessing-the-control-plane">Prompts for assessing the control plane</h4> <ul> <li> <p>Administration</p> <ul> <li>What are the ways an employee can use privileged access to influence a build or provenance generation? Examples: physical access, terminal access, access to cryptographic secrets</li> <li>What controls are in place to detect or prevent the employee from abusing such access? Examples: two-person approvals, audit logging, workload identities</li> <li>Roughly how many employees have such access?</li> <li>How are privileged accounts protected? Examples: two-factor authentication, client device security policies</li> <li>What plans do you have for recovering from security incidents and platform outages? Are they tested? How frequently?</li> </ul> </li> <li> <p>Provenance generation</p> <ul> <li>How does the control plane observe the build to ensure the provenance’s accuracy?</li> <li>Are there situations in which the control plane will not generate provenance for a completed build? What are they?</li> </ul> </li> <li> <p>Development practices</p> <ul> <li>How do you track the control plane’s software and configuration? Example: version control</li> <li>How do you build confidence in the control plane’s software supply chain? Example: SLSA L3+ provenance, build from source</li> <li>How do you secure communications between builder components? Example: TLS with certificate transparency.</li> <li>Are you able to perform forensic analysis on compromised build environments? How? Example: retain base images indefinitely</li> </ul> </li> <li> <p>Creating build environments</p> <ul> <li>How does the control plane share data with build environments? Example: mounting a shared file system partition</li> <li>How does the control plane protect its integrity from build environments? Example: not mount its own file system partitions on build environments</li> <li>How does the control plane prevent build environments from accessing its cryptographic secrets? Examples: dedicated secret storage, not mounting its own file system partitions to build environments, hardware security modules</li> </ul> </li> <li> <p>Managing cryptographic secrets</p> <ul> <li>How do you store the control plane’s cryptographic secrets?</li> <li>Which parts of the organization have access to the control plane’s cryptographic secrets?</li> <li>What controls are in place to detect or prevent employees abusing such access? Examples: two-person approvals, audit logging</li> <li>How are secrets protected in memory? Examples: secrets are stored in hardware security modules and backed up in secure cold storage</li> <li>How frequently are cryptographic secrets rotated? Describe the rotation process.</li> <li>What is your plan for remediating cryptographic secret compromise? How frequently is this plan tested?</li> </ul> </li> </ul> <h3 id="build-environment">Build environment</h3> <p>The build environment is the independent execution context where the build takes place. In the case of a distributed build, the build environment is the collection of all execution contexts that run build steps. Each build environment must be isolated from the control plane and from all other build environments, including those running builds from the same tenant or project. Tenants are free to modify the build environment arbitrarily. Build environments must have a means to fetch input artifacts (source, dependencies, etc).</p> <h4 id="prompts-for-assessing-build-environments">Prompts for assessing build environments</h4> <ul> <li> <p>Isolation technologies</p> <ul> <li>How are build environments isolated from the control plane and each other? Examples: VMs, containers, sandboxed processes</li> <li>How is separation achieved between trusted and untrusted processes?</li> <li>How have you hardened your build environments against malicious tenants? Examples: configuration hardening, limiting attack surface</li> <li>How frequently do you update your isolation software?</li> <li>What is your process for responding to vulnerability disclosures? What about vulnerabilities in your dependencies?</li> <li>What prevents a malicious build from gaining persistence and influencing subsequent builds?</li> </ul> </li> <li> <p>Creation and destruction</p> <ul> <li>What operating system and utilities are available in build environments on creation? How were these elements chosen? Examples: A minimal Linux distribution with its package manager, OSX with HomeBrew</li> <li>How long could a compromised build environment remain active in the build platform?</li> </ul> </li> <li> <p>Network access</p> <ul> <li>Are build environments able to call out to remote execution? If so, how do you prevent them from tampering with the control plane or other build environments over the network?</li> <li>Are build environments able to open services on the network? If so, how do you prevent remote interference through these services?</li> </ul> </li> </ul> <h3 id="cache">Cache</h3> <p>Builders may have zero or more caches to store frequently used dependencies. Build environments may have either read-only or read-write access to caches.</p> <h4 id="prompts-for-assessing-caches">Prompts for assessing caches</h4> <ul> <li>What sorts of caches are available to build environments?</li> <li>How are those caches populated?</li> <li>How are cache contents validated before use?</li> </ul> <h3 id="output-storage">Output storage</h3> <p>Output Storage holds built artifacts and their provenance. Storage may either be shared between build projects or allocated separately per-project.</p> <h4 id="prompts-for-assessing-output-storage">Prompts for assessing output storage</h4> <ul> <li>How do you prevent builds from reading or overwriting files that belong to another build? Example: authorization on storage</li> <li>What processing, if any, does the control plane do on output artifacts?</li> </ul> <h2 id="builder-evaluation">Builder evaluation</h2> <p>Organizations can either self-attest to their answers or seek certification from a third-party auditor. Evidence for self-attestation should be published on the internet and can include information such as the security model defined as part of the provenance. Evidence submitted for third-party certification need not be published.</p> <div class="mt-10 pt-10 border-t flex flex-col sm:flex-row space-between gap-5"> <a href="/spec/v1.0/verifying-artifacts" class="border rounded px-4 py-2 text-left">&lsaquo; Verifying artifacts</a> <a href="/spec/v1.0/threats" class="sm:ml-auto border rounded px-4 py-2 text-right">Threats & mitigations &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/910587ad00cc1f893b1e1ef6af3fb00c382e72f3/docs/spec/v1.0/verifying-systems.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>