Supply-chain Levels for Software Artifacts
OpenSSF framework defining progressive levels of build-system integrity for software supply chain security, focused on tamper-resistance of the build.
Definition
SLSA, Supply-chain Levels for Software Artifacts, is an industry-consensus software supply-chain security specification. Version 1.2 separates Build and Source tracks. Build levels L1, L2 and L3 progress from provenance availability to hosted-build authenticated provenance and hardened build-platform protections. The former four-level model, including Build Level 4, is obsolete.What this means in practice
SBOMs identify components; provenance records build origins and inputs. Verify provenance against trusted expectations. Neither proves the source is benign or prevents every upstream compromise, including attacks involving malicious authorized source changes.Examples
- Illustrative: A medical device manufacturer achieves SLSA Level 2 for their firmware build process by using a cloud-hosted build service that automatically generates and signs provenance attestations for each release.
- Illustrative: During a pre-market submission, a medical device developer includes SLSA Level 3 attestations for critical software components, demonstrating that the code was built in a hardened, tamper-resistant environment.
- Illustrative: A hospital requests and verifies supplier provenance against trusted build expectations, while separately assessing component security.
- •Equating SBOM with supply-chain security, without provenance, an SBOM can be fabricated.
- •Choose a track and version before setting a target. Start with Build L1 provenance and progress toward L2 or L3 as appropriate, rather than targeting obsolete Build L4.
- •Ignoring third-party SLSA provenance when selecting components, the framework's value compounds when consumed and produced.
Frequently asked questions
Related terms
Grouped by themeEditor's picks
· Hand-selected related conceptsA lightweight, OWASP-maintained SBOM format designed for application security and supply-chain use cases.
A documented, risk-based set of processes that build cybersecurity into a medical device across its full lifecycle.
NIST SP 800-218, a framework of secure software development practices that is referenced by EO 14028 and increasingly by medical device guidance.
An inventory of software components and dependencies used in a device, supporting vulnerability management and supply-chain transparency.
More in Cybersecurity
· Same categoryAn open SBOM and license-data format published as ISO/IEC 5962:2021.
A machine-readable statement that explains whether a known vulnerability is actually exploitable in a specific product.
AAMI/ANSI standard establishing requirements for medical-device cybersecurity activities throughout the lifecycle.
AAMI Technical Information Report providing MedTech-specific guidance on cybersecurity risk management.
Where this term appears across MedTech Terms.
Latest in MedTech
Sources
5 sourcesSources support the definition or relevant regulatory context, not necessarily every claim on this page. Each is graded against our source-tier hierarchy so you can see what rests on binding law versus commentary.
Official-source claim check:
SLSA v1.2 uses separate Build and Source tracks, not the legacy four-level model.
Partial review: verified corrections are applied, but this is not a full accuracy certification. The last full review date is unchanged.
Remaining verification limits
- Secondary regulatory, standards-clause, market-prevalence or procurement claims were not fully substantiated by accessible original text.
- 1SLSA SpecificationTier 2 VerifiedOpenSSFslsa.dev
- 2CISA - Healthcare and Public Health SectorTier 2 VerifiedCISAcisa.gov
- 3FDA - Cybersecurity for Medical DevicesTier 2 VerifiedFDAfda.gov
- 4SLSA v1.2Tier 2 UncheckedOpenSSFslsa.dev
- 5SLSA tracksTier 2 UncheckedOpenSSFslsa.dev
Inline markers like [1] jump to the matching reference above.