The Supply-chain Levels for Software Artifacts (SLSA) framework started out as a specification of levels of potential security assurance from producers. Through the lens of software supply chain threats related to source integrity, build integrity, and distribution robustness, the SLSA framework currently offers four build levels ranging from “no guarantees” (Build L0) through “hardened builds” (Build L3) and four source levels ranging from a mere “uses version control” (Source L1) through “code review required” (Source L4).

In many ways reading the framework one sees what should be nearly baseline expectations for security and quality. In the real world though, resourcing and technical nuance leave the state of the art in a place where the higher level assurances are less common in industry than is desirable.

Also troubling is that the early versions of SLSA left “dependencies” untreated. The reality is that most any project is not just an exercise in production, but is also consuming dependencies from elsewhere.

The Secure Supply Chain Consumption Framework (S2C2F) was published at a similar time to SLSA’s emergence and specifies levels of potential security assurance consumers should apply when acquiring OSS dependencies from producers.

The S2C2F framework splits its quality controls into eight areas of practice spanning ingestion, audits and updates, rebuilding, and ongoing vulnerability management. Similar to SLSA, within these practice areas are four levels corresponding to the maturity of a software engineering team, from basic Level 1 through a robust Level 4 which is perhaps an aspirational target for many teams.

SLSA and S2C2F form a useful continuum, a pair of bookends between which a quality software engineering practice can anchor itself. Their separation was perhaps awkward given most producers are consumers and the dependency gap in SLSA 1.x. This should resolve going forward as S2C2F is tracking to morph into SLSA’s dependency track.

SLSA and S2C2F also map reasonably well to other frameworks such as NIST’s Secure Software Development Framework (SSDF) and Security and Privacy Controls for Information Systems and Organizations (SP 800-53). The NIST standards technically don’t truly aim to cover OSS and the mapping may be challenging for those unfamiliar with the intricate details of OSS community development and especially for entities which consume OSS without some type of support plan. It is nevertheless possible to rationalize these as an interrelated set of quality controls across the software delivery lifecycle.

Is your organization struggling with formalizing quality controls or in need of assistance analyzing OSS compliance requirements relative to specifications written with more traditional software in mind? Reach out for a conversation….