equinor
Add management system references for why signed commits is recommended
I enjoyed reading the straight forward guide on how to enable signed commits.
If possible, please add any management system references for why you recommend this on github repositories that already require MFA for pushing commits and authorization on the repository level for writing commits.
I.e. something related to "zero trust" and that we shouldn't even trust our team members from creating forged commits.
Thanx for the comments @v3gard
I get your point, but don't think I fully agree. The MFA is connected to logging in to github.com. The SSH keys, PAT tokens and such (once authorized for org) are not protected by the MFA. So in theory I can "steal" your PAT token, use this to check out code, alter code, commit (unsigned) and the push to the repo. Signing adds another level of "potential" trust. I say potential - because nothing is ever 100% :slightly_smiling_face:
This practive would be connected to TR2375 and SR-133093 - "Secure development life cycle". We can consider adding this later. I'm am a bit uncertain on to what degree we should add references to internal governance - as this will not be available to the "public"
I'm am a bit uncertain on to what degree we should add references to internal governance - as this will not be available to the "public"
What about public references to Equinor's vision or strategy for secure development? I hear this get's talked about, but I don't see much in writing about the subject. This is one of the few articles I could find about Zero Trust Architecture (ZTA).
Referring to ZTA removes ambiguity (for me at least), because it then becomes obvious why we do these things, i.e. Never trust, always verify.
@larskaare - any follow up here or can it be considered as closed @v3gard ?
It's not important for me to have it added, but I think putting references to ZTA somewhere in writing would help motivate those who suffer from indecisiveness on this topic to make a decision (i.e. activate signed commits). It would also help us in team discussions where we can't agree on a shared way of working.
I can let @larskaare decide if we should close this or not.
Closing with as-is for now. We don't add refs. to internal requirements.....