Unverified Commit 56bf197d authored by Tom Hennen's avatar Tom Hennen Committed by GitHub
Browse files

Try to make linter happy.

parent 2f464c29
......@@ -4,7 +4,6 @@ These are some of the use cases for SLSA. Of these the first use case (a vendor
own packages prior to publishing) is the most ready for adoption as it does not require
interactions with any other party.
## Vendor publishing a software package
A vendor, BarInc, has the following goals in applying SLSA:
......@@ -36,21 +35,21 @@ A developer using BarImage wants to ensure it hasn't been tampered with before u
They could do this by:
1. Requesting BarInc to publish the
1. Requesting BarInc to publish the
[in-toto Provenance](https://github.com/in-toto/attestation/blob/main/spec/predicates/provenance.md)
and any additional attestations (such as
[source control attestations](https://github.com/in-toto/attestation/issues/47)) for BarImage
each time it is released.
2. Requesting BarInc to publish the public keys it's builder uses to sign the attestation.
* (TBD) [Determine how to convey these keys](https://github.com/slsa-framework/slsa/issues/101).
4. Requesting BarInc to confirm what SLSA level their builder and source control system meet.
* In the future there may be an accredidation body that confirm this _for_ BarInc.
5. Determining what policy to apply to BarImages
* They could create this policy on first use based on the data provided in the in-toto Provenance.
Any significant deviations (e.g. builder changed, source repo changed) would cause failure. OR
* BarInc could _publish_ a suggested policy for users of BarImage on their website.
- (TBD) [Determine how to convey these keys](https://github.com/slsa-framework/slsa/issues/101).
3. Requesting BarInc to confirm what SLSA level their builder and source control system meet.
- In the future there may be an accredidation body that confirm this _for_ BarInc.
4. Determining what policy to apply to BarImages
- They could create this policy on first use based on the data provided in the in-toto Provenance.
Any significant deviations (e.g. builder changed, source repo changed) would cause failure. OR
- BarInc could _publish_ a suggested policy for users of BarImage on their website.
5. Establish a secure choke-point that any uses of BarImage must pass through in order to be used.
* E.g. On import to a local Docker registry
- E.g. On import to a local Docker registry
6. Have the choke-point check the candiate BarImage against it's provenance, checking it against the
policy from #4.
7. Only import the container image if all the checks in #6 pass.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment