Inferensys

Glossary

SLSA Framework

The SLSA (Supply-chain Levels for Software Artifacts) framework is a security specification providing a graded checklist of controls to prevent tampering and improve the integrity of software packages and build pipelines.
Supply chain manager using AI negotiator on laptop, supplier data visible, casual office afternoon setup.
SUPPLY CHAIN INTEGRITY

What is the SLSA Framework?

A security framework providing a graded checklist of controls to prevent tampering and improve the integrity of software packages and build pipelines.

The Supply-chain Levels for Software Artifacts (SLSA) framework is a systematic, tiered specification designed to protect software from source to deployment by mitigating threats like source tampering, compromised build platforms, and dependency confusion. Pronounced "salsa," it provides a common language and a measurable bar for increasing the integrity of software artifacts, moving organizations from basic provenance generation to hermetic, isolated builds with non-falsifiable attestations.

SLSA defines four ascending levels of security rigor. Level 1 requires automated provenance generation. Level 2 mandates version control and a hosted build service. Level 3 enforces isolated, non-falsifiable build environments with source and build integrity controls. The aspirational Level 4 demands hermetic, reproducible builds with two-person review, providing the highest degree of confidence that an artifact has not been tampered with, forming the backbone of a zero trust supply chain.

SUPPLY CHAIN INTEGRITY

Core Components of the SLSA Framework

The Supply-chain Levels for Software Artifacts (SLSA) framework is organized into a series of ascending tracks and levels, each providing progressively stronger defenses against specific tampering threats throughout the software lifecycle.

02

Build Level 1: Basic Provenance

The foundational level requires automated generation of provenance—a verifiable statement about how an artifact was built. This includes the build entry point, source materials, and build parameters. The provenance must be available for inspection but does not yet require cryptographic signing or tamper-proof storage. This level enables basic vulnerability management and inventory analysis.

03

Build Level 2: Signed Provenance

This level requires provenance to be cryptographically signed by a trusted build service. Key requirements include:

  • The build service must generate and sign the provenance
  • Consumers can verify the signature against a known identity
  • The signing key must be managed by the build service, not the user This prevents attackers from forging provenance metadata after a compromise.
04

Build Level 3: Hardened Builds

The highest level mandates a tamper-proof build environment with strong isolation and auditability. Requirements include:

  • Hermetic builds: No network access or undefined inputs during the build
  • Isolation: Build steps run in isolated containers or VMs
  • Reproducibility: Independent rebuilds produce bit-for-bit identical artifacts
  • Audit trails: All build steps are logged in a verifiable transparency ledger This level defends against sophisticated insider threats and compromised build infrastructure.
SLSA FRAMEWORK

Frequently Asked Questions

Clear, technical answers to the most common questions about the Supply-chain Levels for Software Artifacts framework, its implementation, and its role in securing AI pipelines.

The SLSA framework (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework that provides a graded checklist of controls to prevent tampering and improve the integrity of software packages and build pipelines. It works by defining four ascending levels of security maturity, from basic build automation to hermetic, fully attested builds with two-person reviews. Each level introduces stricter requirements around source integrity, build integrity, and provenance attestation. The framework is designed to be actionable and incremental, allowing organizations to progressively harden their supply chain against threats like source code injection, compromised build platforms, and dependency confusion attacks. SLSA achieves this by requiring cryptographic attestations that create a verifiable chain of custody from source code to the final artifact, enabling automated policy enforcement at deployment time.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.