GitHub GitHub Universe 2022 - Security, 21 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud-native secure software development - Universe 2022

Description

Presented by: Dan Shanahan

Developers face an ever-increasing demand to quickly deliver secure, high-quality software. In this session, we’ll explore the future of cloud-native secure software development tools which remove friction and increase developer productivity. We’ll demonstrate GitHub products and features such as Codespaces, GitHub Advanced Security (GHAS), and Actions, which help developers receive feedback quicker and deliver higher-quality, more secure software.

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

A

Hey there, my name is Dan Shanahan and I'm, a field security specialist here at GitHub today, I'm going to spend the next 15 minutes, walking through a demo of secure development practices using the GitHub platform to show you a couple of methods that you can use to be more productive as an engineer and as a development team. So what do I mean by Cloud native secure software development? Well, really. What I'm referring to is using the suite of capabilities which GitHub offers that provide development.

A

Ecosystems like code spaces also have CI CD tools like GitHub actions and, of course, the security capabilities that come along with GitHub Advanced security. By introducing these capabilities into your development practices, we, as developers were able to write software more quickly with less friction all while making security a first-class citizen.

A

It's a keyword that I use in that intro and that's productivity. Let's dive into that a little deeper, just kind of set the stage in order for us to be productive as developers, we need to find a balance between three sometimes competing concerns versus speed or the ability to deliver software quickly for our customers. For your customers.

A

Secondly, it's quality right, making sure that the software that you're building is free of defects and that it operates the way that your customers expect it to then. Finally, security, which is making sure that the software that you're building is secure, that your customers can trust the services and the software that you're delivering to them and as developers, we need to make sure that the tools that we're using during our development experience help us to achieve that balance and productivity is important.

A

It's not just important, because the companies that we work for want us to ship software quickly, but it's also important for us at the most basic human level as well stack Overflow releases survey back in March, where they asked thousands of developers. What makes you unhappy at work and the number one sighted reason for making these devs unhappy is a lack of productivity. This was a surprise to me.

A

More developers responded with that answer than an unhealthy work-life balance and an unfair salary, and when I think about this and I think about my experience as a developer, I can relate having tools that introduce friction or don't communicate in the same way. I'm communicating and really aren't living in the same platform, where I'm working on a day-to-day basis can be a very frustrating experience. So how does GitHub approach this?

A

How do we think about and enable productivity for developers really it all comes down to reducing friction to reduce friction, we need to be able to embed security into every step of the development life cycle and that's from the initialization of a product idea all the way through to the production release of that product.

A

We need to make sure that the configurations that we're defining for our development environments and for our security is configured and expressed as code, which allows our tools to be portable and allows us to bring configurations with us, no matter where we're actually working from. So when we have all these configurations expresses code, we can begin to introduce Automation and automation. Is there to just really help us make our lives easier?

A

All right so in these demos, I'm going to be using three different products from the GitHub ecosystem, I'm going to be using Advanced security and advanced Security's role is to help me identify security problems in the code that I'm going to be writing I'll, be using Code spaces and I'll, be using Code spaces in this environment to actually develop my code and interact with gab and codespaces is a development is a hosted development environment that allows us to Define our configurations as code and then finally we'll be using actions.

A

Actions is going to be there as that coordination, engine and compute engine that helps us to manage all these different tasks in this first demo, we'll use secret scanning to prevent credentials from being written in plain text to our GitHub repository. Let's go ahead and jump into our repo here, so I'm in my repository and what I'm going to do is actually open up a code space.

A

Now it's important to note that we actually don't need code spaces to get the same value here, but I'm going to use it because it's a much easier environment for me to work within so wait for our code space to open up here and once the container is ready and our IDE is available in the browser for us we'll go ahead and start. Introducing this token.

A

First, up I'm going to create a new Branch where I'm going to be introducing a new file, we'll call this branch conf and in this Branch I'm, going to create a new file called dot EnV within this file. What I'm, actually going to do is paste a token that represents an authentication token for me to log into an external service.

A

I really shouldn't be introducing this token into my repository, because again it's in plain text, and we want to ensure that this is not available to others across our organization. But in this situation, I accidentally introduced this file and I'm actually pushing it up to my repository. So I committed the file and I'm going to go ahead and push it to my Upstream repository, and what we'll see is that we get an error that pops up.

A

Let's take a look at this error So within here we can see that secret scanning and specifically push protection has. Let us know that, there's a problem. We can see where the secret exists in our repository and within our files, and we can also have access to additional information. That's provided by either our organization or GitHub as well. Additionally, there's this link that allows us to bypass this token or this specific block.

A

If we want to accept the risk of checking this token into our Repository in the second demo, I'll introduce a new SQL injection vulnerability into a code base that I'm working on code scanning is going to identify this issue for us, and it's going to provide an easy to understand guidance on how to resolve this issue quickly and allow us to move forward with developing this feature that we're working on so again, let's jump back into our Repository.

A

So just like the last demo that I was working on I'm, going to open up a new code space here, we'll go in and we'll create a new code space and again we're going to do our development within this environment. Here.

A

So we'll let the container fire up taking in our different configurations and building our IDE for us to work within.

A

All right, so our code space is now available and just like last time, I'm going to go ahead and create a new Branch where I'm going to introduce this SQL injection vulnerability.

A

So we'll create the new branch and we're going to name it name. Query name, query is actually the name of the function that I'm going to be introducing. So this will give us a really easy to understand location where we're storing this code we'll go ahead and edit the models.go file and using a little TV magic here, I'm going to speed through creating this function, but what's important is what's actually being done with this function? Specifically, this function called name. Query takes in input from an API and creates a SQL query without doing any parameterization.

A

It's using Sprint F to build this query in the go language. This is an unsafe method of introducing a change like this to our code base. All right so we'll go ahead and add a command message and we'll Commit This, we'll just push this up to our Repository and then once we get this published up to our Upstream Branch we'll go ahead and create a new pull request off of this.

A

So let's jump back to our repo and we'll jump over to our pull requests here, we'll select a new pull request and what I'm going to do is just select the branch that I'm going to be doing. My changes from in the branch where I'll be including the change to do a quick review of the modifications that we've got here and then I'm going to add a little bit of a description of the type of change that I'm making all right. So once we start this pull request.

A

What we'll see is a couple of checks that are going to be kicked off here and Behind. These checks and what's triggering these checks, is actually a GitHub action which is running behind the scenes. So, let's jump over to actions and take a look at what's actually going on here, all right. We can see that there's a workflow running and it's called add, name query.

A

This is code ql, that's running and it's part of the code scanning Suite, let's dive into it, and we can see that code scanning and code ql specifically is reviewing the source code that I introduce and it's looking for any errors in my Approach toward developing these features.

A

So, as we can see here, we'll go back into this pull request and we can see that there's a new comment here. What we can see is that we've got a comma inline from code scanning, which is saying that there's a database query which is built from user-controlled sources.

A

Let's go back over to our IDE and let's take a look at this comment directly in line in our code space. So we can see. Is that we're getting this same kind of feedback directly within our IDE? It allows us to make sense of where this vulnerability exists and where we actually need to fix this problem.

A

I want to get a little bit more detail about this issue that code scanning gave me. So what I'm going to do is actually click on show more details.

A

All right, so this is the information that's provided to us from code qo. So again, codeql was the one that identified this vulnerability for us. Let's click on show paths, so we can get a sense of what exactly is happening here. We can see that the source or the data where or the location where the data is input by the user is coming in from the r API.

A

We can follow that all the way through to the point where actually crafting the SQL statement, we'll go ahead and close this out and what we're going to take a look at now is the actual recommendation on how best to fix this.

A

What we can see here is that code ql is suggesting that we actually use a placeholder parameter instead of using sprintf to build this function.

A

Now that we know how we're going to fix this problem, let's go ahead and jump back over to our code space and let's actually fix this problem here.

A

Okay, so we're going to edit the models.go file and all I'm going to do is actually remove that Sprint F statement, I'm going to drop that out and I'm going to change our percent s. That was listed there and I'm going to just change it to a placeholder parameter, we'll go ahead and commit this change and we'll push this up to our repository again and we'll go ahead and kick off some more scans just to see if we were able to fix the problem that we initially introduced.

A

So if we take a look back at our pull request, what we can see is that there's some more checks that are occurring here again, we'll take a look at actions and just make sure that everything is operating. The way that we expect it to again we're just kicking off another code, ql scan.

A

Look at that workflow and, as we can see again, code kill is going through and it's doing its analysis of our application that we're we wrote.

A

All right so we're back on our pull request page and, as you can see, our checks are still running once these checks have completed, which there they are. What we'll do is we'll just do a quick refresh of our screen, and what we can see is that we've actually fixed this problem. So at this point we know that this pull request that we're introducing into our code base is free of defects and can safely be merged into our code base, all right.

A

So in summary, we use GitHub Advanced security paired along with GitHub code spaces and actions to identify some security vulnerabilities as early as possible in that software development life cycle, although that was helpful for you and I, really appreciate you spending some time with me today enjoy the rest of your time at universe.