Supply-chain Levels for Software Artifacts (LinkML)
Only want to ask? Install
ktl-docentinto any agent you use, by a route from the install page, and ask it about this project. It answers from the bundle and says how far each answer has been checked.Agents: if
.lokf/knowledge/index.mdexists, read it first.llms.txtsays how to weigh it.
The SLSA specification, version 1.2: the Build and Source tracks, the build provenance and Verification Summary Attestation predicates, and the roles, build platform and package model. The in-toto statement layer they sit in comes from lmodel/in-toto's core module, vendored in src/slsa/schema/in_toto/. The Dependency and Build Environment tracks follow the working draft at 1.2. The schema's version is 1.2.0, the copy in src/slsa/schema/spec/ matches the v1.2 tag, and a weekly workflow opens an issue when the SLSA Working Group tags a newer version.
Two sources add elements of their own, each in a subset: the CNCF Secure Software Factory whitepaper (slsa_ssf) and the SLSA adoption study by Tamanna et al. (slsa_adoption_study). docs/about.md says what each adds.
None. The schema declares no mappings to other vocabularies.
- docs/: the documentation pages the website shows
- elements/: generated schema documentation
- examples/: examples of using the schema
- project/: project files (these files are auto-generated, do not edit)
- src/: source files (edit these)
- slsa
- schema/: the LinkML schema,
slsa.yamland the modules it imports (edit these) - datamodel/: generated Python datamodel
- schema/: the LinkML schema,
- slsa
- tests/: Python tests
- data/: example data
- website/: the documentation website, an Astro Starlight site built from the README,
docs/, the schema's pages and the knowledge bundle
Several pre-defined command-recipes are available using just. To see the list, run just or just --list.
.lokf/ holds this project's KTL knowledge bundle. Its domain schema is .lokf/slsa.yaml, a copy that lokf adapt wrote from src/slsa/schema/slsa.yaml. Edit the source, never the copy.
just lokf-adapt rewrites the copy and just lokf-adapt-check says when it is stale; project.justfile says which classes the copy roots on Concept. A concept may name any of them, or a subclass, as its type. Obsidian users of the KTL Registrar and KTL Curator plugins should add them to the Known LOKF types setting:
SlsaProducer, SlsaConsumer, SlsaVerifier, SlsaInfrastructureProvider, SlsaBuildImageProducer, SlsaBuildPlatform, SlsaControlPlane, SlsaPackage, SlsaPackageRegistry, SlsaSourceControlSystem, SlsaSourceRepository, SlsaSourceRevision, SlsaBuildImage
In the copy, LOKF's id stands in for each class's own identifier (builder_id, repository_uri and the like), so a concept writes id. Two slots are renamed in the copy, because LOKF 0.9.0 defines slots of the same names: revision is slsa_revision, with its IRI still slsa:revision, and a statement's predicate is slsa_predicate, with in-toto's IRI. A slsa document keeps both keys. Every other key keeps its name, because no other top-level class, slot, enum or type in the schema has a name that lokf.yaml defines. lokf adapt does not compare class attributes, so media_type keeps the name it shares with a LOKF slot, and takes that slot's IRI, dcat:mediaType.
The schema and the code are under the Apache License 2.0 (LICENSE).
The repository also carries the specification's pages in src/slsa/schema/spec/ and the CNCF Secure Software Factory whitepaper in docs/, each under its own license. See NOTICE.
This is not an official SLSA release, and its use does not imply endorsement by the SLSA Working Group, OpenSSF or the CNCF.
CONTRIBUTING.md is the checklist for a pull request and for releasing. AI_COVENANT.md sets the rules for AI-assisted work. SECURITY.md says how to report a vulnerability. CHANGELOG.md records the changes.
This project uses the template linkml-project-copier published as doi:10.5281/zenodo.15163584.