-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SLSA v1.0: Add "Verifying Build Systems" #568
Conversation
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I think this is great! There are only a few typos that need to be fixed and I think there are some areas that we can improve, especially when it comes to cryptographic secret security
docs/spec/v1.0/verifying_systems.md
Outdated
- Creating executors | ||
- How does the control plane share data with executors? Example: mounting a shared file system partition | ||
- How does the control plane protect its integrity from executors? Example: not mount its own file system partitions on executors | ||
- How does the control plane prevent executors from accessing its cryptographic secrets? Examples: dedicated secret storage, not mounting its own file system partitions on executors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to also mention hardware security modules here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great to me! I just have some minor suggestions
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
### Types of attackers | ||
|
||
We consider three attacker profiles differentiated by the attacker's capabilities and privileges. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now this section is a bit unclear on the meaning of terms like "the source repo", "their", and "the package". Maybe explain that there is a "target" repo/project? Then in low privilege, "their" can be used to describe the attacker creating a separate project unrelated to the target?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to clarify this section by drawing a distinction between the "target build" and "controlled builds." It may be a bit clunky.
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
docs/spec/v1.0/verifying_systems.md
Outdated
Note: Platform abuse (e.g. running non-build workloads) and attacks against builder availability are out of scope of this document. | ||
|
||
TODO: Align/cross-reference with SLSA Provenance Model. | ||
TODO: Redraw diagrams in the style used by the rest of the site. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarkLodato who has created the diagrams before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a design firm (Projects by IF) draw them initially, and then I have since updated them. It's in Figma format, with the source at https://github.com/slsa-framework/slsa/tree/main/resources/editable-diagrams. You can create a free account. Figma has a bit of a learning curve, but it has a lot of features for power users, such as components.
Sadly there is no clean version control integration, so I just download the .fig file and check it in whenever I update the diagram, which is as light pain.
For this PR, I think any diagram is fine, then we can clean it up once we get close to publishing.
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
- Examples | ||
- Anyone on the internet | ||
- Build servec insiders without administrative access |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be "Build service"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
docs/spec/v1.0/verifying_systems.md
Outdated
- What is your process for responding to vulnerability disclosures? What about vulnerabilities in your dependencies? | ||
|
||
- Creation and destruction | ||
- What environment is available in executors on creation? How were the elements of this environment chosen? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you able to append an example for what you'd expect an answer for "What environment is available"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Great work! Thinking about the user experience for someone wanting to fill out the assessment- |
docs/spec/v1.0/verifying_systems.md
Outdated
Note: Platform abuse (e.g. running non-build workloads) and attacks against builder availability are out of scope of this document. | ||
|
||
TODO: Align/cross-reference with SLSA Provenance Model. | ||
TODO: Redraw diagrams in the style used by the rest of the site. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a design firm (Projects by IF) draw them initially, and then I have since updated them. It's in Figma format, with the source at https://github.com/slsa-framework/slsa/tree/main/resources/editable-diagrams. You can create a free account. Figma has a bit of a learning curve, but it has a lot of features for power users, such as components.
Sadly there is no clean version control integration, so I just download the .fig file and check it in whenever I update the diagram, which is as light pain.
For this PR, I think any diagram is fine, then we can clean it up once we get close to publishing.
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
### Types of attackers | ||
|
||
We consider three attacker profiles differentiated by the attacker's capabilities and privileges. | ||
We consider three attacker profiles differentiated by the attacker's capabilities and privileges as related to the build they wish to subvert (the "target build"). | ||
|
||
#### Low privilege |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you thought about just calling these:
- Everyone else (low privilege)
- Project maintainer (medium privilege)
- Build service admin (high privilege)
It seems like the rest of the doc does not use the low/medium/high profile terms anyway. Perhaps the alternates are easier to work in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to the alternatives
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering private projects, I'd recommend to not use "Everyone else" rather something like "Developer" or "Contributor". I feel this could help apply for both public and private projects.
- 1 for alternatives though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New wording is "Project contributors". (But it should be singular.)
But that seems overly narrow. An attacker could be someone who is not a contributor at all, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point, we are talking about someone who is able to execute the capabilities:
Capabilities:
- Create builds on the build service. These are the attacker's controlled builds.
- Modify one or more controlled builds' external parameters.
- Modify one or more controlled builds' environments and run arbitrary code inside those environments.
- Read the target build's source repo.
- Fork the target build's source repo.
- Modify a fork of the target build's source repo and build from it.
I suppose they are an "Authenticated User" with those abilities. That would satisfy my concern about private / public projects.
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
TODO: Align/cross-reference with SLSA Provenance Model. | ||
TODO: Redraw diagrams in the style used by the rest of the site. | ||
|
||
### Types of attackers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this list of attacker profiles, but the rest of the doc doesn't seem to use it. That seems like a missing piece, though I can't figure out exactly what's missing.
Maybe it's that the SLSA Build requirements are designed to protect against Low and Medium attackers, while protecting against High attackers is very complex and we need this "verifying systems" piece to convince consumers that they've done a good enough job?
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
#### Prompts for Assessing Parameters | ||
#### Prompts for Assessing External Parameters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also: What gives us confidence that there are no additional external parameters that are missing from the provenance, and that a future design change will not violate SLSA assumptions?
(I ask because the new GHA Variables is exactly this type of design change.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice work on this Kris. It looks great overall, I made a few minor comments on clarity and would like to see other's feedback addressed too.
Should we be adding a requirement that all build systems provide this information? My reading of the "Builder Evaluation" section suggests yes. If so, is that follow-on work?
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
### Control Plane | ||
|
||
The control plane is the build system component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. The control plane generates and signs provenance for each SLSA Build L3+ build performed on the system. The control plane is operated by one or more administrators, who have privileges to modify the control plane. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The control plane is the build system component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. The control plane generates and signs provenance for each SLSA Build L3+ build performed on the system. The control plane is operated by one or more administrators, who have privileges to modify the control plane. | |
The control plane is the build system component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. At SLSA Build L3+ the control plane generates and signs provenance for each build performed on the system. The control plane is operated by one or more administrators, who have privileges to modify the control plane. |
I'm worried that folks could read the original phrasing as only L3+ builds are signed, but maybe I'm being overly pessimistic here. My suggestion may not actually help either. :-D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, though I used L2+ since that's when the service starts signing provenance.
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
- What sorts of caches are available to build executors? | ||
- How are those caches populated? | ||
- How do you defend against cache poisoning attacks? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might re-phrase this as "How are cache contents validated before use?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
## Builder Evaluation | ||
|
||
Organizations can either self-attest to their answers or seek an audit/certification from a third party. Questionnaires for self-attestation should be published on the internet. Questionnaires for third-party certification need not be published. All provenance generated by L3+ builders must contain a non-forgeable attestation of the builder's L3+ capabilities with a limited validity period. Any secret materials used to prove the non-forgeability of the attestation must belong to the attesting party. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably expand on " All provenance generated by L3+ builders must contain a non-forgeable attestation of the builder's L3+ capabilities with a limited validity period." – what attestation? Why? What period?
This AI could be a TODO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of this - maybe for SLSA 1.1 we could create a verified build system attestation spec :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added as a TODO. I'm hoping to squeeze it into 1.0 if possible.
docs/spec/v1.0/verifying_systems.md
Outdated
|
||
### Types of attackers | ||
|
||
We consider three attacker profiles differentiated by the attacker's capabilities and privileges. | ||
We consider three attacker profiles differentiated by the attacker's capabilities and privileges as related to the build they wish to subvert (the "target build"). | ||
|
||
#### Low privilege |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to the alternatives
It would make the maintainers' lives easier if the build system vendors were able to provide this to the best of their ability (maintainer may need to fill in some gaps) |
Signed-off-by: kpk47 <[email protected]>
docs/spec/v1.0/verifying_systems.md
Outdated
@@ -0,0 +1,157 @@ | |||
# Verifying Build Systems |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: use hyphens to separate words, not underscores (e.g. use-cases.md, get-started.md, also that's Google's style guide). I suggest waiting until right before merging so that we don't lose comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Co-authored-by: Mark Lodato <[email protected]> Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
Signed-off-by: kpk47 <[email protected]>
Addresses #508 .