Document SLSA level for build attesations

[asraa]

Hey!

Very cool project, and we were curious about your SLSA leveling and roadmapping.

I believe this achieves SLSA 2 when creating attestations for a command that produces a build artifact, since it creates signed attestations with the provided key (and upcoming, Fulcio issued certificates).

I was curious about adding a build demo to achieve SLSA 2, and also, if there's a roadmap or way to achieve SLSA 3. We are also creating builders on slsa-framework/slsa-github-generator and some follow a similar model as this one, but we achieve SLSA 3 through some further isolation requirements.

I'd be happy to add a PR with some README documentation about SLSA. Let me know!

cc @laurentsimon @joshuagl

[colek42]

@asraa This action produces in-toto link metadata about some arbitrary CI Step. I think the user would also require in-toto verify and a specific in-toto layout to meet any SLSA or other end-user software supply chain control requirements.

Suppose the link meta-data meets the layout requirements, and the layout has the required policy constraints for SLSA conformance. In that case, you could theoretically make an SLSA 4 assertion about the artifact produced by a pipeline instrumented with in-toto.

There is a bit of debate about isolation guarantees provided by in-toto. However, the file integrity provided by in-toto verify allows the user to detect if the file system was changed between steps.

Of course, this is moot until we have more secure options for key providers in this action.

@SantiagoTorres, do you have any thoughts on SLSA w.r.t. in-toto layouts/link meta-data