Informal security chat with Beyond Identity's CTO Jasson Casey, Founding Engineer Nelson Melo, and VP of Global Sales Engineering Husnain Bajwa and our host Marketing Empress Reece Guida about how the announcement from Github that by the end of 2023 they will be requiring 2FA for all developers. 

Transcription

Reece

Hello, and welcome everybody to "Hot Takes" with me, Reece, marketing person, Nelson, our founding engineer, HB, our global sales engineering leader, and Jasson, our CTO. Today's hot take comes on the heels of some pretty interesting news from GitHub. They made an announcement that by 2023, the end of 2023, that every developer using GitHub needs to have to 2FA enabled. So I think that this is a step in the right direction but I think that GitHub is conflating, securing your repo with enabling MFA. What do you guys think about GitHub's mandate? Do you think that it actually shifts security left in a meaningful way?

Jasson

They are, and I'll take the bait. So I think it's a great thing to do but it is, what is it, $1 sure that they late, whatever the appropriate analogy is. They're helping secure access to the administrative console of Git or of GitHub. The threat and the primary concern of people who build software is, are they actually providing integrity on their build and delivery process to where they can actually ensure their customers are getting exactly what they should be getting and nothing else? How do they help their customers solve the supply chain problem, which is I know I'm building things from a legitimate source and not an adversary, right? So if I drill in, right, I'm building software, how do I solve my build and delivery integrity problem?

Well, I break it into four parts. I have the source code, right? How do I know that code actually comes from the developers that I've trusted then that I have verified? I have built. How do I know that? In fact, I'm building that trusted, verified source and nothing else? We have dependencies, how do I know I'm getting dependencies from parties that I trust and that are verified and only those go into the build process. And then finally, how do I ensure the thing that comes out of my unbilled system that I verified is actually what is being delivered, loaded, and installed at my customer sites and nothing else. So those are kind of the four phases of this lifecycle. Integrity controls and authorship controls are kind of important in each phase. This doesn't address any of that because let's remind everyone, how I access the administrative console of GitHub or even GitLab for that matter has a transitive value or transitive property on security of how I pull and push repos and how I commit code to those repos.

Because when I pull a repo or when I start a repo, it's on my machine, right? It's not in GitHub or GitLab. I have to synchronize. So if I'm worried about those four phases or really the first set of phases, right, if we're thinking about repos, like how do I know that the code in the repo is from my people and no one else? I need to worry about the security of commits and of database synchronizations. So database synchronization is managed through SSH. So again, if I'm securing the administrative console, then I'm depending on developers to get key management for push pull operations. We know even developers have error rates. And so if my error rate is one to a thousand, then we're just waiting on my developer to do something a thousand times for the error to show up. How many developers exist in the world? That's a material number when you multiply that out.

Now, again, that's still not actually solving the problem of source strips. Source strips is the commit in the database, actually, from the person I expect and no one else. And the SSH key does not solve that problem, you actually have to do commit signing with a GPG key. Technically, you can kind of do it with a SSH key as of like a get-release last year but the reality is those haven't been picked up and mainstreamed in major ways just yet. But the point is, no one is really signing commits yet. But until I'm signing commits, my build system can't actually groom and look at the source that it's building and say "these are verified developers or not" right? It's trivial for you to do a commit dash, dash author equals Donald Duck. And oftentimes, that's not actually what's happening.

What's happening is people just have improper repo git config or device repo config, so depending on where they're doing work and committing work, you may or may not have authorship that's accurate, but it's accurate at best guess. It's not provable, it's not verifiable. It doesn't fall into any world of trusted or verified computing and is not good enough for security. So good job GitHub. It doesn't solve the problem of delivery integrity, or as far as those of us who build software and sell for a living, it doesn't solve our customers' supply chain problems.

Reece

And that's what they said it would do, which is very misleading and I think a bit confusing to a lot of people who are looking to MFA to solve a lot of their security woes, right? Like we saw Salesforce make this required, now GitHub is doing it. So we're seeing this trend but the underlying problem is still there.

HB

I think if you look at it more closely, one of the things that's problematic is that GitHub's blog posts had a lot of nuance to it. But the nuance doesn't get picked up by the news stories and it's intentionally vague and ambiguous. The part of the...

Reece

Why do you think it's intentionally vague and ambiguous though? Like, because you think they know that there's still gaps, kind of like what Jason was saying?

HB

I think it's really tricky, right? Like for one thing, the timeframes are kind of ridiculous, right? Like the idea of announcing something and the broad idea is that we're going to do it by the end of 2023. In internet time that's got to be what like, you know, 20 years or something? So the near-term stuff that they're proposing is to essentially improve security and force this on to the top 500 maintainers. Super alarming when you hear them say that because you would assume that that 16.5% of the population that's currently using MFA would be that group of 500 maintainers. I think it's definitely a good step for them to do that. I think the last paragraph was the most telling on the blog post and I think a lot of people probably missed it, which was the looking forward.

And the looking forward had sort of parenthetical about other things that they'd like to improve while maintaining excellent user experience. And I think they just don't have solutions yet for CodeCommit or actions and packages that they feel are comprehensive and easily integrated. And I think that's where we would obviously beg to differ, right, like, I think our CodeCommit solution is the technique by which enterprises can immediately adopt a much stronger posture on a software supply chain security.

Reece

Yeah, absolutely. And Nelson, I think you'd be great to comment on how that works, how we do it, and how that kind of addresses the gaps that GitHub knows are there but it's just kind of...

Nelson

So we're essentially looking at two fundamental problems. One is how do we make sure that whatever keys you're using to sign those commits are generated in a manner that's consistent with your security practices stored in that machine in that same way? Hopefully, on some sort of Secure Enclave or TPM that cannot be moved. And then actually ensuring that when you're using that key to commit something, it comes from a machine that has the security controls you expect in place. And hopefully, you're also doing some sort of MFA to use that key. So Touch ID, biometric local pin, whatever you have available on that machine to unlock the key shouldn't be part of the process. If you sort of tie that down, you go a long way making sure that the commit comes from who you actually think it came from.

Reece

Yeah. And that approach is MFA by default, right?

Nelson

It could be or it should be, just to be able to sign every commit with the assurance that we've verified that it's not some remote actor that has access to your machine, but it's actually someone who's been able to unlock the key on the TPM one to two chip, whatever it is.

Reece

Yeah. So in order to impersonate somebody or to commit code to a repo, you'd have to have that person and that device in the same room. So I think that that does go a long way to securing the repo in a way that this 2FA mandate does not. So if you guys could tell the world, you know, GitHub, your peers, any kind of advice or caution on the heels of this announcement, what would it be?

Jasson

If you're building a product, you need to actually think about how you secure your product and the integrity of it and get it to your customers. You need to think about those four phases that we talked about: source, dependencies, build, and distribution. And you really need to think hard about how do I know when, or in the fourth case, how does my customer know that this is exactly what it's supposed to be and it comes from exactly who they think and no one else. The only technical answer to that is integrity, right, integrity protection, i.e., things that are signed from a source that you actually trust, but it's also a mechanization process that orchestrates that through the lifecycle of how software gets built.

GitHub and GitLab and Bitbucket or whoever your provider is, is not going to solve this problem for you. You kind of have to take charge of this yourself. And you have to take charge of this yourself from a CI/CD architecture perspective. Are you signing your commits? And if you're not, like how do you start the process in a way that's verified? Number two is how do you know that the things that you're building, are in fact the things that were signed, right, whether by your developers or your third parties? For your third parties or your dependencies, how do you know that what you're getting is in fact from them and no one else? And then from a distribution perspective, how do you know that all of those things that you just verified in your system, in fact, make it to your customer and your customer has the ability to verify that integrity?

So we're talking about chaining, right? We're not talking about transitive trust, we're talking about chain of trust. The way the person knows it's true at the end is they can see the chain of almost all of the steps. There's evidence trail, right? There's never a security model in place where because I see you in a secured area I assume you must be authorized to be in the secured area, right? That's oftentimes how we solve these problems today. But we're not actually solving those problems when we use that method. We're giving ourselves a little security theater, or causing work for people, and we're just creating opportunity for adversaries.

HB

I think those are all really good points. And the other thing is that when people are thinking about software supply chain security and identity governance, you can't start from the very incremental model of 20% better by moving away from exclusively password-based authentication.

You've got these four components that you have to think about. And rather than just thinking about user accounts is this little bubble that today has passwords and tomorrow it has passwords plus MFA, the real answer is exactly what Jason was talking about that like each of those stages needs to have a strong identity tie-in that has, ideally, you know, record-keeping with guarantees around non repudiation. You know, these are the sort of like levels of highest assurance that are possible. And the more people can think about it in terms of that like stage by stage identity governance and apply solutions, that's the best approach and that's where we're trying to plug in with our solution.

Reece

Yeah. That's a way to put the stake in the ground. Feast on that GitHub. Let us know what you think in the comments, and we'll see you for next week's "Hot Take."