GitHub GitHub Checkout, 13 Oct 2020

Previous Meeting

⏯

youtube image

►

From YouTube: View And Manage Your Dependency Graph - GitHub Checkout

Description

8:01 - Demo

GitHub dependency graph identifies all upstream dependencies and public downstream dependents of a repository or package. You can see your project’s dependencies and some of their properties, like vulnerability information. Hear Sasha Rosenbaum and William Barr discuss dependencies and see Dependency Graph in action!

GitHub Dependency Graph overview
https://github.blog/2020-08-04-secure-at-every-step-how-githubs-dependency-graph-is-generated/

GitHub Dependency Graph documentation
https://docs.github.com/en/free-pro-team@latest/github/visualizing-repository-data-with-graphs/about-the-dependency-graph

William Bartholomew:
GitHub - https://github.com/iamwillbar
Twitter - https://twitter.com/iamwillbar

Sasha Rosenbaum:
GitHub - https://github.com/DivineOps
Twitter - https://twitter.com/DivineOps

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 and welcome to github checkout today we're going to talk about github dependency graph and we're also going to show you a quick demo of the feature I am sasha rosenbaum a product manager at github and my guest today is william barcelo emil, barcelona. William, would you like to introduce yourself.

B

Sure I'm a product manager on the github supply chain team responsible for dependency graph.

A

Nice, so let's talk a little bit about what the feature really is and what it's all about.

B

Yeah dependency, graphs job is to give you the information you need about the dependencies that your project has so it analyzes all of your package manifests and works out exactly what you depend on.

A

So this is interesting. I've actually looked at software competition reports before and what it's showing me is that ninety percent of my code is actually coming from my dependencies and not from the business logic that I write, but it sounds really high to me. Is it really that high.

B

I I think it is. If you look at a lot of projects- and you think about you- know all of the things that are in there- you know the user interface authentication logging. You know all of these things that you need to make your application work. The vast majority of that isn't your business logic. It's just stuff.

B

You need to build a basic application, and so using all of those things from open source makes a lot of sense, and you know, as a result, we see the this large trend of more and more open source being used so that you can focus on that business logic.

A

Yeah, so I know that a lot of the software actually comes from open source and this is actually like solving problems right. So, like you mentioned right, I don't have to implement authentication on every single project that I have or like even like string parse or something simple like that right, but also there's some vulnerabilities that could come from open source right, so I could potentially consume something that I can't fully trust. So um can we talk a little bit about the challenges of consuming all the open source dependencies.

B

Yeah, absolutely I it's interesting dependencies. You know people tend to forget that they're code and you know it's no different than code. You would write in your own application and so these dependencies that you're pulling in have all of the same issues. That code you write yourself might have. You know whether it's vulnerabilities performance issues, stability bugs, um and so you know, keeping these dependencies up to date um know contributing back to them.

B

If you find issues is really important, and so you know it's it's easy to forget that their code, but it's important to you, know care for them um and you know, keep them up to date and all of those important things that you would do with your own code.

A

So you know what that's interesting like. I really like the phrase that, like all code, is technical, that right the moment you write something is out of date and there's somebody else who wrote a new package or something, and you need an update for this, um but so it's even harder when it comes to potentially um to my dependencies right, because I might not even know that a new new update has been pushed, or I might not know that it's important or it might not have backwards compatibility with what I'm doing right now.

A

So this sounds like a lot of work, and I know um a lot of people will just naturally avoid this work. Just because it's you know it's adding on to what they already have to do day to day. um So are we independency graph? um Can this work become easier for us.

B

Yeah definitely so I think, there's two parts to this. The first is people are relatively good with the direct dependencies they take. You know you go and find the open source project you're interested in, and so you add a dependency on to that, um but that one dependency can bring in you know dozens or even hundreds of other, what we call transitive or indirect dependencies, and so what dependency graph helps you with is analyzing.

B

What that full set of dependencies is knowing exactly what version you're using in your project and being able to provide that information to enable things like vulnerability alerts through dependable alerts or even automatic updates.

A

So that's fantastic! I can really gain insight, not just into like my direct dependencies, which I can easily see, but into all the vast open source dependency tree that like, I might not even know that these factors exist, but I'm indirectly, depending on them that that is very, very cool. So tell me more about how does dependable actually know what my dependencies are.

B

Sure so, every time that you do a push to your repository, that contains an update to your package, manifest file and so for, let's say you're using npm. That might be a package.json file where you've done an npm, install and you've said. Okay, I want to depend on express, and then you check in that file and you push it to your repository at that point. Dependency graph will analyze that and work out what the set of dependencies you are.

B

You you have and we'll capture that information in a graph where we link that dependency to the transitive dependencies, and we also work out where those packages originally come from, because a lot of open source is published from github. So we have that information about which repositories produce which packages, and we can leverage that to give you better insights into where all of your dependencies come from.

A

So is that just the sort of the package.json type files that you're analyzing.

B

Pretty much um so for each package ecosystem there's a set of files that we will analyze um so for maven. It would be you know the pom.xml file, if you're using yarn, we'll analyze the yarn file, so it is ecosystem dependent.

A

Cool and then um another thing is so, it looks like um dependency graph is doing a lot for me in terms of being able to consume um analyze my the dependencies that I consume, but do I get anything out of it as a package maintainer.

B

Yeah one of the interesting things that we do is because we have the information of who is consuming your package. Then we're able to show that information to you just for the public repositories. You know we're not exposing any private information there, but we can give you an idea of. You know how many people are consuming your package and we also have the ability to show that on the home page of your repository. So when someone comes in they can see.

B

You know this is being used by 1.8 million consumers, and you know that can help give confidence to someone that's considering to consume that package.

A

That's very, very cool. It also can be kind of like if I'm choosing an open source package to contribute to right. It can be a guide for me, like, oh, my god, there's so many people who are already using this. So it must be relevant and useful to folks. I was out there in the community, um so we've talked for quite a while, but feature I'm really excited to actually see it in action. So do you mind showing us a demo.

B

Yeah absolutely.

B

So I have a repository here that I have pushed some npm package manifest to. So if we take a quick look at the package.json here, um you know. Most of this is boilerplate that you would see in any um npm package, but you'll see.

B

I have one dependency on express version 4.4, and this is a private repository and if I go over to insights and then dependency graph you'll see here that we're not showing any of the dependencies, and I can opt in here very quickly and say: yes, I'm happy for dependency graph to do a read-only analysis of this repository, um but you can also enable this from within the repository settings under security and analysis, and the good thing about this is.

B

This is also where you can enable other security features for the repository I'm going to go ahead and just enable dependency graph at this time. So I've enabled that if I go back to insights and dependency graph.

B

There we go, what we've done is we've gone and looked for all of those manifest files within the repository.

B

If I scroll down here you'll see this is the package.json file that I just showed and we found that one express dependency for 4.4, but we also analyzed the lock file and the lock file gives us all of the information about the actual versions of indirect dependencies that we're using so you'll see. Even though we started off with you know, one dependency, we have 23 dependencies in the lock file and we now have the exact versions of those.

B

So if any of those had security vulnerabilities, then we could start to explore those and get more information.

A

I see and for that I'm guessing we're going to have to talk about depend about which we are going to do in the one of the next videos in this series right.

B

That's right and depending on what alerts, does the important you know, step of taking this information and combining it with github's advisory database to tell you which of these dependencies? Do you need to go pay attention to.

A

Fantastic is there anything else you wanted to show us here.

B

One thing I will show is you can drill into these dependencies to see you know kind of the next level dependencies as you go deeper and deeper into that those indirect dependencies and as you can see, this starts to fan out pretty extensively.

A

This is kind of incredible just to get an insight into how much other people's software I depend upon in my project, just from importing one one package.

B

Exactly and you can imagine you know how difficult it would be going and collecting all of this information manually working out whether each one is the latest version or not. You know going and searching for vulnerabilities, so.

A

Oh, my goodness, that that's impossible.

B

A

Yeah automation comes to rescue, um so this all looks fantastic and I'm sure our viewers are right now excited about this. So um can you tell us when, where we can go to learn more about the future and maybe play with it today.

B

Sure so you know the two things I would recommend is we have some great documentation up on docs.github.com um and the other thing I would do is go and enable this for your private repositories, so that you can see this data for your project and you know start to learn the ways that it can help you for yourself.

A

Thank you and we'll also, obviously put all the links in the show notes and as we mentioned before, this could be another video in the series dedicated to depend about and how you can actually leverage um dependable to also update your dependencies and and discover if you have any security vulnerabilities and things like that. um So please go ahead and click that subscribe button.

A

So you can stay tuned for more videos and thank you so much for being with us today and thank you william, for um both like talking to us today and also doing all the hard work that goes into delivering this uh feature.

B

A