slsa
slsa copied to clipboard
slsa-framework
v0.2: Simplify terminology and concepts: "platform" vs "service", "trusted person", "non-falsifiable", etc.
This thread tracks terminology and concept simplification for v0.2. Things under consideration:
- Use either "platform" and "service" consistently rather than having two separate terms. (#294)
- Replace "non-falsifiable" with a more accurate term, such as "non-forgeable" or "trusted". (#332)
- Replace "trusted persons" with "maintainers". (https://github.com/slsa-framework/slsa/issues/94#issuecomment-1079603510)
We will do a version bump for this because these terms are used in many places. Changing these names in v0.1 will break existing links/references and generally make it harder people who knew the old version to understand the new version.
Please add more ideas to this thread.
Capturing that it would be useful to clean up Trigger and Instruction usage (separating the unit that is executed in response to the event causing that execution to occur).
See also: #129 (better define source). We probably want to clarify "build script" vs "primary source artifact" because in some cases it's different, e.g. GCB and Tekton allow the build script to be defined via the UI, not coming from the source repo. That thread has a lot more detail.
By the way, here's an alternate build diagram that I just rediscovered. We might want to incorporate bits of this into our new build model from #294.
Regarding terminology, defining "build script" and "primary source artifact" and also splitting "build" and "source code" into two valid ... sources(?) would clarify some issue, at least for me.
I asked in #308 if e.g configuration management code[1] could be a valid level 1 since there is no build process per se and the documentation states that "the build process must be fully scripted/automated and generate provenance".
- Ansible, Terraform or shell code
Regarding the question from #308, we should clarify that no build is required. If the thing pulls directly from the version controlled source of truth (eg git) then all of the build requirements are trivially met. But if you pull files out of the get repo and package them into a zip file or similar, that is still a build.
Continuing the discussion with @nasifimtiazohi from #94 on the idea to rename "trusted persons" to "maintainers":
Are there any cases where "maintainers" is worse than "trusted persons"? I can't think of any but it's worth asking.
Well, I am not sure about the exact definition of maintainer as well. If it is only about write access to a GitHub project, then a compromised maintainer can add a sock puppet account as another maintainer to bypass the review restrictions. But then again, a compromised maintainer with enough permissions probably can do a lot of other things as well.
On the other hand, a "trusted person" may indicate that trust is established based on some past activity for a certain developer account.
Suggestion: we move this term to the Terminology page and define a maintainer as a person, not an account. In the requirements we already have the "Different persons" requirement w.r.t. the sock puppet issue.
GCB and Tekton allow the build script to be defined via the UI, not coming from the source repo.
Small detail re Tekton: the hurdle for Tekton is that in the initial implementation, the source of truth for task/build definitions was the Kubernetes cluster - but later support was added for storing these definitions in OCI registries and recently fetching them from version control (TEP-0060).
(The UI was never the source of truth for Tekton task definitions, just a way of viewing them.)
+1 on resolving for 1.0. I'd note that "Non-falsifiable" has long been used in security circles and has a well understood technical definition. Agree re: service/platform and as "trusted person" only appears to be used in the context of source provenance we can probably defer resolving that
Other terminology related issues:
- https://github.com/slsa-framework/slsa/issues/369
- https://github.com/slsa-framework/slsa/issues/366
- https://github.com/slsa-framework/slsa/issues/367