Introducing Policies: Smarter Controls for Managing Security Findings

At Jit, we’re all about empowering developers to build secure software without compromising agility. But as teams scale, enforcing strong governance and compliance practices while enabling flexibility can be tricky. That’s why we’re thrilled to announce Policies, a new feature that lets you customize controls over who can ignore security findings in Jit.

With Policies, you can ensure security findings are addressed appropriately based on risk, context, and compliance requirements. No more worrying about critical vulnerabilities slipping through the cracks—Policies give your team the guardrails they need to stay secure and productive.

Why We Built Policies

We built Policies in response to your feedback. You told us that while Jit helps uncover and fix vulnerabilities, you needed more control over how Jit-detected security findings are handled across your teams.

For example, you wanted to:

• Enforce better governance: Ensure only authorized team members can ignore security findings.
• Mitigate risk in production: Prevent findings from being ignored when they pose a real threat or violate compliance rules.

Without this level of control, there’s a risk of developers unintentionally ignoring findings that could violate compliance requirements or leave your application vulnerable.

To solve this, we built Policies—a flexible way to enforce your security rules while keeping your workflows developer-friendly.

In the future, we'll add additional uses cases for Policies - let us know if you have one!

How Policies Work

Policies let you define who can ignore security findings, and under what circumstances. Here’s how:

1. Set fine-grained controls: Create rules based on roles and responsibilities, such as allowing developers to ignore non-critical findings but requiring approval for anything that impacts production.
2. Leverage runtime context: Use factors like "accessible via the internet" or "exposes sensitive data" to make smarter decisions about what can and cannot be ignored.
3. Enforce policies where it matters: Apply these rules directly in pull requests and across the Jit platform, so security stays consistent across remediation workflows.

Here’s an example of policies that control the ability to ignore findings in the Jit platform:

• Only Jit Admins can ignore findings in the "jit" resource (i.e. code repository)
• Only Jit Admins and Members can ignore "critical" and "high" severity findings that are in production



Similar policies can be created to control how findings are ignored when they're detected by Jit in the pull request:

• Only Ayelet can ignore "critical" severity findings when the resource has a Risk Score above 90 (the risk score is based on the runtime context of the code repository or security finding, like whether it is exposed to the internet or calls a sensitive database.)





Get the flexibility to ensure efficiency, and the governance to ensure security and compliance

Developers need the ability to ignore findings so they can bypass security controls if urgent updates are needed - there is nothing worse than being blocked by a false positive. Similarly, security teams need the ability to ignore existing security findings to clean up their backlog.

That said, some issues are ignored when they shouldn't be, so we built Policies to give Jit Admins control over which security issues can get ignored, which can't, and which findings need to be reviewed.

With Policies, you can:

• Reduce risk: Ensure critical findings are never ignored without proper review.
• Stay compliant: Enforce security rules that align with your compliance requirements.
• Save time: Give developers the freedom to address low-risk findings or false positives without unnecessary bottlenecks.

Ready to take control of your security workflows? Policies are available now!

Find Policies in the "Settings" tab in the left menu, or book a demo.