SLSA Conformance - Kris Kooi, Google  ## Metadata - Author: [[OpenSSF]] - Full Title: SLSA Conformance - Kris Kooi, Google - Category: #articles - Document Note: --- tags: [#supply-chain-security, #slsa, #opensource] - #supply-chain-security - #slsa - #opensource Author: Kris Kooi Source: OpenSSF / Google Reference: [SLSA Conformance - Kris Kooi, Google](https://www.youtube.com/watch?v=NXOVAtCov-E) date created: 2025-08-22 23:59 --- # Title: SLSA Conformance and Supply Chain Security – Kris Kooi’s Proposal for Trust and Transparency ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: Kris Kooi (Google, OpenSSF) explains the **SLSA (Supply Chain Levels for Software Artifacts)** framework and its upcoming **conformance program**. The framework provides tiered levels of trust in software build pipelines, addressing vulnerabilities in provenance and integrity. Kooi proposes a **two-tier conformance system**: - **Tier One**: Community questionnaires, self-attestation, transparency commitments. - **Tier Two**: External auditor verification and mandatory public reports. The goal: strengthen trust in software supply chains by introducing **badges** and standardized proof of compliance, ensuring OSS build systems meet high security standards. --- ## 📖 Main Content: SLSA defines a multi-level framework to **secure software supply chains**. - **Level One**: Documentation of provenance; still vulnerable to manipulation. - **Level Two**: Trusted build platform separates producers from provenance creators. - **Level Three**: Stronger guarantees against multi-tenant interference. Kooi argues that higher levels deserve **auditor involvement** to prevent blind trust in build platforms. The **conformance program** gives organizations badges, signaling compliance and transparency. External auditors’ mandatory publication of audit results adds **accountability**. --- ### 🗒️ Notes - [00:06](https://www.youtube.com/watch?v=NXOVAtCov-E&t=6): Kooi introduces SLSA, credits Red Hat collaborator Josh Malkin. - [01:03](https://www.youtube.com/watch?v=NXOVAtCov-E&t=63): SLSA framework tracks improvements in supply chain posture. - [02:03](https://www.youtube.com/watch?v=NXOVAtCov-E&t=123): Build process: source → dependencies → package + provenance metadata. - [03:08](https://www.youtube.com/watch?v=NXOVAtCov-E&t=188): Conformance badges ensure compliance with specs. - [04:01](https://www.youtube.com/watch?v=NXOVAtCov-E&t=241): Higher levels reduce attack surface, enforce provenance trust. - [04:57](https://www.youtube.com/watch?v=NXOVAtCov-E&t=297): Tier One: questionnaires, community registry, vulnerability disclosure commitments. - [05:57](https://www.youtube.com/watch?v=NXOVAtCov-E&t=357): Tier Two: auditors publish audit procedures and results; prevents hiding bad audits. - [06:55](https://www.youtube.com/watch?v=NXOVAtCov-E&t=415): Participation info at salsa.dev; proposal #5 outlines program structure. --- ## 📖 References: - OpenSSF: [slsa.dev](https://slsa.dev) - Kooi, K. (Google), SLSA Proposal #5 (GitHub: salsa-framework/salsa-proposals) - OpenSSF Slack: #salsa --- ## 🗣️ Paraphrase: 1. Original: *“At level three you have guarantees that multi-tenant systems can’t interfere with your build or provenance.”* Paraphrase: At SLSA Level 3, safeguards ensure that other builds in shared environments cannot alter your build results or provenance. 2. Original: *“External auditors must publish reports even if organizations dislike the results.”* Paraphrase: To maintain trust, auditors are required to release all reports publicly, regardless of whether the findings reflect poorly on the audited platform. --- ## 📰 Newsletter: 🛡️ **Supply Chain Security Gets a Badge System** Google’s Kris Kooi just pitched a conformance program for **SLSA (Supply Chain Levels for Software Artifacts)**. Imagine WordPress plugin repos showing **security badges** earned through external audits—exactly what’s coming to broader OSS ecosystems. The system has two tiers: self-attested questionnaires (tier one) and **audited, public reports (tier two)**. The idea is simple: you can’t buy silence, and audits must be transparent. For developers, this sets the stage for **trustworthy builds** and reproducible supply chains. Full details: [slsa.dev](https://slsa.dev) --- ## ✅ Action Items: - Apply SLSA principles to **WordPress plugin/theme repos** for provenance tracking. - Advocate for **external audit publishing policies** within WordPress.org. - Integrate SLSA-style compliance into **GoDaddy’s OSPO** roadmap. - Educate contributors on **supply chain security** basics via workshops. - Align with career path → OSPO director: tie supply chain trust frameworks into **corporate risk strategy**. --- ## 🧪 Hypotheses: - H1: Auditor-enforced conformance improves trust in OSS ecosystems. - H2: Public audit registries increase adoption of secure build practices. - H3: SLSA-style badges reduce dependency risk in large projects (e.g., WordPress). ### 📊 Methodology: - Run controlled adoption pilots in plugin repos. - Survey developer trust before/after badges introduced. - Analyze incident frequency post-conformance adoption. ### ❓ Questions: - Would **WordPress.org plugins** adopt a conformance badge system? - How do OSS projects balance **audit costs** vs security gains? - Could SLSA badges become a **requirement for enterprise adoption**? ### 🔮 Future Research: - Comparative studies of **badge-based vs trust-based ecosystems**. - Impact of public audits on **developer reputation economies**. - Case studies on **multi-tenant cloud build interference risks**. ### 💡 Implications: - Raises the bar for OSS security across ecosystems. - Empowers OSPOs to **set minimum compliance standards**. - May become a baseline for **procurement and regulatory frameworks**. --- ## 🧠 Learning Styles Assessment: - **Visual**: Strong diagrams in slides; registry model could use more visuals. - **Aural**: Delivered as a talk; no audio recap available afterward. - **Verbal**: Clear analogies (badges, stickers) aid understanding. - **Kinesthetic**: No hands-on demo; suggest mock audits for practice. - **Logical**: Heavily structured reasoning, tiered systems. - **Social**: Encourages community participation in registries. - **Solitary**: Reflection prompts absent; could add checklists. - **Naturalistic**: No natural analogies; could compare to ecosystems’ interdependence. --- ## 📊 Accessibility Assessment: - Transcript available ✅. - Presentation slides lacked alt-text ❌. - Improve contrast + font scaling for legibility. - Ensure registry website (slsa.dev) meets WCAG standards. --- ## 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: - **Cultural Relevance**: Limited; framed mostly in Western OSS contexts. - **Inclusive Language**: Neutral, technical; jargon may alienate newcomers. - **Neurodiversity**: Structured clearly but could add simplified guides. - **Representation**: Example use cases lack diversity of projects (focused on infra). - **Psychological Safety**: Encourages transparency; risks punitive framing of audits. --- ## ✅ Logical Validity: - **Strengths**: - Deductive reasoning: higher SLSA levels → stronger trust. - Causal reasoning: external auditors prevent concealment. - Consistent analogies: “badges” = visible proof. - **Weaknesses**: - Slight **appeal to authority**: assumes OpenSSF standards universally applica - Summary: The article discusses Salsa, a supply chain security specification that has different tracks and levels for supply chain security. The proposal is to create an official Salsa conformance program to ensure software meets the Salsa specification. The program will involve two tiers and an external auditor for the second tier. The article explains how the program will work and how individuals can get involved. - URL: https://youtube.com/watch?v=NXOVAtCov-E&feature=share we are going to talk about salsa a wordthat I is near and dear to my heart wehave Chris cool he's a software engineerfrom Google'she focuses on supply chain security andis Joshua heresaid trombone you just have Chris who'sawesome take it away sirI mean I hope it's not just Chris butyeah uh Josh wasn't able to make ittoday but uh Josh Malkin from Red Hat was has beenum a great collaborator through thishe's been critical to the projectum so my name is is Chris uh Qui if itmattersum and I am a member of Google's opensource security team where I've beencontributing to the salsa specificationfor around six monthsum today I'm here to talk to you aboutuh a proposal for standing up anofficial salsa conformance program just to make sure we're all on the samepagewhat is salsasalsa stands for supply chain levels forsoftware artifacts and it is an open ssfprojectuh it's a supply chain securityspecification it's a it consists of aframework with different tracks andlevels for looking at different aspectsof the supply chain and reasoning aboutand then tracking improvements in your security posture in each of themso what problem does salsa solveum this is Salsa's model of the softwaresupply chain you start with a producerwho's a person or a group of peoplethinking OSS project or a companyand they they write some Source it'sprobably source code but in salsa Worldit doesn't actually have to be it's justanything that is written or reviewed bya human uh you feed the source into a build toproduce a packageas part of the build it will resolvedependencies well what is the build thebuild is the process that turns Sourceinto packageit can be anything it can be involvedcompilation or it can just be tarring upa source code dependencies are anythingin the build that is not the source it'salmost always other packages and thepackage is whatever you whatever the consumer uses at the endum in addition to the package it's notin this diagram sorry uh the build alsoproduces a bundle of metadata which isknown as provenance which explains wherethe package came from and how it wasbuiltso what is a conformance programum it's a fancy way to give out stickersum so uh glibly it's a program for saying that a particular either SoftwareSystem or servicemeets or conforms with a specificationin this case it would be the salsaspecification and uhyeah if you put if you participate inthis program your software could getcould get a badge that hopefully looks alittle better than this oneso why does salsa need a conformance programum without going to too much detail ithas to do with how the build levels areput togetherso at build level one you really justget documentation in the provenance youstill have to trust the whole supplychain anyone can mess with you at anytimeat level two and I should say this is azoom in on the hexagon in the middle ofthe the build slide uh here you're onlytrusting the build step uh you know thatthe build is performed by someone other than the producer who then creates theprovenancewhich means that there are fewer peoplewho can mess with the provenanceand then at build level three you haveguarantees about the build saying thatfor example other builds happening in amulti-tenant system could not mess withyour build or your provenancethe trick here is that the trust routebetween levels two and level two and threeis still the build platform where thethe organization that maintains or runsitand I think that stronger guaranteesfrom a higher salsa level deservestronger proofand that's why I think we should add anauditor into the into the fold so youyou don't just trust the build platformat level three you also trust someexternal auditorso how would this program work we have one trick at Salsa and that islevelssoum it would start as a two-tiered systemuh the the goal being that over timetier uh we're not calling them levelsbecause over time hopefullytier one is less used because tier oneis sort of like salsa build level oneit's just documentationum the community maintains a questionnaire that is derived from thesalsa specification of what a salsaconformant build platform looks likeand the build platform will answer thosequestions and provide whatever evidencethey they think is also necessary andpublish it to a registry run by thesalsa Community or perhaps the open ssfthey'll also make a public commitment tovulnerability disclosures that wouldimpact the the security of their buildsystemum they commit to keeping it up to date and then they sign some terms andconditions and they get a badgebut tier two is where things getinteresting because now is a two-stepprocedure that involves an externalauditorthe first step is done by the auditorthey publish their audit procedure tothe registryand they make a public uhcommitment that every audit they perform will also be published to the registryeven if the organization being auditeddoesn't like itand they acknowledge that should they becaught hiding audit reports for whateverreason we'll kick them out of theprogram that's how we build trust in theAuditors if you can pay someone not totell the world that your build system isbad they should not be trustedstep two involves both the auditor andthe build platformit's the audit and then the Public Public excuse me publishing the auditreportand then you get a badge maybe this timethe badge has the auditor's logo on it Idon't knowsohow can you all get involved uh the thedefinitive resource for all things salsaincluding how to participate issalsa.devthe particular conformance proposal thatJosh and I have been working on is salsa proposal number five in salsa frameworkslash salsa proposalsotherwise come to a meeting find meafterwards or as always go to theopenssf slack hashtag salsathank you for your timeforeign, SLSA Conformance - Kris Kooi, Google, OpenSSF, 01h1n064wj0yn9884brj8y35z0.