-
Notifications
You must be signed in to change notification settings - Fork 16
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
ITE-2: Using TUF and in-toto to build compromise-resilient CI/CD #4
ITE-2: Using TUF and in-toto to build compromise-resilient CI/CD #4
Conversation
@jhdalek55 Addressed your early comments, thanks! @SantiagoTorres @JustinCappos Please send feedback, thanks! |
One idea is to make ITE-2 all about the basic security model And ITE-3 about the Datadog Agent integrations What do you all think? |
Trishank's suggestion of keeping ITE-2 more general and covering the specific Datadog integration more general makes sense to me. |
@SantiagoTorres I need to write the CNAB TUF-in-toto standard. Could you please help address Justin's comments? Thanks! |
Signed-off-by: Aditya Saky <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
This is for situations where different packages are results of different projects / supply chains. Signed-off-by: Aditya Sirish <[email protected]>
Signed-off-by: Trishank Karthik Kuppusamy <[email protected]>
a75aed1
to
7d15ac6
Compare
Thanks for all your help, @adityasaky! @JustinCappos, could we please get another review? |
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 have a few thoughts. The main one is trying to figure out the balance between best practices and a spec. It feels like this tries to give advice (as a best practice would) but is using MUST, SHOULD, etc. without explanation (as many specs do). I'd recommend moving to more of a best practice flow with narrative explanation around the choices. However, I also want to leave this up to others to chime in on the chance that I am off base...
Something that I would like this PR to specify is what is the key for the custom in-toto metadata. I think the DD implementation uses simply |
Another aside that I'm thinking of is if we want to "abstract out" the roles suggested to not mandate a pipeline, but rather the minimum duties provided:
My rationale for this is to not say "you need to have a packager" but rather "somebody that's wrapping everything together (which btw it fits very well with the packager, look at ITE-3)" Thoughts? |
Okay, I think we can make these changes. Let me talk to @adityasaky and get back to you... |
Signed-off-by: Trishank Karthik Kuppusamy <[email protected]>
Ok, @adityasaky and I made some changes! Are we good now? |
can we resolve the conflicts? |
Done! |
Thanks! I was reading and I wonder if we'd like to use the tuf in-toto-demo (with changes) as the reference impl for this. What do you think? |
Signed-off-by: Trishank Karthik Kuppusamy <[email protected]>
Signed-off-by: Trishank Karthik Kuppusamy <[email protected]>
Agreed, and updated link |
Hi, any news on this, pls? |
Oh, sorry I thought I merged. Could you also go ahead and announce it on the ML so we can start gathering feedback? |
We discuss a standard for using The Update Framework (TUF) as a higher-level protocol for securely distributing in-toto layout and link metadata as well as the software packages described in the in-toto metadata. Assuming that critical signing keys are kept offline from the CI/CD pipeline, combining TUF with in-toto provides the pipeline with a desirable property called compromise-resilience: that is, even if the pipeline is compromised anywhere between developers and end-users, then attackers should not be able to cause end-users to install malicious versions of packages that were never released by developers.