Although it’s tempting to attempt to set up a single customary for use SLSA, it’s not doable: SLSA isn’t a line dance the place everybody does the identical strikes, on the identical time, to the identical tune. It’s a diversified system with totally different types, strikes, and prospers. The open supply neighborhood, organizations, and shoppers could all implement SLSA otherwise, however they will nonetheless work with one another.
On this three-part sequence, we’ll discover how three fictional organizations would apply SLSA to satisfy their totally different wants. In doing so, we’ll reply a few of the important questions that newcomers to SLSA have:
Half 1: The fundamentals
- How and when do you confirm a package deal with SLSA?
- deal with artifacts with out provenance?
Half 2: The main points
- The place is the provenance saved?
- The place is the suitable coverage saved and who ought to confirm it?
- What ought to the insurance policies test?
- How do you identify belief & distribute keys?
Half 3: Placing all of it collectively
- What does a safe, heterogeneous provide chain appear to be?
Our fictional instance includes three organizations that need to use SLSA:
Squirrel: a package deal supervisor with numerous builders and customers
Oppy: an open supply working system with an enterprise distribution
Acme: a mid sized enterprise.
Squirrel desires to make SLSA as straightforward for his or her customers as doable, even when which means abstracting some particulars away. In the meantime, Oppy doesn’t need to summary something away from their customers beneath the philosophy that they need to explicitly perceive precisely what they’re consuming.
Acme is attempting to provide a container picture that incorporates three artifacts:
- The Squirrel package deal ‘foo’
- The Oppy package deal ‘baz’
- A customized executable, ‘bar’, written by Acme staff
This sequence demonstrates one strategy to utilizing SLSA that lets Acme confirm the Squirrel and Oppy packages ‘foo’ and ‘baz’ and its prospects confirm the container picture. Although not each recommended resolution is ideal, the options described could be a place to begin for dialogue and a basis for brand spanking new options.
Squirrel, Oppy, and Acme will comply with the same qualification course of for the supply management methods they plan to help.
In some unspecified time in the future, a number of of the organizations might want to do full verification of every artifact to find out whether it is acceptable for a given use case. That is completed by checking if the artifact meets the suitable coverage.
Sometimes, full verification would happen with SLSA provenance, supply attestations, and maybe different specialised attestations (like vulnerability scan outcomes). Whereas having to coordinate this knowledge for all of its dependencies looks like a number of work to Acme, they’re ready to do full verification if Squirrel and Oppy are unable to.
When Acme isn’t utilizing full verification, they will as an alternative use delegated verification the place they test if an artifact is suitable for a use case by checking if another trusted get together who carried out a full verification (comparable to Squirrel or Oppy) believes the artifact is suitable.
Delegated verification is simpler to carry out rapidly with restricted knowledge and community connectivity. It might even be simpler for some customers who worth if somebody they belief verified the artifact is sweet.
Squirrel likes how straightforward delegated verification would make issues for his or her customers and plans to help it by making a Verification Abstract Attestation (VSA) once they carry out full verification.
Verification (full or delegated) may occur at a variety of totally different occasions.
Squirrel plans to carry out full verification when an artifact is revealed to their repo. It will be sure that packages within the repo have met their corresponding coverage. It’s additionally useful as a result of all of the required knowledge could be gathered when latency isn’t essential.
If this have been the one time verification is carried out, it could put the repository’s storage within the trusted computing base (TCB) of its customers. Squirrel’s plans to make use of delegated verification (and problem VSAs) can stop this. The signature on the VSA will stop the artifacts from being tampered with whereas sitting in storage, even when they’re simply SLSA 0. Downstream customers will simply have to confirm the VSA.
Acme additionally desires to do some type of verification on the import to their inner repo because it simplifies their safety story. They’re not fairly certain what it will appear to be but.
Acme additionally desires to do verification when an artifact is definitely put in since it could take away a variety of intermediaries from their TCB (their repo, the community, upstream storage methods).
In the event that they carry out full verification at set up then they have to collect all of the required data. That may very well be a number of knowledge, but it surely is likely to be simplified by gathering the information from exterior sources and caching it of their inner repo. A bigger downside is that it requires Acme to have established belief in all events that produced that data (e.g. each builder of each package deal). For a fancy provide chain that could be troublesome.
If Acme performs delegated verification, they solely want the VSA for the packages being put in and to explicitly belief a handful of events. This permits the complicated full verification to be carried out as soon as whereas permitting all customers of that package deal to carry out a a lot less complicated operation.
Given these tradeoffs Acme prefers delegated verification at set up time. Squirrel additionally actually likes the concept and plans to construct set up time verification instantly into the Squirrel instrument.
On use
Time of use verification permits probably the most context with which choices could be made (“is that this job allowed to run this code and is it free from vulns proper now?”). It additionally permits coverage adjustments to have an effect on already constructed & put in software program (which can or will not be fascinating).
Acme desires their customers to have the ability to confirm on use with out too many dependencies in order that they plan to offer VSAs customers can use to carry out delegated verification once they begin the container (maybe utilizing one thing like Kyverno).
Such an artifact would possible not be accepted at larger SLSA ranges, however the provenance can be utilized to: 1) stop tampering with the artifact after it’s been imported and a pair of) be an information level for future evaluation (e.g. ought to we prioritize asking for foo.tgz to be distributed with native SLSA provenance?).
Acme is likely to be concerned about taking this strategy in some unspecified time in the future, however they don’t want it in the intervening time.
In our subsequent submit we’ll cowl particular approaches that can be utilized to reply questions like “the place ought to attestations and insurance policies be saved?” and “how do I belief the attestations that I obtain?”
