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 <aditya@saky.in>
Signed-off-by: Aditya Sirish <aditya@saky.in>
Signed-off-by: Aditya Sirish <aditya@saky.in>
Signed-off-by: Aditya Sirish <aditya@saky.in>
This is for situations where different packages are results of different projects / supply chains. Signed-off-by: Aditya Sirish <aditya@saky.in>
Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>
trishankatdatadog
force-pushed
the
trishankatdatadog/ITE-2
branch
from
a75aed1
to
7d15ac6
Compare
|
Thanks for all your help, @adityasaky! @JustinCappos, could we please get another review? |
There was a problem hiding this comment.
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 <trishank.kuppusamy@datadoghq.com>
|
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 <trishank.kuppusamy@datadoghq.com>
Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>
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.