SLSA Knowledge Bundle
A LOKF knowledge base for SLSA. Every Markdown file under knowledge/ is one concept; together they form a queryable knowledge graph, derived from this repository’s code and docs.
| The root file declares | |
|---|---|
| Base IRI | https://w3id.org/lmodel/slsa/knowledge/ |
| JSON-LD context | https://w3id.org/lokf/context.jsonld |
| Licence | CC BY 4.0 |
| Publisher | Noel McLoughlin |
| Concepts | 19 |
How far it has been checked
Section titled “How far it has been checked”The bundle health page gives each concept’s label. The counts, computed from frontmatter when the site was built:
- Confirmed by a person: 0 of 19
- Checked by automation only: 17
- Nobody has checked: 2
- Drafts: 19
- Reopened: 0
- Past review date: 0
- Edited since confirmed: 0
- Retired: 0
- concepts.jsonld: every concept’s frontmatter and body under one JSON-LD context.
- graph.nt: the whole bundle as N-Triples.
- graph.json: the typed relations as cytoscape.js elements, which the knowledge graph draws.
- datasets.jsonld: a schema.org Dataset description for each Dataset or Table concept.
- index.md: the bundle’s root file, which declares the header above.
- log.xml: the bundle log as an Atom feed, its newest 20 days.
- previews.json: each concept’s title, type, genre, trust label and definition, which a link to the concept shows before it is followed.
- Each concept page links the concept’s own Markdown file and its JSON-LD, at the concept’s path with
.mdor.jsonldadded. - The bundle as it stood at each release is a zip on the releases page.
Contents
Section titled “Contents”Services
Section titled “Services”- slsa documentation site - The Astro Starlight site in
website/, built from the README,docs/, the schema’s gen-doc pages and the knowledge bundle by the Knowledge website workflow, which publishes it athttps://lmodel.github.io/slsa/onceKNOWLEDGE_WEBSITE_ENABLEDis true. ItsREDIRECTSsetting sends the retired mkdocs site’s page addresses, such as/elements/<name>, on to the new pages.
References
Section titled “References”- SLSA specification - Supply-chain Levels for Software Artifacts (SLSA), the OpenSSF specification of tracks and levels for supply chain security; the slsa LinkML schema renders version 1.2, its Build and Source tracks, and the working draft’s Dependency and Build Environment tracks.
- CNCF Secure Software Factory whitepaper - The CNCF TAG-Security Secure Software Factory whitepaper (2022), which describes a pipeline of version control, build service, artifact registry, signing service and policy engine; the schema’s slsa_ssf subset takes five slots from it.
- SLSA adoption study (Tamanna et al., 2024) - An empirical study by Tamanna et al. (2024, arXiv:2409.05014) of 1,523 SLSA-related GitHub issues from 233 repositories; the schema’s slsa_adoption module encodes its four challenge and five strategy themes as enums on SlsaAdoptionMetadata.
- OpenSSF Supply Chain Integrity Working Group - The OpenSSF Supply Chain Integrity Working Group, whose software supply chain projects include SLSA, Sigstore, GUAC, gittuf and Security Insights; the schema’s guac_uri and security_insights_uri slots point at GUAC and Security Insights.
- in-toto attestation framework - The in-toto attestation framework (spec v1), whose Statement, ResourceDescriptor and DigestSet layers carry SLSA provenance and verification summaries; the schema takes its InToto classes, InTotoPredicate and three field types from lmodel/in-toto’s core module at v0.1.0, vendored unchanged in src/slsa/schema/in_toto/, with every digest algorithm the DigestSet page lists.
Datasets
Section titled “Datasets”- slsa LinkML schema - The modular LinkML schema of the SLSA specification v1.2 (schema id
https://w3id.org/lmodel/slsa):slsa.yamlimports a core module and one module per track, predicate or study, covering the Build, Source, Dependency and Build Environment tracks; the core imports the in-toto statement layer from lmodel/in-toto’s vendored core module and adds SlsaStatement; itslokf adaptcopy in.lokf/slsa.yamlis the bundle’s domain schema. - SLSA specification copy - The SLSA specification’s Markdown pages, images and provenance schemas (.proto, .cue) copied into
src/slsa/schema/spec/: all 39 files are identical todocs/spec/draft/at SLSA tag v1.2, and a weekly workflow watches for a newer release. - Generated artifacts - Files generated from the slsa schema and never edited by hand, committed or git-ignored: the two merged schemas in docs/schema/, the Python data models, project/ (JSON Schema, OWL, SHACL, Java and more), docs/elements/ and the bundle’s domain schema .lokf/slsa.yaml, which a release also attaches as its schema asset.
- Test data - Example YAML instances of the slsa schema in tests/data/, valid and invalid, named ClassName-###.yaml after the class they instantiate (SlsaStatement, InTotoDigestSet, SlsaBuildPlatform and the rest); pytest and linkml-run-examples check them.
Explanations
Section titled “Explanations”- Schema subsets - Why the slsa schema tags its elements with six subsets (one per SLSA track: Build, Source, Dependency and Build Environment, plus slsa_ssf and slsa_adoption_study for what two outside sources add), and what each subset covers.
Glossary
Section titled “Glossary”- SLSA track - A SLSA track focuses on one aspect of a software supply chain (Build, Source, Dependency or Build Environment), with its own levels, threats and requirements; the schema gives each track a subset and a level enum.
- SLSA level - A rung within a SLSA track, such as Build L2 or Source L3; higher levels give better guarantees against supply chain threats at a higher cost to implement. The schema names them in its four level enums, such as SlsaBuildLevel.
Playbooks
Section titled “Playbooks”- Regenerate and test the schema - How to change the slsa schema and its modules, regenerate the artifacts, the docs and the bundle’s domain schema with just (gen-project, gen-doc, gen-merged, lokf-adapt), then run the checks CI runs: just test on Python 3.10 to 3.14, and just lint and just lokf-adapt-check on 3.13.
- Release the slsa package - How a releasing commit merged to main makes semantic-release promote the changelog, tag vX.Y.Z and publish a GitHub Release, and how pypi-publish.yaml then publishes slsa-linkml to PyPI once PYPI_RELEASE_ENABLED is true.
- Knowledge sources map - The librarian’s scrape map: every repository location and external URL this bundle derives concepts from, and how to re-verify each on a refresh run.
- SLSA project (OpenSSF) - The OpenSSF project that publishes the SLSA specification from the slsa-framework/slsa repository, governed by a steering committee and licensed under the Community Specification License 1.0.
- CNCF TAG-Security - The CNCF Security Technical Advisory Group, publisher of the Secure Software Factory whitepaper from its cncf/tag-security repository (now archived), which licenses its documentation under CC BY 4.0.
Policies
Section titled “Policies”- License and attribution - Which license covers what in the slsa repository: Apache-2.0 for the schema and code, the SLSA specification copy under the Community Specification License 1.0 (older portions Apache-2.0) with its name, version and source given in NOTICE, the whitepaper under CC BY 4.0, lmodel/in-toto’s vendored core module under Apache-2.0, and what else NOTICE lists.