Transcript:
One of the important things that Deepfactor does that truly distinguishes Deepfactor from other static SCA-only tools is that it then starts correlating the container image that was scanned on the left, or the artifact that was scanned on the left to whether it is running in your running environments. Whether that’s production Kubernetes environments, or dev and test environments, so on and so forth, depending on how you configure it. In this case, it is telling me that this particular component that belongs to Bank of Anthos is actually running, or in this case it’s not running, but this was running in a specific Kubernetes environment and therefore correlating it automatically.
This is a summary of what you see in the artifact section, very similar to what you would see with static SCA tools, but it essentially combines SCA for open source image scanning, container image scanning, and software bill of materials creation into this section of the UI.
Now, let’s jump into the application section. We’re going to jump into this application called Bank of Anthos. This is an application by Google. It’s made up of nine microservices and it’s composed of various languages. If you look at what Deepfactor has found on the right… This Bank of Anthos application, by the way, is running in Kubernetes in a Kubernetes environment, and that namespace is being watched by Deepfactor because we installed the Deepfactor Kubernetes book, if you remember the first part of this demonstration.
So now if you go to the summary section, Deepfactor is already detected that this application is composed of nine microservices, and there’s one active incentive that is running in a certain namespace. It’s made up of these languages, Java, Python, and C. It has this many vulnerable dependencies and this many vulnerable OS packages in the container image. It’s listening on this many ports.
It has this many web services, so on and so forth. That’s a quick summary of what Deepfactor has detected in this particular application. Now, if you go back to this dashboard, there’s two panels on this dashboard. The panel on the left shows you runtime enriched software compilation analysis, and SBOM information. The panel on the right shows you runtime security alerts that potentially determine violations or insecure behaviors that this application has been demonstrating and how that may affect certain compliance frameworks that you may care about. So let’s talk about for the purpose of this demo, this left pane, which essentially correlates the application’s runtime behavior to determine which of the vulnerable components are actually loaded into memory. Here we’re going to talk about two subsections. One is container scans, which is the OS packages that are installed in the container image, whether they’re used or not.
And number two is we’re going to talk about dependencies. In this case, we’re going to talk about specifically Java, take data as an example and show that whether that is used in memory or not. Let’s look at the OS packages. So in this application, as we see here, there are nine components. So that’s nine microservices that make up Bank of Anthos. Together, they have 527 plus 42 vulnerabilities. Normally, an AppSec team would take this list of vulnerabilities and then apply severity filter to it, and then go to the dev teams to have them fix these vulnerabilities, and that results in a large number of vulnerabilities that you’re throwing at your developers.
Now, Deepfactor, what it’s doing is it’s showing a Venn diagram that essentially says there are 527 plus 42 vulnerabilities. However, if you look at the blue circle and focus only on the intersection, only 42 of them are actually loaded into memory and used at runtime. As Bank of Anthos is running for, in this case, two full days, we noticed that only 42 of these packages were actually loaded. If you want to now go to the SBOM page, and I’m going to click on the OS packages section.
Let’s double click on this. So basically what we’re seeing here is there are 1,336 packages, as you’re seeing on the right side. Out of them, if you filter based on vulnerable, you get that 569. If you apply a severity filter to it and look at just the P1s and P2s, then you’re still looking at 200 and something vulnerable components that you are going to pass on to your dev team to fix. But if you apply the used filter, you’re able to bring that significantly down almost by an order of magnitude, and that helps you reduce the number of things that you’re showing to your developers.
In this case, the way the usage is tracked for each of these components is down to the level of which shared objects and which file or executables that belong to that package are actually touched or loaded by that application. For example, the libc6 package is flagged as a used package because these are the shared objects that belong to this package that were actually loaded into memory or opened by the application over the course of the two days that the application was running.
Now let’s switch to dependencies. In this case, let’s focus on Java. What we’re seeing here is that there are 39 vulnerable components that are not loaded. There are 48 vulnerable and loaded components. So instead of focusing on this entire red section, you need to focus on this red and black section first because that is the most important section because these are vulnerable components that are actually loaded into memory. Now, there’s a bunch of other components that are not used as well. So one is probably wondering why those components are not used by the application. So the AppSec team actually can go back to the dev teams and try to have an intelligent conversation about the fact that there’s a bunch of unused components in their applications that may need to be remote. If you go back again to the SCA and SBOM and focus on the dependencies this time we see that there are 86 dependencies that are vulnerable and have fits and highs, but if you filter out based on loaded, these factors, able to filter that down to 39.
So it’s a much smaller number that you can share with your developers. A good example here is to go a little deeper here is our friend Log4j. So if you look for Log4j, we see that Log4j is actually presented in this application, and we see here that it is loaded and it is vulnerable, so it’s important. However, just because it’s loaded in memory sometimes doesn’t mean that it may actually be vulnerable. So Deepfactor gives you that one more additional layer of check, which is there a class that belonged to Log4j that was actually loaded that could be vulnerable?
So if you click on this and you look at usage here, Deepfactor is able to identify that 522 classes that belong to Log4j were actually loaded in memory as the application was running for two full days in this case. So if the CV happens to have the information about whether a certain class or method has that vulnerability, some CVs do, some CVs don’t, but if the CV does, then you could certainly filter by that to understand whether this vulnerability is of immediate threat to you and whether you should immediately jump on trying to fix it.
One last example to complete the story here is, I’m not sure if you guys remember that we had an OpenSSL vulnerability last Thanksgiving, 2022 Thanksgiving. So if you look for OpenSSL, in this case, this Bank of Anthos application has seven instances where OpenSSL was actually present and it is vulnerable. However, if you look at the usage column, none of these OpenSSL components are actually loaded in user memory. So if you are a forward-thinking AppSec organization employed with this additional piece of data, now you can go back to your developers and say, “Hey, look, there is OpenSSL, but don’t panic. You don’t have to ruin your Thanksgiving just to fix this vulnerability now because we know that it’s not being used by your application because we did a usage analysis on this app with Deepfactor, and you can come back after your Thanksgiving break and fix this. You don’t have to fix it right now.”
This additional piece of usage information not only gives you reachability aspect of it, but it also tells you whether… It gives you a much more mature way of thinking about zero days and how you handle those zero days when something new were to pop up. Thank you for watching this video. Any questions, contact the Deepfactor team.