ThreatMapper picks up where Shift Left ends

Michelle Brinich
Michelle Brinich
ThreatMapper picks up where shift left ends tutorial

Shift left, secure right. Shift left initiatives empower developers and DevOps teams to deliver secure code to production. Once code has been deployed, shift left steps back and ThreatMapper takes over. We recently announced that ThreatMapper is now 100% open source. In this blog post, we explain what ThreatMapper is and how to get started. 

Why do organizations need ThreatMapper?

A large majority of modern applications rely significantly on open source components and third-party dependencies. For example, it’s not uncommon to see 90% of an enterprise application’s code base made up of open source and third-party components vs. 10% built by the enterprise’s developers themselves. But when you push your applications into production, you are responsible for the security and the integrity of the entire application, not just the 10% created within your organization. Here are a few real-world data points to better explain the problem of securing your software:

The industry’s response to this problem of securing software has led to what is now known as the shift left movement, where the responsibility of building secure applications and testing for security moves to the development team as far left as possible. The challenge the development team faces is to scan and secure their applications as early as possible and fix bugs as soon as possible so that when the application is pushed into production, it has been tested and is as free as possible from known vulnerabilities at that time.

However, the shift left movement, extremely valuable as it is, is not enough to secure modern applications. There are many limitations if you stop at “shift left” as the solution to the security problem, including: 

  • Not all vulnerabilities can be patched before production.
  • A late breaking vulnerability may not have a fix. 
  • A fix may be too costly to integrate and test. 
  • The engineering team may make a very qualified, and sensible decision, that a particular vulnerability is probably not exploitable and are comfortable with that vulnerable code moving into production at that time.
  • Not all third-party resources on which your application depends can be tested before moving into production. 
  • Network technology, ingress controllers, and, third-party plugins such as for monitoring or log handling or alerting, or indeed the infrastructure itself that you deploy your application code onto do not typically get the same level of scrutiny that your own application does through a shift left process.  

But nevertheless, all of the above examples are potential ingresses for attack against your application. And most importantly, vulnerabilities continue to be discovered at an alarming rate in production.

Here’s a summary of why shift left only addresses half of the problem:

Furthermore, on the right side, the application security team are sitting at the end of the pipeline with responsibility for the production systems, looking for vulnerabilities and weaknesses. When we talk to AppSec teams here at Deepfence, typically they are able to identify tens of thousands of potential vulnerabilities across their entire infrastructure, including hosts and containers. With the immense volume of vulnerability data, a very important question arises – how can you prioritize vulnerabilities and give the Dev and DevOps teams the specific and actionable information they need to reduce your attack surface as quickly as possible? This is where ThreatMapper comes in!

ThreatMapper in Action

Visualize your running services, K8s pods, and third-party APIs

ThreatMapper provides security observability across your production infrastructure and multiple modalities – including workloads spread across multiple clouds, container images, hosts, Kubernetes clusters, namespaces, pods, VMs, third-party services like RDS instances, and more. ThreatMapper enables you to visualize everything you have running within your infrastructure.

Within ThreatMapper’s main dashboard, there’s a graph view and a table view that you can toggle in the upper right hand corner of the main dashboard. Both views scale to several thousands of nodes to accommodate sizable environments, and enable you to dig deep into your infrastructure, from cloud to regions, to hosts, all the way down to your processes. Here you can see the main ThreatMapper dashboard starting at a high-level view of your multi-cloud infrastructure:

Visualizing a multi-cloud infrastructure on the ThreatMapper dashboard

And here’s an example showing that you have visibility all the way to the process level, shown below:

Visualizing all the way down to the process level on the ThreatMapper dashboard

Scan builds and registries for vulnerabilities

In addition to using ThreatMapper to visualize your running services, K8s pods, and third-party APIs, ThreatMapper can also scan image builds in your CI/CD pipelines, supporting CircleCI, Jenkins, and GitLab. You can even use ThreatMapper to scan registries for vulnerabilities, too, to review workloads before they are deployed.

Here are some popular registries that ThreatMapper can scan:

Examples of registries that can be scanned for vulnerabilities with ThreatMapper

Scanning registries with ThreatMapper comes with a lot of flexibility – you can list and scan all images within your registry. You can scan images individually, as a cron job, you can even do a batch mode scan, for example, scanning your entire registry every 24 hours. Even more granularly, individual developers or Ops practitioners can scan only the images that they need to, or they also have the option to scan the whole container registry as well periodically.

Runtime scanning with ThreatMapper

Scanning image builds in your CI/CD pipelines and scanning registries, is just the first part. The second part is being able to scan at run time. 

Runtime scanning is very important because it adds necessary context such as: 

  • Is this dependency actually being used or loaded by a process? 
  • Is this particular .jar or this particular .py file, which has a vulnerability, being used or not?

Otherwise, you’re going to be looking at inactive, unexploitable vulnerabilities and missing out on fixing the most pressing issues that require your most immediate attention.

To begin runtime scanning, you can click into one of your nodes on the ThreatMapper dashboard, in this example it’s a Kubernetes cluster running on Google Cloud, and start the scan process. You can choose to only scan for some vulnerabilities, for example only Java vulnerabilities if you are predominantly using Java, or you can scan every executable piece of code, no matter the language or framework within the entire cluster or on a particular host.

Flexible vulnerability scans within ThreatMapper

It’s also important to note that the scan is not a network scan. You’re not going to saturate your network bandwidth by scanning. Why? Because ThreatMapper is deployed as a microservice. It’s a container deployed as a DaemonSet along with your other containers, alongside your other services. It’s not a proxy, it’s not a kernel module. All the tracing is being handled with eBPF and other services without negatively affecting your performance or slowing you down.

Vulnerability scanning with ThreatMapper provides a wealth of information for you, including your most exploitable vulnerabilities.

Uncover your most exploitable vulnerabilities

ThreatMapper shows you the list of your most exploitable vulnerabilities. To prioritize the list by exploitability, ThreatMapper augments the vulnerability data with runtime context, including:

  • Is that particular container image in which the vulnerability is reported even running? 
  • Is that host in which we discovered a vulnerability, is it even online? If it is online, is it taking network connections? Is it accepting traffic from the outside world? 
  • How long ago was this particular image built? For example, If this container image was built six months ago, chances are that it is more exploitable now. 

ThreatMapper considers a comprehensive set of runtime conditions to be able to surface how exploitable a vulnerability is within your environment, so that out of the total number of vulnerabilities you’ve found, you are able to prioritize which ones to fix right now because they are going to hurt you immediately. It’s important to note that the score shown in ThreatMapper is not a CVSS score; it is an exploitability score being computed based on all of the runtime parameters. Why? The CVSS score is not enough because it’s a static score. You need more runtime context to be able to prioritize a vulnerability properly, which is what ThreatMapper provides, letting you know which vulnerabilities to fix first.

Vulnerabilities found in your scan with ThreatMapper, ranked by exploitability so you know which ones to fix first

Fix your most exploitable vulnerabilities

Once you’ve uncovered your list of most exploitable vulnerabilities, so which ones you need to fix now, you can take action on those vulnerabilities through the integrations ThreatMapper supports.

For example, you can generate reports, in XLS and PDF format, to send to specific teams to address. The reports can be very granular, for example, by container images that are owned by a particular team. In addition to reports, you can generate notifications on Slack or PagerDuty or Microsoft Teams. You can file a Jira ticket and assign it to the appropriate team. You can also integrate ThreatMapper with your SIEM tools. New integrations are added regularly, so the list of possibilities will continue to grow over time.

How to get started with ThreatMapper

Because ThreatMapper is 100% open source under the Apache v 2.0 license, it’s easier than ever to get started.


Related Posts