Announcing Context Engine: Focus on the alerts that matter

It's impossible to effectively prioritize vulnerabilities without understanding how they're executed in runtime. That's why we built Context Engine.

David Melamed writer profile image
By David Melamed

Updated June 10, 2024.

a purple background with a pink and green megaphone and the words announcing a content

Today, I’m delighted to announce the release of Jit’s Context Engine, which uses the runtime context of vulnerabilities to automatically prioritize the top security risks in our customers’ cloud applications. 

One of the defining challenges of product security is the overwhelming volume of alerts generated by code and cloud security scanners, which is especially painful when the majority of “issues” don’t pose any real security risk. Development and security teams waste time chasing down security findings that don’t introduce risk, while the real risks are obscured in mountains of alerts.

Context Engine solves this problem by incorporating runtime context – including the location of the security finding and whether it is externally accessible – into vulnerability prioritization. Rather than trying to determine which security findings represent exploitable vulnerabilities in production, Context Engine tells you immediately, focusing mitigation efforts on the top risks.

To try it out yourself, request access we’ll open it up to your account. Customers don’t need to pay extra for Context Engine – it's included in the cost of Jit’s Open ASPM Platform.

Learn about the benefits of Context Engine and how it works in the video below:



What’s wrong with the status quo?

Code and cloud security scanners are excellent at surfacing security issues in cloud applications. Using SAST, SCA, secrets detection scanners, IaC scanners, and other product security tools, developers can quickly identify a wide variety of code and configuration flaws that could create vulnerabilities – depending on how they’re executed in runtime.

Without this context for how security issues are executed in runtime, most development and security teams prioritize issues according to their “severity”, which are determined by third parties. For example, the National Institute of Standards and Technology maintains the Common Vulnerability Scoring System (CVSS), and the Common Weakness Enumeration (CWE) is sponsored by the MITRE Corporation.

While these scoring systems are very useful for determining the potential impact of code and configuration flaws, they don’t provide the runtime context needed to understand the true risk of security issues. For example, if a high severity SQL injection resides in a staging environment that doesn’t handle sensitive data, it shouldn’t be considered a high risk.

As mentioned earlier, the lack of runtime context can lead to painful remediation cycles. Developers inevitably waste time resolving issues that don’t introduce real risk, while the most critical risks remain buried in the backlog.

That is why we built Context Engine.

Context Engine: How it works, and how to use it

To understand the runtime context of vulnerabilities, Jit’s Context Engine builds a knowledge graph of our customers’ environment, which doesn’t require any installation or configuration.

The knowledge graph paints a full picture of the code, delivery pipeline, and runtime environment, which allows Context Engine to understand how, where, and if security issues are executed, so it can prioritize those issues accordingly. Specifically, Context Engine uses the following prioritization factors:

  • Location: Usually, the top security risks will reside in production rather than a staging environment. Context Engine can determine where security issues reside to prioritize production vulnerabilities.

  • External accessibility: just because a security issue resides in production, that doesn’t mean it’s externally accessible. Perhaps the issue isn’t accessible via the internet, or perhaps the application doesn’t explicitly call the library containing the security issue. Context Engine examines the application code to determine whether the issue is reachable.

  • Fix availability: for many known vulnerabilities in open source components, there aren’t yet fixes available. If such a vulnerability cannot yet be fixed, Context Engine will deprioritize it.

Once Jit surfaces security issues in your repositories, Context Engine synthesizes the prioritization factors above for each security finding and assigns them a Priority Score, which can be filtered in Jit’s backlog. This is how Context Engine automatically prioritizes the top product security risks in your cloud applications.

After clicking on a security finding, Jit presents information like the associated repo, the location in runtime, and whether it is externally accessible.

a screenshot of a computer screen with a number of buttons


With this information, security and development teams can quickly understand the runtime context of each security finding, so they can easily prioritize the exploitable vulnerabilities in production. Context Engine provides full traceability from the code pipeline to the runtime environment – connecting live security issues with the associated repo and responsible developer.

As a result, developers spend their remediation cycles mitigating the top risks, while deprioritizing the noise.

Try it yourself by getting in requesting access, and we’ll open it for your account.