Welcome back.
Let's keep going down our security
guidelines and go with our second third party libraries.
Let's see what that's all about.
You see, as our applications grow, we
depend on more and more third party libraries.
And you can see that right away if you go
into any project and look at their node modules folder.
We use a ton of code from other people and that's not a bad thing.
We don't want to keep writing our own functions, our own solutions that have
already been discovered.
The idea of npm is to be able to share
code with other people so we can build applications faster.
I mean, look what create react app can do for us.
Now, when that happens, you encounter this other problem where once again
you're using code that you didn't write yourself and that perhaps might not be
the most secure.
And when it comes to third party
libraries, you always want to make sure if you're adding it to your project that
it is a good library.
It's a library that you can trust and
it's a library that is secure.
Because anybody can load up any package
that they want on npm.
And if I'm a bad person, I can perhaps
load a really bad library that says it helps you with one problem but actually
collects user information perhaps or maybe your logging outputs.
So you always want to be careful with third party libraries.
Now, luckily for you, there's a fairly good system that you can implement.
And that is just make sure you go to their github page of whatever third party
library you're using and look at their stars and how many times they've been
forked and generally the big community around it
.
You can trust big libraries like react or
redux because, well, they're developed by companies that you can trust.
Well, kind of you can trust.
But they also have a lot of stars on github.
A lot of people are working on it and a lot of open source community time has
gone into it in order to make it better and safe.
So use packages that are well known, well respected, and that are constantly being
worked on.
Now, I want to show you two things that
you can do right away to really improve your security practices when it comes to
third party libraries.
And that is these two tools, the NSB and
the SNIC.
I think you say it's SNIC.
I'm not sure how it's pronounced.
But we're going to show you how these
work to check your third party libraries.
I have over here our robo friends
progressive web app.
And in here, let's make this a little bit bigger.
I'm going to install these two packages that I just talked about.
npm install -g for global so that I can use the NSB command and hit enter.
Now, this is probably going to give me an error.
There it is.
You're going to get an e -access error.
You have the permission denied.
Again, if you're getting this error, that means you don't have permission to
install a global package.
So sometimes you might have to do pseudo
or run the command in admin mode.
So let's do that with NSB.
And you'll have to enter your password.
Make sure you are who you say you are.
And you have your package installed.
So NSB, what can we do with it?
Well, we can run a command called NSB check.
And it's going to check our robo friends PWA.
Let's see what it does.
Uh -oh.
Looks like we have one vulnerability.
And NSB check is awesome because it gives
you great information on where your issues are.
You see, people are constantly finding vulnerabilities in code and how they can
do bad things with it.
And good people are always trying to fix these.
And that's why you have on your iPhone or your Android phone constant updates
because companies are constantly updating software in order to be more secure.
If somebody finds a vulnerability, they need to fix that right away because all
the attackers are going to be like, ooh, there's a new vulnerability.
I'm going to try that out and see if I can do bad things with it.
So always, always update and have the latest software updates because most of
the time there are security updates to avoid these type of vulnerabilities.
And with NSB check, we see that, yeah, we have a package that is named hoke, hoke, hoke.
I don't know how to say that.
And you see that it's a medium level.
We have the 4 .2 version installed.
And the vulnerability affects all things
that are 4 .2 or below.
And then it shows you what the patch
version is and also what is using this package.
And we see that the RoboFriends app, the
hoke package is used by React Scripts, Jest, Jest .ly, Environment, JSDOM,
Request, Hawk, Hoke.
So it's being used.
You can see the nesting that's happening here.
So even though we don't directly know
about it, it's being used by JSDOM that uses the request and that uses Hawk that
uses Hoke.
And also it gives you information on
where you can find more details about this vulnerability.
And if we actually go to the Hoke website, let's do Hoke NPM, we see that,
oh, yeah, there's a newer version, 5 .0 .3, and that we definitely have an
outdated version.
Very cool.
So we might want to update that by changing our package .json file to a
newer version or perhaps just using the npm install command again to reinstall
whatever we need.
All right, what about the other tool I
was talking about, the npm install -g, but this time it's called Snyk.
We're going to go with Snyk.
And this tool is going to require you to
actually connect your GitHub account.
That's because with NSP, we're auditing
our package .json file.
Snyk is going to audit your node modules
directory using this Snyk test command, and this is a really, really good tool.
So if we run, let me clear this.
If we run Snyk test, you see that we need
authentication account.
So we need to connect it to our GitHub account.
So I can do Snyk auth, and I'm just going to log in with my GitHub account.
I'm going to authorize it.
Yeah, sure, we'll agree.
All right, we're ready to be used.
So let's go with Snyk test.
All right, we have to run npm install first.
And again, because I just git cloned this
package, I haven't run npm install, so there's no node modules folder yet in
this project.
But the NSP was able to run the test
because it tests the package .json file.
All right, so let's just run npm install.
All right, and now let's run our command.
I'm going to clear this, and we're going
to rerun Snyk test.
And while this is running, it's going to
run a ton of tests.
There are other tools like this out
there, but the idea and the end goal is always the same.
Make sure that the third -party libraries that you're using are always up to date
and that you're not using any packages that have known vulnerabilities.
And there's a ton of information online about how to find those.
All right, we're testing.
That's a lot of dependencies, 1 ,049
dependencies, and found 13 vulnerabilities with 528 vulnerable paths.
Holy moly, that's a lot.
And it gives you a ton of output.
It even gives you information of how you can fix this.
You see that your dependencies are out of date.
Otherwise, you'd be using a newer
ToughCookie than ToughCookie 2 .3 .2.
Again, it says try deleting no module and
reinstalling and running Snyk test again.
And if the problem persists, and it
probably does because we just installed this, one of your dependencies may be
bundling outdated modules.
So again, you might have to go ahead and
fix that and install new packages, but you see that we have a ton.
And here's the thing.
There's definitely, when you run this,
it's very rare that you're going to get 100%, but at least now we know where to
start and where to perhaps update our packages.
The problem with some of these is that
the ToughCookie package, for example, is needed by the request package.
And perhaps if we update the ToughCookie package, the request package won't be
able to work with the newer version of ToughCookie.
And you know what?
That's one of the big problems with NPM and having these really deep nested
dependency trees.
And there are many discussions online on
how to solve this and what the best practices are.
But I hope by using these two tools, you can decide for yourself what you want to fix.
I hope this has taught you that you have to be careful of all these packages, and
it's good to have these tests running, and perhaps as a team decide when to fix
something and when to not include a third -party library because of a vulnerability
or when you should.
I'll see you in the next video.
Bye -bye.