|
| 1 | +# Use Cases |
| 2 | + |
| 3 | +These are some of the use cases for SLSA. Of these the first use case (a developer checking |
| 4 | +their own packages prior to publishing) is the most ready for adoption as it does not require |
| 5 | +interactions with any other party. |
| 6 | + |
| 7 | +## Developer publishing a software package |
| 8 | + |
| 9 | +A developer, BarInc, has the following goals in applying SLSA: |
| 10 | + |
| 11 | +1. Protect their users from malicious changes to the BarImage container image. |
| 12 | +2. Protect their reputation, which would be harmed, if BarImage were compromised. |
| 13 | +3. Access to metadata for auditing and ad-hoc analysis. |
| 14 | + |
| 15 | +BarInc can acheive these goals when publishing the container image by: |
| 16 | + |
| 17 | +1. Upgrading their source control systems to meet higher SLSA levels. |
| 18 | +2. Upgrading their build system to meet higher SLSA levels. |
| 19 | +3. Ensuring BarImage **MUST** go through a secure control-point in order to be published. |
| 20 | +4. Having the control-point check the candidate BarImage against its provenance, checking: |
| 21 | + 1. That the expected builder created it. |
| 22 | + 2. That the builder meets some minimum SLSA level. |
| 23 | + 3. That the source repos listed in the provenance meet some minimum SLSA level. |
| 24 | + 4. That the build entry point listed in the provenance is what they expect. |
| 25 | + 5. (TBD) That the binary dependencies listed in the provenance meet some minimum SLSA level. |
| 26 | +5. Only publishing the container image if all the checks in #4 pass. |
| 27 | +6. Storing the provenance and all other attestations for future reference. |
| 28 | + |
| 29 | +This approach allows BarInc to acheive their goals without requiring any changes from their users |
| 30 | +or from their distribution channels. It doesn't, however, protect their users from a published |
| 31 | +BarImage from being tampered with after publication (though there may be other ways to address |
| 32 | +those concerns, such as code-signing after verification, and time-of-use verification). |
| 33 | + |
| 34 | +## Developer using third party software packages |
| 35 | + |
| 36 | +A developer using BarImage wants to ensure it hasn't been tampered with before using it. |
| 37 | + |
| 38 | +They could do this by: |
| 39 | + |
| 40 | +1. Requesting BarInc to publish the [in-toto Provenance] and any additional attestations (such |
| 41 | + as [source control attestations]) for BarImage each time it is released. |
| 42 | +2. Requesting BarInc to publish the public keys its builder uses to sign the attestations. |
| 43 | + - (TBD) [Determine how to convey these keys]. |
| 44 | +3. Requesting BarInc to confirm what SLSA level their builder and source control system meet. |
| 45 | + - In the future there may be an accredidation body that confirm this _for_ BarInc. |
| 46 | +4. Determining what policy to apply to BarImages. |
| 47 | + - They could create this policy on first use based on the data provided in the in-toto Provenance. |
| 48 | + Any significant deviations (e.g. builder changed, source repo changed) would cause failure. OR |
| 49 | + - BarInc could _publish_ a suggested policy for users of BarImage on their website. |
| 50 | +5. Establishing a secure control-point that any uses of BarImage must pass through in order to be used. |
| 51 | + - E.g. On import to a local Docker registry. |
| 52 | +6. Having the control-point check the candidate BarImage against its provenance, checking it against the |
| 53 | + policy from #4. |
| 54 | +7. Only importing the container image if all the checks in #6 pass. |
| 55 | + |
| 56 | +This approach protects the developer without having to rely on any trust in intermediate package |
| 57 | +repositories. |
| 58 | + |
| 59 | +## Package Repository accepting a software package |
| 60 | + |
| 61 | +A Package Repository (e.g. Docker Hub) wants to protect their users from malicious changes to the |
| 62 | +container images uploaded to the repo. |
| 63 | + |
| 64 | +They could do this by: |
| 65 | + |
| 66 | +1. Requesting publishers of containers to publish the [in-toto Provenance] and any additional |
| 67 | + attestations (such as [source control attestations]) each time a new image is pushed to the |
| 68 | + repository. |
| 69 | + - (TBD) Where to store this provenance? |
| 70 | +2. Requesting publishers to publish the public keys it's builder uses to sign the attestations. |
| 71 | + - (TBD) [Determine how to convey these keys] |
| 72 | +3. Requesting publishers to confirm what SLSA level their builder and source control system meet. |
| 73 | + - In the future there may be an accredidation body that confirm this _for_ the publishers. |
| 74 | +4. Determining what policy to apply to published images. |
| 75 | + - They could create this policy on first use based on the data provided in the in-toto Provenance. |
| 76 | + Any significant deviations (e.g. builder changed, source repo changed) would cause a push |
| 77 | + failure. OR |
| 78 | + - The Package Repository could have publishers configure their specific policy as a part of their |
| 79 | + repo. |
| 80 | + - The Package Repository could make these policies publicly readable by users of the repo. |
| 81 | + - (TBD) How to securely update these policies. |
| 82 | +5. Checking new containers against the policy from #4. |
| 83 | +6. Preventing container images that fail the check in #5 from being made public. |
| 84 | + |
| 85 | +This approach could protect users of protected repos from malicious tampering without requring all |
| 86 | +users to do their own policy checks of each image they consume. |
| 87 | + |
| 88 | +[Determine how to convey these keys]: https://github.com/slsa-framework/slsa/issues/101 |
| 89 | +[in-toto Provenance]: https://github.com/in-toto/attestation/blob/main/spec/predicates/provenance.md |
| 90 | +[source control attestations]: https://github.com/in-toto/attestation/issues/47 |
0 commit comments