4 hours 39 minutes
Welcome back to lesson 4.4. Where we're gonna talk about software composition analysis. This is the last topic. We're gonna use this in combination with static analysis so that we understand what what we need to test or how we're gonna test our source code and weaken jump into the demo in the next module.
So for lesson objectives which would discuss supply chain security, which is related to weaknesses and third party libraries
examine the need for review and external modules. And also take a look at what that lost the dependency check tool reports.
So by supply chain,
it's related to Thea s e A so specific to say, like Java has as a maven. Libraries dot net has new get Piketon Python has
pip node has the NPM. You might be able to take
libraries that are out and get. And so any of these public libraries you can. People have already built
methods or libraries that are useful for your application instead of redoing it or reused, rewriting it your own in their own way and maybe making some new errors. It is a lot more efficient to take these libraries, but the same time we need to keep them up to date. We need to perform some reviews on them before he just
inject this code that somebody else wrote into our application
and the same thing. If you're looking at containers, Docker Hub has the ability has these built images out there and you could just say I want Tomcat or I want whatever else and I could just download this and then I dropped my application in there. How
effective are we? How efficient are we actually going through and reviewing what is in this container
to? We'd be doing that. She would be having our own internal trusted repository, which is another one of the NIST s S D f
requirements. That's PW, that force and you should be. You should have a trusted internal repository instead of just pulling these containers from external public sources that who knows who have edited them.
So when I have a gin, there's another one. This is peter be 10.3 requirement for SST fto Be reviewing this supply chain and just gotta looking at this from the perspective of a threat. So I mentioned python node Ph b all have their own
public libraries out there where you can just download.
And sometimes there's the libraries are pulled in without even reviewing them.
So there's this article here about are the 1st 1 you could take a look at where crypto currency clipboard hijacker was discovered in the pipe. I repository if there for a while knows how many people got affected by it.
The second article about there's 20 libraries is interesting research that somebody that a couple people did. They looked all the libraries, and if you understand how, so you might have a library, which and then you have somebody else creates a new one and they inherit the other one, and somebody else takes Makes a new one. Inherit that one, and you can't even you may not even know that hierarchy.
And so what the researchers did was they looked at all the libraries,
looked at the dependencies across him and found that there were 20 core libraries that were that inherited 50% of the ecosystem, which means if you are malicious actor out there and you're able to compromise all 20 of these or some portion of that,
you could compromise 50% of the libraries out there that that are being in inherited and used in people's code.
Which is pretty scary, though,
and there's another.
It's funny, but it's also it was worrisome. The last article there you can see reference. It says 11 lines of code broke the Internet. There was this very small code that all it did was patting whitespace, but it was very helpful. It was It was amazing how many people inherited use this.
There was some dispute. You can read the story.
The developer took it off line, and the Internet pretty much broke. It was it was amazing that this 11 lines of code just destroyed everything.
Three objective of why we're doing this. We've seen Equifax with Apache struts. There's a Seuss breach where somebody actually broke into the supply chain or the right there where they stored their application
and were able to digitally sign, upload, applicator our upload code into that which was entrusted by a suits computer. So this is the idea behind third party libraries, but also protecting our supply chain.
So what mitigations are reviewing? Third party libraries regularly
don't do things like
pit, which is in python install. Uh, recursive Lee all the requirements, and you would if you ever run this before. It might be easy if in your personal life are you doing this. But you install it and it just pulls all the dependencies for you, pulls them all in, and you have no idea what happened so far.
Enterprise application. We should be really reviewing every one of these libraries and figure out what's what's going on.
Here's the OAS dependency check tool, which is an amazing tool, and you'll see it the output from it.
When we do the Jenkins demo, it can pull that and directly into your build.
Here's an example, right? I put in the end zone application and just ran it, and you can see it's it says. I see it. I see all the libraries you're running, and then it runs it against the Envy D database
that it pulls down every every new one that that's out there. And it says, I see what version you have. And here's the risk associated with that being the 1st 1 has won high risk.
The 2nd 1 has six. There's critical, So any of these third party libraries really need to be upgraded or you're injecting vulnerabilities directly into your code that you didn't develop.
So we talked about the importance of software competition analysis in this module and supply chain. Although all those ideas next we're finally have enough information. We can run the Jenkins demo and run against our Java vulnerable lab and run their these static analysis and SC A tools.