GitHub GitHub Universe 2020: Developer - Secure Development, 9 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Catching vulnerabilities early with GitHub - GitHub Universe 2020

Description

Presented by:
Maya Kaczorowski, Product Manager, Software Supply Chain Security, GitHub
William Bartholomew, Staff Product Manager, GitHub

"Shifting left allows development teams to implement security controls earlier, thus helping your team catch issues earlier, too. In this talk, we’ll first cover what your supply chain is, including everything you need to know about the dependencies you pull into your software—including information on their vulnerabilities—to determine your risk profile. We'll then dive into what GitHub can do to help you address vulnerabilities in these dependencies and alert you when new vulnerabilities arise using Dependency Graph and Dependabot. Then, we’ll delve into new updates that will help you shift left starting today.

https://githubuniverse.com/developer"

For more from GitHub Universe 2020, visit https://githubuniverse.com

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

Hello welcome. Thank you so much for joining us today to talk about catching vulnerabilities early with github, I'm maya, kaczorowski, a product manager at github, working on software supply chain, security.

B

And I'm william bartholomew, also a product manager at github, working on supply, chain security.

A

So today, in this session, we'll cover a couple of different topics.

A

First, what your supply chain is, including everything you need to know about the dependencies you pull into your software, such as information on their vulnerabilities, in order to determine your risk profile, then we'll dive into what github can do to help you address vulnerabilities in these dependencies and alert you when new vulnerabilities arise, using dependency graph and depend about and for the main attraction today I'll hand it over to william to delve into a new feature that we just demoed in the keynote this morning. That will help you shift left starting today.

A

Dependency review we'll cover what dependency review is, how it works and how it can help you shift left. So, let's get started if you're unfamiliar with the term software supply chain. It's used to refer to everything that goes into your software and where it comes from, and what is that it's dependencies, your software supply chain depends on well your dependencies as well as properties of your dependencies and what is a dependency. A dependency is another binary that your software needs in order to run.

A

This can include both binaries required when building the application, often called dev dependencies as well as binaries that are actually used at runtime. A dependency enters your environment when a developer specifies it as part of your application in a manifest file where dependencies are declared or log file, where particular versions of dependencies are specified.

A

Dependencies can also be included transitively, so a dependency of your dependency is also your dependency.

A

The thing is dependencies can be risky, they're, not code, that you wrote, you don't really know what's in them kind of like you, don't really know. What's in that 2 a.m, shawarma from the place around the corner, it seems fine, but you never know so. One particular piece of information developers should pay attention to is vulnerability information if your dependency has known vulnerabilities. Well, maybe you should update it to a patched version. However, not all vulnerabilities are properly disclosed or patched, and there are other potential risks to using a given dependency.

A

Other security risks that make it more susceptible to being attacked or harder to detect an attack, legal and compliance risks for using a dependency in a way. That's not in line with the specified license, maintenance risks if a dependency is no longer supported and you don't have a viable alternative and other risks as well, so to make the dependencies that you pull in less scary.

A

We want transparency as to what's in them, so that you can be confident in what you're consuming this means means that you might want to know for a given dependency, who wrote it when it was contributed. How it's been reviewed for security issues, any known, vulnerabilities, supported versions, license information everything all of these things help you determine your risk profile, but that's just a given dependency and the reality is you probably have a lot of dependencies.

A

Software dependencies are pervasive, it's normal for your project to use hundreds or even thousands, of open source dependencies. The developer didn't write themselves from the latest state of the octoverse report. We know that anywhere from 65 to 94 of active repos rely on open source code with the variability depending on the ecosystem, and that, although, although the median active repo might only have a handful of direct dependencies, it has many hidden indirect dependencies with javascript being the clear winner with a median 683 transitive dependencies whoa, so so many dependencies.

A

So what can you do on github today, if you're using github? There are several features you can take advantage of to improve the security of your dependencies.

A

um We have uh first, you need to know your environment, so you need to understand what dependencies you use and manage your dependencies. That is know about vulnerabilities in those dependencies and patches, so you can address them, really be quick to discover it and react to it on github to know your environment use dependency. Graph dependency graph identifies all upstream dependencies and public downstream dependence of a repository or package and items are automatically added to the dependency graph.

A

When you add a new dependency and to manage your dependencies, dependable alerts notify you of repositories affected by a newly discovered vulnerability to do. This, github compares the information in the dependency graph to the information in github's advisory database.

A

A dependable alert can either be sent when you added a new dependency um or when a new vulnerabilities is covered in an existing dependency that you have dependable security updates will send you a pull request to update a dependency to the minimum version that resolves a known vulnerability.

A

This is done automatically based on known vulnerabilities and known patched versions by suggesting a change to update packages in a lock file, and, lastly, dependable version updates keep your dependencies up to date, even when there isn't a new vulnerability by checking for new versions on a configured schedule.

A

Dependency graph, dependable alerts, independent about security updates, are all on for public repos by default and so putting it all together. That means that, instead of having to identify, examine triage, the vulnerabilities independencies yourself with these features with dependency graph, dependable alerts and the pen about security updates enabled managing a new vulnerability is as simple as merging prs from dependable now. That sounds too good to be true right.

A

Well, it isn't really it really is that straightforward, but please still be cautious review the content of your pr's. If the patch requires a major version, change you'll want to ensure it's still compatible with your environment. The most important thing to do here is to please please run your normal test suite against these changes to ensure that they will work, and you might also have to wait to patch and to avoid interrupting any operations that you have going on. So it's not always as straightforward as you'd like it to be.

A

Our goal here is still to help you find and patch vulnerabilities faster and the reality is, and I'm happy to say it's working from the latest state of the october report. Again, we know that repositories using automation, define and address vulnerabilities, like dependable security updates, remediate those faster where a repository automatically generated a pull request to update to the fixed version. They patched their software in 33 days, which is 13 days faster than those who didn't that's for meeting and remediating an issue 1.4 times faster and by automating patch management.

A

You can focus your team's resources where it really matters for simple patches, there's not much to do fine and for more complex patches. They can now spend much more time validating an upgrade and ensuring that your systems make the change safely. This makes it easier and safer to integrate fixes into your environment.

A

So what we've been talking about so far are remediations and dependency management.

A

After the fact, once you already have a dependency but there's an ongoing trend in devops to shift left to move processes earlier in the development life cycle, where development teams are so they can take action, and a developer-centric approach means that developers can stay in context and respond to issues when they code, not days later at deployment time or worse months later, from a penetration penetration test report by moving steps like testing, including security testing, from a final gate at deployment time to an earlier step, fewer mistakes are made and developers can move more quickly.

A

Dependable already helps you a little bit with that today. It not only warns you about a security issue in your repos dependencies, but it does send you a pull request to respond to. That means that, instead of a vulnerable dependency being an issue for the security team to follow up on it's a pull request for the development team to review.

A

But all this thinking about shifting left, let us a github to think what. If we could tell a developer in context what they needed to catch these vulnerable dependencies before they're introduced to begin with. So, let's welcome back william to show us how that's possible on github now.

B

Thanks maya fire has just shown us why it's so important to manage your dependencies and some of the features that github provides to do. Just that, I'm going to show you our newest feature dependency review, which helps you shift dependency management left.

B

So what is dependency to review dependency review? Lets you easily see changes to your repositories, dependencies and the vulnerabilities in those dependencies when reviewing pull requests.

B

If you've ever reviewed changes to a dependency manifest file such as a package.json or package.json, then you know how difficult it can be to see exactly what changed. People aren't great json, xml or even yaml parsers, and we shouldn't expect you to be once you've worked out. What's changed? Do you go one by one and look up every dependency to see if it has vulnerabilities?

B

Probably not as this isn't practical at scale, especially if you consider transitive also called indirect dependencies if you're a savvy github user, then you may have turned on dependable alerts to alert you to vulnerabilities in your repository's dependencies, there's no fun for anyone merging a pull request. Only then to find out it introduces a new vulnerability.

B

If someone introduces a new dependency, what do you know about that dependency? Is it commonly used? How is it licensed? So, let's see how dependency review helps solve these problems with a.

B

B

Okay, so here I've got a pretty standard, express application that I generated using express generator and we're going to take a look at some of the pull requests that are in this repository.

B

So if I jump over to the normal pull request, tab like I would, when reviewing any pull requests, I'm going to pull up this first pull request, which is you know, updating, looks like we're going to output operating system in front of the console when the server started. So I'm going to jump over to the files, change tab and take a look at the changes.

B

So this all looks pretty innocuous. You know importing a module calling some code. Then we've got the changes to the package manifest themselves.

B

um So if we look at the package json first yeah, I can see that the um version of system information or this new package has been introduced. uh But it looks like this didn't change. It's marked as a diff, but it looks like there's just an extra comma there.

B

So, let's switch over to dependency review to see if it can give us a clearer view of what went on here and so here I can see at a glance that you know a new dependency was added and this was the version range, but I can also see that this particular version has a couple of vulnerabilities, and so I might want to look if there's a newer version.

B

I can jump in and take a look at the advisory to see what's going on um and if I take a look at the package lock here, I can see that you know this diff is complex enough that it's not rendered by default.

B

But again I can jump in and see the details here and I can see you know ten point. Ten point: seven thousand repositories depend on this particular one. Now, if I jump over to another pr, let's see what happens in other scenarios.

B

So if I look at this particular one we'll go through the same workflow, you know we review the code again, pretty simple change, just adding a new dependency.

B

Oh again, we can see there's a vulnerability, but let's take a look at the diff for this one.

B

In this case, the diff was a lot more complex. You know this particular package has a lot of dependencies and we can go through and see what those transitive dependencies are, how they're licensed what they depend on and vulnerabilities that are being introduced by those indirect dependencies to decide whether you know this particular pr is something we're willing to accept, or do we want to work with the contributor of the pr to upgrade those dependencies.

B

The final scenario I want to show you here is an update to a dependency, so in this case this was a dependency that the project already had.

B

If I take a look at the files changes again, we can see if this is a major version change. um So we can expect there to be a fair number of changes here again. The dependency reviews giving me that at a glance here, here's exactly what changed.

B

If we take a look at the package block json here, we can see that there's a lot of diffs in this json file. You know, there's almost 20 000 changes in total um 4 000 editions, six, almost 16 000 deletions.

B

This probably isn't something where we want to review the json changes. So, let's see, if defensive review is helping us here as well, so I'm going to switch to the rich diff and again we get that very clear view of you know this particular version was updated and has a dependency.

B

I can see all of the individual dependencies that were added. If I want to. I can click through to see the repository that produces that particular dependency, and in this case I can also see if I scroll down um dependencies are being removed. So I can get that at a glance. Feel, for you know, is what is the overall impact of this.

B

So, jumping back to the presentation for a minute.

B

B

um Now that you've seen it in action, let's take a look at how it works and we'll start with a typical pull request. Workflow, that reviews commits between a topic branch and a compare branch with dependency review. We extend this to generate a dependency manifest.

B

For both branches, these dependency manifests are generated by github's dependency graph. The same one that shows dependencies on repositories and powers depend upon alerts.

B

Once we have those dependency.

B

Manifests we then compare them to work out exactly what changed and pull in additional package metadata, which is then displayed in the rich diff in the pull request, this process updates whenever the pull request is updated or the destination branch is updated, so you'll always always understand the impact of a pull request on dependencies and what's great about dependency review is, if you have dependency graph, already turned on there's no additional onboarding or configuration to have dependency review work in your repository.

B

So how does this work with defendable alerts so why? I spoke earlier about defenderbot alerts, and this helps you react to vulnerabilities that already exist in your dependency manifests or when new vulnerabilities are discovered in existing dependencies that you have, it will also catch changes that are pushed directly to the repository dependency review, helps you shift left catching vulnerable dependencies before they're introduced, as well as giving you more context about those dependencies. They're complementary and you should use both.

B

Github provides other ways to shift left.

B

You can use code scanning to run static analysis, including code ql, but also any code scanning tool that outputs industry standard, serif, dependerbot version updates, will help keep you on the latest stable version of your dependencies, which can help avoid undiscovered vulnerabilities and take the pain out of having to upgrade across many versions.

B

When a new vulnerability is found, you can use actions to run, build test or other automation on pull requests to validate changes and, of course, you can use protected branches and check suites to ensure these requirements are met when merging into specific branches.

B

Dependency review is currently rolling out for public repositories, so if it's not already there, it will be over the next few weeks to see it in action when reviewing a pull request that modifies a manifest file. Click on the rich gif to get this streamlined review experience that will also highlight known vulnerabilities.

B

If you'd like to learn more about defensive review or some of the other features we've talked about today, please check out these things. These links we'd love to hear your feedback as well, so keep it coming, and thank you so much for joining us to learn about supply chain security.