Focusing on the WHY: Jit Enables Developers to Understand the Runtime Context for Security Issues

While code and cloud security scanners are great at identifying code flaws and cloud misconfigurations, they can bombard developers with long lists of potential security “issues” – many of which don’t introduce real risk.

Whether insecure code introduces real risk depends on a number of factors, like whether it is being deployed to production, is exposed to the internet, or calls a sensitive database. Without this runtime context, it's nearly impossible to understand whether code flaws and misconfigurations introduce real risk – eroding developer trust in the results.

Jit provides runtime context for each security issue, so that developers can understand WHY a given security issue should be resolved. 

And today, we’re excited to announce that this runtime context is integrated into the developer environment, so developers never need to leave their GitHub or GitLab environment to understand the real impact of security issues.

Example: Integrating runtime context for security issues into the developer environment

In this example, we’re going to create a pull request with insecure code that could lead to Cross-Site Scripting vulnerabilities. Jit has already been installed in my GitHub environment.

 // This is an unsafe practice and can lead to XSS vulnerabilities
 const userInput = document.getElementById('userInput').value;
 document.getElementById('content').innerHTML = userInput;

Jit automatically scans every pull request and identities the problem.



As a developer, I’m used to code security scanners telling me there is something wrong with my code. If I’m like many developers, I’ve lost trust in these results. Too many times, I’ve chased security “issues” that don’t introduce real risk.

This is why Jit provides runtime context as a comment within the pull request (or merge request, if you’re using GitLab). Right away, I can see the “Repository risks” that explain why code that is committed to the repository can create real vulnerabilities with real risk if deployed.



By expanding the “Repository Context” graph, I can see exactly how my code will be deployed in production – helping me understand why security issues will introduce actual risk.

To the left of the graph, I can see this code is deployed by a Lambda in production. I can also see that the code calls a database, which could be handling sensitive information.

This information summarized in a quick blurb, also added within the PR comment.



This is all critical context to help developers understand the true risk of a security issue. That said, most developers aren’t security experts, so they may also need some guidance on remediating the issue.

This is why Jit provides this remediation guidance, along with a suggested code change to auto-remediate the issue with a click.



With Jit, developers can quickly understand whether they’re code change contains any security issues, why the issues introduce real security risk, and how to resolve them – all without leaving their development environment.

Want to try it out yourself? Start a free trial of Jit to provide developers with automated feedback on the security of every code change, with the runtime context needed to understand its impact, and remediation guidance needed to quickly resolve the issue.