SLSA vs Makoto

Makoto is a sibling framework to SLSA, not an extension. While SLSA secures the software supply chain, Makoto addresses the fundamentally different challenges of data supply chains. Both frameworks share a common philosophy: progressive security levels, attestation-based verification, and threat-focused design.

Complementary, not competing: Organizations securing both code and data can use SLSA for software artifacts and Makoto for data artifacts. Both use the same attestation format (in-toto/DSSE) and level philosophy.

Concept Mapping

SLSA Concept	Makoto Equivalent	Key Difference
Software Artifact	Data Artifact	Data includes streams and batches, not just files
Build	Transform	Data has multi-stage ETL, not single build step
Source	Origin	Data sources may be external APIs, sensors, humans
SBOM	DBOM	DBOM tracks transformation chain, not dependencies
Build Provenance	Origin + Transform Provenance	Data needs separate attestation types per stage
Builder	Collector / Executor	Separated roles for ingestion vs processing

Why Data Needs Its Own Framework

Data pipelines differ from software builds in fundamental ways. These differences require different attestation types, different threat models, and different verification approaches.

Characteristic Comparison

Dimension	Software (SLSA)	Data (Makoto)
Artifact Type	Discrete builds (binaries, packages)	Continuous streams AND large batches
Transformations	Single build step	Multi-stage ETL pipelines (N stages)
Granularity	File or package level	Record, row, window, table, or dataset
Privacy	Generally public metadata	May contain PII, requires privacy controls
Velocity	Per-release (hours to days)	Millions of events per second
Lineage Depth	Source → Binary	Source → T₁ → T₂ → ... → Tₙ
Reproducibility	Often reproducible	Often non-reproducible (time-dependent)

Data-Specific Challenges

Streaming Scale

Attesting millions of records per second requires different approaches than per-build attestation. Makoto introduces window-based Merkle tree attestations.

Privacy Requirements

Data attestations must not leak sensitive information. Makoto supports privacy-preserving techniques like aggregate proofs and blinded hashes.

Transform Chains

Data passes through many transformations. Each stage needs its own attestation with hash chaining to prove lineage integrity.

Level Comparison

Both frameworks use three progressive levels with similar philosophies but different requirements.

Level	SLSA	Makoto
L1	Provenance Exists Build provenance generated by hosted build platform	Provenance Exists Origin + transform attestations in Makoto schema
L2	Authenticated Provenance Signed provenance from authenticated build service	Provenance is Authentic Signed attestations with hash chaining between stages
L3	Hardened Build Isolated build environment, ephemeral credentials	Provenance is Unforgeable Platform-generated attestations, HSM/TEE signing

Key Level Differences

L1: SLSA requires hosted build; Makoto allows any attestation producer
L2: Makoto adds hash chaining between transform stages (not in SLSA)
L3: Both require isolation, but Makoto emphasizes platform-level attestation generation

Threat Model Comparison

Makoto extends SLSA's threat model with data-specific threats:

SLSA Threat	Makoto Equivalent	Data-Specific Considerations
(A) Submit unauthorized change	D1: Source Falsification	Data sources may be external APIs, not just repos
(B) Compromise source repo	D2: Collection Tampering	Data can be modified during ingestion
(E) Compromise build process	D3: Transform Opacity	Multi-stage transforms need per-stage attestation
(F) Upload modified package	D4: Lineage Forgery	Fabricating data history across transform chain
—	D5: Stream Injection	New: Inserting records into streams
—	D6: Aggregation Manipulation	New: Tampering with computed statistics
—	D7: Privacy Leakage	New: Attestation metadata exposing PII
—	D8: Time Manipulation	New: Backdating or falsifying timestamps

Attestation Format Compatibility

Both SLSA and Makoto use the in-toto attestation framework. This means attestations from both frameworks can be:

Stored in the same attestation registries
Verified using the same signature verification tools
Combined in unified verification policies

SLSA Build Provenance

{
  "_type": "https://in-toto.io/Statement/v1",
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {...},
    "runDetails": {...}
  }
}

Makoto Origin Attestation

{
  "_type": "https://in-toto.io/Statement/v1",
  "predicateType": "https://makoto.dev/origin/v1",
  "predicate": {
    "origin": {...},
    "collector": {...}
  }
}

Predicate Types

Framework	Predicate Type	Purpose
SLSA	`slsa.dev/provenance/v1`	Software build provenance
Makoto	`makoto.dev/origin/v1`	Data origin/collection
Makoto	`makoto.dev/transform/v1`	Data transformation
Makoto	`makoto.dev/stream-window/v1`	Stream window attestation

When to Use Each Framework

Use SLSA for...

Container image builds
Package publishing (npm, PyPI, etc.)
Binary compilation
CI/CD pipeline artifacts
Infrastructure-as-code deployments

Use Makoto for...

ETL pipeline outputs
ML training datasets
Real-time streaming data
Data warehouse tables
Analytics and reporting data

Use Both When...

Many organizations need both frameworks. For example, an ML pipeline might use:

SLSA for the training code and model binary
Makoto for the training data and feature datasets

The attestations can be stored together and verified as a combined provenance chain, proving both the software and data integrity of the final model.

Summary

Aspect	SLSA	Makoto
Focus	Software supply chain	Data supply chain
Primary artifact	Build outputs (binaries, packages)	Data outputs (datasets, streams)
Provenance type	Build provenance	Origin + Transform provenance
Scale	Per-build	Per-record to per-window
Privacy	Generally public	Privacy-preserving options
Output artifact	SBOM	DBOM
Attestation format	in-toto/DSSE	in-toto/DSSE (compatible)

Learn about Makoto Levels → | Learn about SLSA →