GitHub: "Trust By Default".. what???

[bkwalker]

I was reading a GitHub job posting on linked in and saw this (emphasis mine):

"Leadership Principles:

Customer Obsessed - Trust by Default - Ship to Learn - Own the Outcome - Growth Mindset - Global Product, Global Team - Anything is Possible - Practice Kindness"

Okay, it's a "Leadership Principle" however in the context of the job it really sounds bad.   "Enterprise Solutions Engineer" is roughly a sale/support job helping businesses leverage GitHub services for DevOps... I wouldn't want Trust By Default to be anywhere near that 😉

job posting: https://www.linkedin.com/jobs/view/2701615072/?refId=w4o3Hu2li2R3UxBuXBOP1A%3D%3D 

[JKWiniger]

@bkwalker Yes, you are right on this one, but it's not the worst job description I have seen. Instead of "trust by default" I would think it should be "secure by default" it would make a lot more sense and instill a much higher level of trust!

John-

[bkwalker]

I think it shows a disconnect between leadership and R&D/Security... or they mean something else entirely.

[Caute_cautim]

@bkwalker @JKWiniger But remember that GitHub has failed on a number of occasions, including issues with the code itself being compromised.  Trust but verify is more appropriate.

https://github.com/hjacobs/kubernetes-failure-stories

https://containerjournal.com/features/how-not-to-use-kubernetes-5-failure-stories/

https://github.blog/2020-12-16-reducing-flaky-builds-by-18x/

Regards

Caute_Cautim

[CraginS]

"Trust but verify is more appropriate"

Last year I used the phrase Trust but verify in an academic paper that I presented at a conference, because that phrase was used by the lead author.  One of the folks in the room, a published expert in information security who is also a lawyer, objected. She said she hates that phrase because if you have to verify, then logically, you do not trust. She said the focus should be

Verify to Trust.

I had to admit that both grammatically and logically she was correct.

Craig

[JKWiniger]

@CraginS I don't agree at all. To me, Trust but verify is exactly what it should be and it is why we have audits and pen tests. When we build our systems hopefully we use best practices, which we trust, but then when things are audited or test we are basically verifying...

John-

[JKWiniger]

@CraginS I had another thought on this... from a management perspective it is defiantly trust but verify! Think about, you have the people under you that you asking tasks you. You trust them to do the work, and when they say they have done what was asked, you trust! But you would not be doing your due diligence if at times you did not verify that they did what they were asked to do... there is no way to verify then trust...

John- 

[CraginS]

John @JKWiniger 

You have hit on a distinction that is essential in this process.

When dealing with people and their actions, it only possible to vet their trustworthiness in advance, as during the hiring or appointing process, then trust their actions, but have an after the fact audit process to verify the trust remains valid.Keep in mind, that the initial evaluation of trustworthiness is, in reality, a verify step prior to trusting. So, even in this situation, you are verifying before trusting. Since people change their actions under conditions of new motivation, you still need teh post-action to verify again through reviews and audits.

However, when moving into information systems, as we look at the overall systems, we still must pay attention to the tools and processes. You must verify the tools (hardware and software) prior to trusting them. And you must verify the processes, through table top exercises and other steps, prior to trusting them.

The language her eis most definitely nuanced, but I contend even your example, when examined in detail, is a verify then trust process.

Craig

[JKWiniger]

@CraginS Hmmm, very interesting.. you have given me a different way to look at it, so thank you!

John-