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.
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:
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 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:
And here’s an example showing that you have visibility all the way to the process level, shown below:
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:
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.
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:
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.
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.
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:
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.
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.
Because ThreatMapper is 100% open source under the Apache v 2.0 license, it’s easier than ever to get started.
.png)