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="Frequently asked questions" /> <meta property="og:locale" content="en_US" /> <meta name="description" content="Answers to questions frequently asked about SLSA." /> <meta property="og:description" content="Answers to questions frequently asked about SLSA." /> <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="Frequently asked questions" /> <script type="application/ld+json"> {"@context":"https://schema.org","@type":"WebPage","description":"Answers to questions frequently asked about SLSA.","headline":"Frequently asked questions","image":"/images/icons/android-chrome-192x192.png","publisher":{"@type":"Organization","logo":{"@type":"ImageObject","url":"/images/icons/android-chrome-512x512.png"}},"url":"/spec/v1.0/faq"}</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 • Frequently asked questions</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/faq" class="inline-block">Version 1.1 RC</option> <option selected value="/spec/v1.0/faq" class="inline-block">Version 1.0</option> <option value="/spec/v0.1/faq" class="inline-block">Version 0.1</option> <option value="/spec/draft/faq" 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 is-active" 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" 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/faq" class="inline-block">Version 1.1 RC</option> <option selected value="/spec/v1.0/faq" class="inline-block">Version 1.0</option> <option value="/spec/v0.1/faq" class="inline-block">Version 0.1</option> <option value="/spec/draft/faq" 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">Frequently asked questions</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="#q-why-is-slsa-not-transitive">Q: Why is SLSA not transitive?</a></li><li><a href="#q-what-about-reproducible-builds">Q: What about reproducible builds?</a></li><li><a href="#q-how-does-slsa-relate-to-in-toto">Q: How does SLSA relate to in-toto?</a></li><li><a href="#q-what-is-the-difference-between-a-build-platform-system-and-service">Q. What is the difference between a build platform, system, and service?</a></li><li><a href="#q-is-slsa-the-same-as-tacos">Q: Is SLSA the same as TACOS?</a></li><li><a href="#q-how-does-slsa-and-slsa-provenance-relate-to-sbom">Q: How does SLSA and SLSA Provenance relate to SBOM?</a></li><li><a href="#q-how-to-slsa-with-a-self-hosted-runner">Q: How to SLSA with a self-hosted runner</a></li></ul> </div> </aside> <div class="content markdown"> <h2 id="q-why-is-slsa-not-transitive">Q: Why is SLSA not transitive?</h2> <p>SLSA Build levels only cover the trustworthiness of a single build, with no requirements about the build levels of transitive dependencies. The reason for this is to make the problem tractable. If a SLSA Build level required dependencies to be the same level, then reaching a level would require starting at the very beginning of the supply chain and working forward. This is backwards, forcing us to work on the least risky component first and blocking any progress further downstream. By making each artifact’s SLSA rating independent from one another, it allows parallel progress and prioritization based on risk. (This is a lesson we learned when deploying other security controls at scale throughout Google.) We expect SLSA ratings to be composed to describe a supply chain’s overall security stance, as described in the case study <a href="../../example.md#vision-case-study">vision</a>.</p> <h2 id="q-what-about-reproducible-builds">Q: What about reproducible builds?</h2> <p>When talking about <a href="https://reproducible-builds.org">reproducible builds</a>, there are two related but distinct concepts: “reproducible” and “verified reproducible.”</p> <p>“Reproducible” means that repeating the build with the same inputs results in bit-for-bit identical output. This property <a href="https://reproducible-builds.org/docs/buy-in/">provides</a> <a href="https://wiki.debian.org/ReproducibleBuilds/About">many</a> <a href="https://google.github.io/building-secure-and-reliable-systems/raw/ch14.html#hermeticcomma_reproduciblecomma_or_veri">benefits</a>, including easier debugging, more confident cherry-pick releases, better build caching and storage efficiency, and accurate dependency tracking.</p> <p>“Verified reproducible” means using two or more independent build platforms to corroborate the provenance of a build. In this way, one can create an overall platform that is more trustworthy than any of the individual components. This is often <a href="https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/">suggested</a> as a solution to supply chain integrity. Indeed, this is one option to secure build steps of a supply chain. When designed correctly, such a platform can satisfy all of the SLSA Build level requirements.</p> <p>That said, verified reproducible builds are not a complete solution to supply chain integrity, nor are they practical in all cases:</p> <ul> <li>Reproducible builds do not address source, dependency, or distribution threats.</li> <li>Reproducers must truly be independent, lest they all be susceptible to the same attack. For example, if all rebuilders run the same pipeline software, and that software has a vulnerability that can be triggered by sending a build request, then an attacker can compromise all rebuilders, violating the assumption above.</li> <li>Some builds cannot easily be made reproducible, as noted above.</li> <li>Closed-source reproducible builds require the code owner to either grant source access to multiple independent rebuilders, which is unacceptable in many cases, or develop multiple, independent in-house rebuilders, which is likely prohibitively expensive.</li> </ul> <p>Therefore, SLSA does not require verified reproducible builds directly. Instead, verified reproducible builds are one option for implementing the requirements.</p> <p>For more on reproducibility, see <a href="https://google.github.io/building-secure-and-reliable-systems/raw/ch14.html#hermeticcomma_reproduciblecomma_or_veri">Hermetic, Reproducible, or Verifiable?</a></p> <h2 id="q-how-does-slsa-relate-to-in-toto">Q: How does SLSA relate to in-toto?</h2> <p><a href="https://in-toto.io/">in-toto</a> is a framework to secure software supply chains hosted at the <a href="https://cncf.io/">Cloud Native Computing Foundation</a>. The in-toto specification provides a generalized workflow to secure different steps in a software supply chain. The SLSA specification recommends <a href="https://github.com/in-toto/attestation">in-toto attestations</a> as the vehicle to express Provenance and other attributes of software supply chains. Thus, in-toto can be thought of as the unopinionated layer to express information pertaining to a software supply chain, and SLSA as the opinionated layer specifying exactly what information must be captured in in-toto metadata to achieve the guarantees of a particular level.</p> <p>in-toto’s official implementations written in <a href="https://github.com/in-toto/in-toto-golang">Go</a>, <a href="https://github.com/in-toto/in-toto-java">Java</a>, and <a href="https://github.com/in-toto/in-toto-rs">Rust</a> include support for generating SLSA Provenance metadata. These APIs are used in other tools generating SLSA Provenance such as Sigstore’s cosign, the SLSA GitHub Generator, and the in-toto Jenkins plugin.</p> <h2 id="q-what-is-the-difference-between-a-build-platform-system-and-service">Q. What is the difference between a build platform, system, and service?</h2> <p>Build platform and build system have been used interchangeably in the past. With the v1.0 specification, however, there has been a unification around the term platform as indicated in the <a href="/spec/v1.0/terminology">Terminology</a>. The use of the word <code>system</code> still exists related to software and services within the build platform and to systems outside of a build platform like change management systems.</p> <p>A build service is a hosted build platform that is often run on shared infrastructure instead of individuals’ machines and workstations. Its use has also been replaced outside of the requirements as it relates to the build platform.</p> <h2 id="q-is-slsa-the-same-as-tacos">Q: Is SLSA the same as TACOS?</h2> <p>No. <a href="https://github.com/tacosframework">Trusted Attestation and Compliance for Open Source (TACOS)</a> is a framework authored by Tidelift. Per their website, TACOS is a framework “for assessing the development practices of open source projects against a set of secure development standards specified by the (US) NIST Secure Software Development Framework (SSDF) V1.1” which “vendors can use to provide self-attestation for the open source components they rely on.”</p> <p>In contrast, SLSA is a community-developed framework—including adoptable guidelines for securing a software supply chain and mechanism to evaluate the trustworthiness of artifacts you consume—that is part of the Open Source Security Foundation (OpenSSF).</p> <h2 id="q-how-does-slsa-and-slsa-provenance-relate-to-sbom">Q: How does SLSA and SLSA Provenance relate to SBOM?</h2> <p><a href="https://ntia.gov/sbom">Software Bill of Materials (SBOM)</a> are a frequently recommended tool for increased software supply chain rigor. An SBOM is typically focused on understanding software in order to evaluate risk through known vulnerabilities and license compliance. These use-cases require fine-grained and timely data which can be refined to improve signal-to-noise ratio.</p> <p><a href="/spec/v1.0/provenance">SLSA Provenance</a> and the <a href="/spec/v1.0/levels#build-track">Build track</a> are focused on trustworthiness of the build process. To improve trustworthiness, Provenance is generated in the build platform’s trusted control plane, which in practice results in it being coarse grained. For example, in Provenance metadata completeness of <code>resolvedDependencies</code> information is on a best-effort basis. Further, the <code>ResourceDescriptor</code> type does not require version and license information or even a URI to the dependency’s original location.</p> <p>While they likely include similar data, SBOMs and SLSA Provenance operate at different levels of abstraction. The fine-grained data in an SBOM typically describes the components present in a produced artifact, whereas SLSA Provenance more coarsely describes parameters of a build which are external to the build platform.</p> <p>The granularity and expressiveness of the two use-cases differs enough that current SBOM formats were deemed not a good fit for the requirements of the Build track. Yet SBOMs are a good practice and may form part of a future SLSA Vulnerabilities track. Further, SLSA Provenance can increase the trustworthiness of an SBOM by describing how the SBOM was created.</p> <p>SLSA Provenance, the wider <a href="https://github.com/in-toto/attestation/blob/main/spec/">in-toto Attestation Framework</a> in which the recommended format sits, and the various SBOM standards, are all rapidly evolving spaces. There is ongoing investigation into linking between the different formats and exploration of alignment on common models. This FAQ entry describes our understanding of the intersection efforts today. We do not know how things will evolve over the coming months and years, but we look forward to the collaboration and improved software supply chain security.</p> <h2 id="q-how-to-slsa-with-a-self-hosted-runner">Q: How to SLSA with a self-hosted runner</h2> <p>Some CI systems allow producers to provide their own self-hosted runners as a build environment (e.g. <a href="https://docs.github.com/en/actions/hosting-your-own-runners">GitHub Actions</a>). While there are many valid reasons to leverage these, classifying the SLSA build level for the resulting artifact can be confusing.</p> <p>Since the SLSA Build track describes increasing levels of trustworthiness and completeness in a package artifact’s <dfn>provenance</dfn>, interpretation of the specification hinges on the platform entities involved in the provenance generation. The SLSA <a href="/spec/v1.0/requirements">build level requirements</a> (secure key storage, isolation, etc.) should be imposed on the transitive closure of the systems which are responsible for informing the provenance generated.</p> <p>Some common situations may include:</p> <ul> <li>The platform generates the provenance and just calls a runner for individual build steps. In this situation, the provenance is only affected by the platform so there would be no requirements imposed on the runner.</li> <li>The runner generates the provenance. In this situation, the orchestrating platform is irrelevant and all requirements are imposed on the runner.</li> <li>The platform provides the runner with some credentials for generating the provenance or both the platform and the runner provide information for the provenance. Trust is shared between the platform and the runner so the requirements are imposed on both.</li> </ul> <p>Additional requirements on the self-hosted runners may be added to Build levels greater than L3 when such levels get defined.</p> <div class="mt-10 pt-10 border-t flex flex-col sm:flex-row space-between gap-5"> <a href="/spec/v1.0/principles" class="border rounded px-4 py-2 text-left">&lsaquo; Guiding principles</a> <a href="/spec/v1.0/future-directions" class="sm:ml-auto border rounded px-4 py-2 text-right">Future directions &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/faq.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>