Skip to content
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

TODO: Need mitigation description for "Use a compromised build tool" threat #1184

Closed
lehors opened this issue Oct 9, 2024 · 2 comments · Fixed by #1251
Closed

TODO: Need mitigation description for "Use a compromised build tool" threat #1184

lehors opened this issue Oct 9, 2024 · 2 comments · Fixed by #1251
Assignees
Labels

Comments

@lehors
Copy link
Member

lehors commented Oct 9, 2024

No description provided.

@TomHennen
Copy link
Contributor

I think a reasonable mitigation here is something like "Treat build tooling, including OS images, as any other software to be verified prior to use (as described in (G)). This will allow the build platform to detect any modified binaries."

Once the attested build environments track is finalized we can update this mitigation to reference it specifically. CC @marcelamelara

Separately, I'm wondering if this is a reason to move the mitigations from (G) (discussed in #1190, #1191) to (I) since 'usage' is more clearly aligned with this risk than with 'distribution channel'. (Or maybe we can just tweak the mitigation language here to discuss).

@TomHennen TomHennen self-assigned this Oct 15, 2024
@marcelamelara
Copy link
Contributor

@TomHennen Definitely happy to help with this as well!

@lehors lehors added this to SLSA 1.1 Nov 26, 2024
@lehors lehors moved this to Todo in SLSA 1.1 Nov 26, 2024
TomHennen added a commit to TomHennen/slsa that referenced this issue Dec 3, 2024
This threat can be mitigated in a number of ways, here I address it in the simplest one,
verifying the tooling prior to use.  You can also imagine resolving it by recording
the digests in the provenance, and propagating VSAs so that downstream verifiers can
verify recursively, but that's pretty complicated.

You can also resolve this with the attested build environments track, but I don't think
we should mention that here until it's finalized? Or maybe we can point to it now as
'coming soon'?

fixes slsa-framework#1184

Signed-off-by: Tom Hennen <[email protected]>
TomHennen added a commit that referenced this issue Dec 11, 2024
This threat can be mitigated in a number of ways, here I address it in
the simplest one, verifying the tooling prior to use. You can also
imagine resolving it by recording the digests in the provenance, and
propagating VSAs so that downstream verifiers can verify recursively,
but that's pretty complicated.

You can also resolve this with the attested build environments track,
but I don't think we should mention that here until it's finalized? Or
maybe we can point to it now as 'coming soon'?

fixes #1184

---------

Signed-off-by: Tom Hennen <[email protected]>
Signed-off-by: Tom Hennen <[email protected]>
Co-authored-by: Marcela Melara <[email protected]>
Co-authored-by: Trishank Karthik Kuppusamy <[email protected]>
@github-project-automation github-project-automation bot moved this from 🆕 New to ✅ Done in Issue triage Dec 11, 2024
@github-project-automation github-project-automation bot moved this from Todo to Done in SLSA 1.1 Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants