 Today I'm going to show you how to create a software bill of materials or detect all of the software packages that are installed on your system, including their dependencies. The reason we would do this is to be able to find vulnerabilities in those dependent packages. That way we know what to focus on and where those packages are when something is vulnerable. So I'm in a Linux system and I'm going to get the SIFT software from Encore, it's open source on GitHub, and I want to click on code. And I'm going to clone their repository. I'm going to open up a command prompt and I'm already on my desktop. I'm going to type get clone and then download the repository. So now I'm going to CD into the SIFT folder that was created, type LS to see the directory listing, and I should see an install.sh file. So I need to do .slash install.sh to run that script. And then SIFT was installed into .bin sift. To LS, I should see a bin folder, LS bin. I see the SIFT program installed. Now it's not actually installed on my system. It's just in that folder right now, but now I can use this executable on any similarly configured system and then run SIFT from all of those different systems. So let's try to run it doing .slash bin sift and then dash H. Running the help menu is a good way to make sure you have the right version and that your program actually works. So we did get a help prompt and there's a lot of text here. You can see that there's a lot of different ways that you can run this to create a software bill of materials. It's really built for creating a software bill of materials on Docker images, but it also works for local file systems. We are going to output in JSON format, but the spdx format is compatible with some Microsoft standards. So we're just going to run a basic scan of the software that's installed in this Linux system that we run .slash bin sift. And then I'm giving it a directory. So I'm going to specify dir because it's the directory that I wanted to scan. And in this version of Linux, I'm going to scan the opt directory. Next, I want to put the output type as JSON formatted. And then I'm going to put the output file that I want to save all of this scan results into what I recommend is naming this file, whatever your computer's name is, and then saving them all into a single directory. That way you can load all of this information into a database or scan everything on your network at the same time. So we go ahead and hit enter. Now it's scanning all of the software that's installed in the opt folder. It will look not only at the software, but all of the dependencies that they can find related to that software. And I know I have some log 4j vulnerable things installed in here, so we should be able to find them once it's done. Once that's done, we have 4268 packages that it found. Let's go ahead and take a look at the output. I'm going to use cat against the JSON file that we just output and then more that way we can scroll by slowly. And you can see some of the artifacts, the type of artifacts that it found are, for example, MPM. So Java script related. And because this is JSON, it's really easy to parse out with a program. So you can see the structure of this as the packages, it has the versions of the package, where it found it, things like that. Okay. So let's go ahead instead of searching everything, instead of searching everything by hand, I want to know if I have a specific software installed. So let's look for the recent log 4j. And we do have a couple entries of log 4j installed. Now I don't necessarily want to go through and check all of these manually to see if I have a vulnerable version installed. I want to be able to kind of automate this a little bit. So I have my file saved on my shared drive. After SIFT, I'm going to get gripe from the same organization and gripe will take in a SIFT output and then scan all of those packages for vulnerabilities. So let's go ahead and get the source code for that. Open up our command prompt again, go back to the desktop, do get clone, download gripe, do cd gripe. And then now we're in the gripe folder. If I do LS, again, we have this install.sh file. So just do dot slash install.sh and gripe is really only for your analysis workstation where SIFT would be on all of your assets that are on the network. So I would run SIFT, maybe daily or weekly on all of the systems that are in the network. And then gripe, I would be scanning all of those outputs and then seeing if I had any vulnerabilities coming up. Now we have gripe installed in the bin directory. So to run it, I need to do dot slash bin gripe. We are feeding it a software bill of material. So I need to specify what type of file it is. So it's an S-bomb. And then the location was the shared folder. Now, whenever I run that, it's going to check for vulnerability updates, download any that you don't have and then start scanning our S-bomb for any vulnerable packages. So from the scan damage, we have 1,753 vulnerabilities detected and quite a few of them are critical. So we already have some software that is not log4j that has critical vulnerabilities, whatever those means, quite a few high and then quite a few medium. Let's go ahead and use gripe to check the S-bomb again and see if we can just find anything related to log4j. And you can see that we have actually quite a few references to log4j. This doesn't tell us the locations, but we can see the software that's being used. Vulnerable versions of log4j are definitely included in the software that we're looking at. Okay, so to find out which packages actually contain the vulnerable software, we don't output the summary of vulnerabilities. We have to output the details of them. We output the details by using the JSON output format and slash been gripe S-bomb and then our S-bomb file output and JSON format. And then I'm going to grep for log4j that way I can find any vulnerable version. I'm going to grep for the path of the vulnerable version that I'm looking for. Okay, so we have some results and you can see that autopsy written in JavaScript uses log4j quite a bit. Autopsy has already pushed out updates using fixed versions of log4j. So make sure you do have the newest version. And this will tell us where everything is. Now we can scan all of the systems on our network once a week or so, save that software bill of materials into a central repository and then use gripe to scan that central repository and detect any vulnerabilities. Then we'll know that the system that is vulnerable and where those packages are located on that system, rather than just guessing where everything's at. This will help us to focus in our investigations. And if you're a consultant, for example, you can scan for log4j vulnerabilities or you can scan and give an entire S-bomb back to your client and say, okay, log4j is included in these. Here are the vulnerable log4j instances, but also consider that you have a lot of other software that's also a dependency that's also vulnerable, maybe not to the extent that the log4j was, but still we had some critical vulnerabilities in dependencies that were detected. So that would be much better value to your customers, giving them a whole S-bomb plus the vulnerability list. And then you just have to be aware about giving them too much information and information overload. Make sure that they know what to do with that. So that's it for creating a software bill of materials in Linux systems. This also works for macOS, Docker, any type of container system that you can run it directly on directories. You can run it on remote systems. There is also a version for Windows. Thank you very much.