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.
Glossary
SLSA Framework

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.
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.
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.
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.
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.
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.
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.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
The SLSA framework operates within a broader ecosystem of tools and standards designed to cryptographically attest to software integrity. These related concepts form the technical foundation for implementing tamper-proof build pipelines.
Software Bill of Materials (SBOM)
A formal, machine-readable inventory of every component, library, and dependency within a software artifact. SBOMs provide the ingredient list that SLSA provenance attestations reference.
- Formats include SPDX and CycloneDX
- Enables precise vulnerability mapping when new CVEs are disclosed
- Required by U.S. Executive Order 14028 for federal software suppliers
Reproducible Builds
A deterministic compilation process where independent parties can recreate a bit-for-bit identical artifact from the same source code. This verifies that no tampering occurred during the build.
- Critical for achieving SLSA Level 4 (highest assurance)
- Requires hermetic build environments with no network access
- Eliminates reliance on trusting a single builder's output
Binary Authorization
A deploy-time security control that enforces strict policy checks before execution. It requires a valid cryptographic signature from a trusted authority before a container image can run in production.
- Integrates with Kubernetes admission controllers
- Enforces SLSA provenance verification at the deployment gate
- Prevents unsigned or tampered artifacts from reaching runtime

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us