Jit After the Torq Acquisition: What DevSecOps and AppSec Buyers Should Check Before They Renew or Buy (2026)

If you run Jit today, or had it on a shortlist before the summer, one fact changes how you should evaluate it: on 19 May 2026 Torq announced that it had acquired Jit. Torq builds an AI security operations platform, and the stated purpose of the deal is to put Jit's context graph underneath Torq's SOC agents. None of the coverage we read says what happens to the standalone Jit application security product, its contracts or its support. That is a gap, not a verdict, and this guide is about how to work with a gap like that sensibly.

It is written for an AppSec lead, a platform engineer or a head of engineering who either owns a Jit contract or is choosing a DevSecOps platform and has met Jit along the way. You will get a dated timeline of what is public as of 28 October 2026, a fair account of what Jit built and where it is strong, a list of questions to put to Jit and Torq in writing, a way to make your pipeline portable so that no vendor event can strand you, and a 30 day evaluation checklist that includes Safeguard, our own product, so read our sections as a vendor's sections and test them on your code.

A note on method. Facts about Jit and Torq come from their own pages, their announcements, trade press with links and dates, and listings that Jit publishes itself, all accessed on 28 October 2026. Jit's own site blocked our automated fetches on the day, so several Jit documentation facts below were read through search-engine excerpts of the page rather than the page itself, and we say so where it matters. Where a source does not answer a question, we write that it does not. We do not quote Jit's prices, because the figures in third-party profiles disagree and its pricing page should be your source.

Key takeaways

• The deal is real and recent. Torq announced the acquisition on 19 May 2026. Trade press reports that Jit's co-founder and CTO David Melamed and a team of roughly 30 to 33 people joined Torq. The price was not disclosed.
• Torq's stated plan is about the SOC. Torq's own post says the context graph makes its platform better "without adding a separate product line for teams to adopt." The coverage we read does not mention the Jit application security product or its customers.
• Jit had already moved toward agents. In April 2025 it launched an AppSec Agent, a Compliance Agent and a Security Ops Agent on top of a company knowledge graph. The acquisition continues a direction rather than starting one.
• Jit's open scanner approach limits your exit cost. Its plans run well known open source scanners such as Semgrep and Gitleaks, so the underlying detection logic is something you can recreate. The orchestration, plans and agent layer is what you would have to rebuild.
• Ask in writing, then decide. The useful question is not whether Jit will survive. It is what Jit and Torq will commit to for your contract term: support, roadmap, data handling, assignment and price at renewal.
• Portability is the best hedge. Keep SBOMs, policy definitions and fix history in formats you own. That makes any tool, ours included, replaceable.

What happened, with dates and sources

Deal news is easy to garble, so here is the timeline using only what the sources state. Dates are those given by each source.

Three details deserve care. First, the price. Torq did not disclose it. Calcalist's Ctech estimated roughly $70 million and labeled that an estimate. BankInfoSecurity reported that Business Insider had said Torq planned to pay $50 million, and did not confirm it. Treat both as press estimates. Second, headcount. Calcalist says about 30 employees joined, BankInfoSecurity says 33. Third, one page we found dated the deal to April 2025. Every other source says May 2026, so that is the date used here.

Torq's press release describes Jit as an "AI Context Graph cybersecurity pioneer" and says Torq will welcome Melamed and "dozens of brilliant innovators" from Jit. Torq's blog says Melamed joins as Head of Emerging Technologies and that the Torq Context Graph is now "strengthened by Jit." SiliconANGLE adds the strategic logic: Torq's existing agents reason over alerts from third-party tools, and Jit's graph is meant to add an organization-specific layer underneath them. Torq's CEO Ofer Smadari, quoted by Channel Insider, called Jit "the missing layer the industry needed."

Read those sentences as a buyer of application security and you will notice what is absent. There is no mention of CI scanning, Security Plans, pull request findings or developer workflows. That is natural for a press release aimed at SOC buyers. It still leaves your contract in a gray zone, and gray zones are what the questions later in this guide are for.

What Jit built, and why people chose it

Fairness first. Jit earned its reputation, and if you chose it you probably had good reasons.

Security plans as code

Jit's pitch from 2021 was to turn the pile of open source security tools a startup would otherwise assemble by hand into a managed product. Its documentation describes a security plan as an outcome driven blueprint, "security plan as code," that captures requirements as intent, allows custom risks, and translates the intent into running workflows and evaluated policies. Plans are built from items spread across layers of the stack. Workflows are triggered by events such as pull requests, deployments, scheduled runs or external inputs, and the plan hierarchy runs from plan to items to workflows to jobs to steps, where a step runs a security tool (Jit docs). Named plans include a minimum viable security plan for AppSec built on open source tools, a Max plan that covers the full control suite, a GitHub security plan, and compliance oriented plans for SOC 2 and the AWS Foundational Technical Review, according to Jit's materials and third-party profiles.

For a small engineering team that wants a defensible baseline in an afternoon, that is attractive. You connect a repository and the plan decides which scanners run where.

Open scanners you could recognize

Jit's scanner summary names the engines behind its plans. As read through search excerpts of docs.jit.io on 28 October 2026: Semgrep for static analysis across a long list of languages, Gitleaks and TruffleHog for secrets, Trivy for Dockerfiles, Gosec for Go, OSV-Scanner for dependency vulnerabilities, and KICS for infrastructure as code in an earlier docs version. Jit's own marketing pages also mention OWASP ZAP for dynamic testing. Jit's flexible tooling page says it adds its own rules on top of Semgrep and supports open source, cloud native and commercial tools, including in-house ones. Jit's GitHub organization describes the company as "the only open DevSecOps Orchestration Platform," which is Jit's own wording, and it publishes small public repositories such as customer scripts and IDE pre-commit hooks.

This matters for exit planning. When the scanners are open and named, your detection logic is not trapped. We come back to that below.

Scans that do not use your CI minutes

A third-party profile of Jit states that scans run on Jit's managed infrastructure rather than inside your CI pipelines, so they do not consume CI minutes (AppSecSanta). That is convenient for monorepos and for teams that dislike slow pipelines. Jit's pricing page, according to excerpts we could retrieve, also mentions self-hosted GitHub runners, so confirm which execution model your plan uses.

Agents and an MCP server

On 8 April 2025 Jit launched three agents. The AppSec Agent builds and updates risk assessments and threat models and does contextual code review. The Compliance Agent maps environments to standards, produces reports on demand and suggests how to close gaps. The Security Ops Agent automates triage and remediation, creates and follows up on tickets, notifies developers and generates posture reports (Help Net Security, PR Newswire). Jit says the agents use a company knowledge graph that ties findings to business priorities, SLAs and code to cloud context. Jit also announced an MCP server in preview for existing customers, aimed at letting developers see findings, assess severity and impact and act on them from the IDE.

Breadth on the AWS Marketplace listing

Jit's own AWS Marketplace listing, which we read directly, describes a SaaS agentic security platform with static analysis across 29 languages, dynamic testing, container and infrastructure as code scanning, secrets detection, SCA, a risk graph for code to cloud traceability, a pluggable scanner architecture and zero day policies backed by a research team. It lists an average review score of 4.5 from 44 ratings, with reviewers praising setup speed and CI and GitHub integration, and mentioning limited documentation for advanced configuration and reporting depth as common complaints. The listing also names IAST and mobile testing in its feature list, which other pages do not, so verify any specific scanner you need in a trial rather than from a brochure.

What is known and unknown after the deal

Here is a sorted list. It is the most useful thing in this guide for a stakeholder who has two minutes.

Stated by the companies or reported with attribution

• Torq acquired Jit, announced 19 May 2026.
• Jit's technology, branded as the AI Context Graph, is being folded into Torq's AI SOC platform.
• Melamed and a team of about 30 to 33 joined Torq.
• Torq says it adds this "without adding a separate product line for teams to adopt."
• Terms were not disclosed.

Not stated in any source we read

• Whether the standalone Jit application security product continues, is merged into Torq or is retired.
• What happens to existing contracts, renewal terms, pricing or support levels.
• Whether Jit's Security Plans, scanner orchestration and pull request experience keep their roadmap.
• The future of the MCP server preview and the three agents as separate products.
• Whether the legal entity you contracted with changes, or whether your agreement can be assigned.

Signals that point in different directions

• Jit's own site, as of the research for third-party comparisons updated on 30 September 2026, still markets product security agents and Security Plans.
• One comparison describes Jit's position as a product security agent offering that Torq positions inside its AI SOC platform and calls pricing quote-led after the deal. Another alternatives guide, written by a vendor that sells a competing product, argues that the deal shifts Jit toward enterprise security operations and leaves developer teams asking what to move to. That second source has an obvious interest, so weigh it accordingly.

The honest summary is that nobody outside the two companies knows. Which means you should ask them, and you should make the answer a precondition of any renewal.

Four reasonable stances for existing and prospective Jit customers

Not every team should move, and none should panic. Pick the stance that matches your situation.

1. Stay and get commitments in writing

If Jit's plans do what you need and developers like the pull request experience, staying is rational. The change you want is contractual: written statements about support, roadmap for the product you use, data handling after the acquisition, and an assignment clause that you have read. Jit's AWS Marketplace listing says contracts run for 12, 24 or 36 months and that fees are non-cancellable and non-refundable except as required by law. That is common for annual SaaS, and it makes the time before you sign or renew the right time to ask, not the time after.

2. Stay on a short term while you build a portable fallback

If you have a renewal soon and no answers, take the shortest term available and use the months to make your pipeline portable using the steps in the next section. This stance costs a little more and buys a lot of optionality.

3. Run a parallel pilot

Pick two or three representative repositories and run a second platform next to Jit for a month. Compare findings, noise, time to fix and developer reaction. Safeguard is one candidate. A scanner set you assemble yourself from the same open source tools Jit orchestrates is another. See the checklist later.

4. Move

If your use of Jit is mostly the managed open source scanner bundle, moving is easier than it sounds, because the detection engines are not proprietary to Jit. If your use leans on the agents, the context graph and the compliance plans, you have more to map. Either way, move on your schedule, not a vendor's.

Questions to put to Jit and Torq in writing

Put these in an email to your account owner and keep the replies. Anything they decline to answer is also information.

1. Which legal entity holds my contract today, and will it change? Under what conditions can the agreement be assigned?
2. Is the standalone Jit product, including Security Plans, scanner orchestration and the pull request bot, committed for my current term? For how long past it?
3. What is the roadmap for the AppSec features I use, in the next two quarters? Who owns it now?
4. Are the AppSec Agent, Compliance Agent and Security Ops Agent continuing as customer products?
5. What is the status of the MCP server that was announced as a preview, and is it supported?
6. Has anything changed about where my source code metadata, scanner output and cloud telemetry are processed or stored? Which subprocessors apply now?
7. Can I have the current SOC 2 report, and does it cover the entity and systems I rely on after the transaction? (Third-party profiles report SOC 2 Type II for Jit. Ask for the report itself.)
8. What are the support channels and response targets after the acquisition? Has the support team changed?
9. What is the price at my next renewal, and what notice will I receive of changes?
10. If I leave, how do I export my findings history, ticket links, exceptions and plan configuration? In what format?
11. Do you offer a transition period, and does it include a termination right if the product direction changes?
12. How do I get a copy of the plan configuration files so I can run the same open source scanners without Jit?

Torq may also have an answer on bundling. If you are already a Torq customer, ask whether Jit capabilities are included in your platform or priced separately, since the stated approach is to add the graph to the platform rather than sell another product.

Make the pipeline portable, whatever you decide

You cannot control what a vendor does. You can control how much of your security program lives in places only that vendor can read. Five things to own.

Your SBOMs. Generate a software bill of materials per build in SPDX or CycloneDX and store it in your own artifact storage. Third-party descriptions of Jit's SBOM generation name Syft and Grype, and Safeguard exports 30 or more formats, but the format matters more than the tool: standard SBOMs travel.

Your detection configuration. If your Jit plan runs Semgrep with custom rules, keep those rules in a repository you own. Jit's plan modification docs show a plan file that overrides workflows by category, job and step, each step naming a container image and arguments. Copy that file into version control. The docs note that modification support is currently narrow, so check which of your customizations are in it.

Your policies. Write down the rules that decide whether a build fails: severity thresholds, secrets handling, license restrictions, who approves exceptions. Whatever platform you pick should be able to express them. Safeguard expresses them as policies and gates, with conditions such as severity, CVSS, EPSS, license, component age, maintenance status and SLSA level, and actions that block, warn or notify.

Your exception history. Auditors ask why a finding was accepted. Export accepted risks with justification and expiry date, and keep them outside any single tool.

Your evidence. If you pass SOC 2 or ISO audits partly on tool-generated reports, store the reports, not only the dashboard login.

A team that has done these five things can leave any vendor in a few weeks. That is true for Jit, for Safeguard and for anything else.

Where Safeguard fits, and where it does not

Safeguard is a software supply chain security platform. It resolves dependencies and matches advisories enriched with EPSS and CISA KEV, applies reachability analysis with four verdicts (reachable, conditionally reachable, unreachable and unknown), opens tested pull requests through auto-fix, and carries SBOMs, vendor risk and compliance evidence in one findings model. Its application security testing page covers first-party SAST and DAST, and its engine catalog includes optional third-party engines alongside first-party ones.

The honest comparison with Jit has two halves.

Where Jit has the edge for some teams: an orchestration layer over named open source scanners, plans mapped to outcomes such as SOC 2 and the AWS Foundational Technical Review, scans that run on managed infrastructure, an agent layer for triage and ticketing, and cloud posture checks that third-party profiles list as CSPM. Where Safeguard has the edge: reachability verdicts, fix pull requests from one engine with category by category control, a registry of rebuilt components for the case where upstream has no fix, Zero AI mode and air-gapped deployment, and a single product that also covers third-party risk and compliance evidence.

On SAST specifically, today the docs list SAST for JavaScript and TypeScript, Python and Java, with more planned, so check the docs against your languages before you assume parity with Jit's Semgrep based coverage.

A longer technical comparison is in our sibling post, Jit vs Safeguard: security plans as code over open source scanners, or one engine that opens the fix pull request.

Comparison table: what to weigh as of 28 October 2026

Pricing and contract points to check

We do not repeat Jit's price figures. The paragraph that follows lists what to look for, as of 28 October 2026.

Jit's pricing page was not reachable by our automated fetch, and the figures reported in third-party profiles differ, so read the live page and ask for a quote in writing. A third-party comparison dated 30 September 2026 describes pricing as quote-led after the Torq deal, while noting its own figures were historical and unverified. Jit's AWS Marketplace listing shows contract tiers by developer count, 12, 24 and 36 month terms, unlimited scans and remediation in every tier, and a usage charge for developers beyond a tier. Fluid Attacks, a competitor, reports a minimum scope of five developers and an annual minimum term. Compare any quote on the same repositories and the same scanner scope. Ask whether DAST is metered separately, because third-party sources describe DAST as consumption priced.

For Safeguard, there is a Free plan with no card and no expiry. See safeguard.sh/pricing for current plans.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

When to choose Jit

Jit is a sensible choice, and this is not a polite way of saying otherwise. These are the cases where it fits.

• You want a managed bundle of well known open source scanners with sensible defaults, and you value that the scanners are named and recognizable.
• Your driver is a baseline plan quickly: a minimum viable security plan, a GitHub security plan, or a compliance oriented plan for SOC 2 or the AWS Foundational Technical Review.
• You like security expressed as a plan with items and workflows, and want developers to see findings on pull requests without owning pipeline plumbing.
• You are a small or mid sized team without a large existing security toolchain, so there is little to orchestrate and a lot to start.
• You already use Torq, or plan to, and want the context graph and security operations story in one vendor relationship.
• You have read the answers to the questions above, you are satisfied with them, and your contract protects the product you use for the term you need.

If those describe you, run the contract conversation, keep your configuration portable and carry on. Nothing in the public record says Jit stopped working.

When to choose Safeguard

• Your problem is vulnerable dependencies and supply chain exposure: you want a reachability verdict per finding and a tested pull request that fixes it, not another list of findings.
• Upstream has not fixed something, or will not, and you want a path that does not end with waiting: rebuilt components, fork and patch, or a requested hardened build.
• You cannot send code to a third party model, or want to choose: Zero AI mode, bring your own model, models inside your environment, or an air-gapped deployment.
• You want SBOMs, third party risk, compliance evidence and zero day advisories in the same findings model as your scanner.
• You want vendor independence as a design property: the standards based exports and the local runner make Safeguard replaceable too, which is how it should be.
• You value an agent native interface: the MCP server lets assistants such as Claude drive the platform.

Both: some teams keep Jit's plans for the baseline scanners and add Safeguard where fixes and reachability matter. That is workable if you pick one authoritative source of verdicts for each vulnerability, so developers do not get two opinions on the same finding.

Migration and evaluation checklist: 30 days

Use this whether you are moving, hedging or only doing diligence. Replace Safeguard with any candidate.

Days 1 to 5: inventory

• List every repository, workspace and cloud account connected to Jit.
• Export or screenshot plan configuration, including which items and workflows are on, and any modifications to a plan file.
• List integrations: source control, ticketing, chat, IDE plugins, CI jobs, compliance tools.
• Record who owns Jit internally and which stakeholders read its output (developers, AppSec, GRC).
• Write down the five policies that decide whether a build fails.

Days 3 to 10: contract and questions

• Send the twelve questions above. Put the reply date in the calendar.
• Read the renewal date, termination and assignment language, and any refund terms.
• Ask for the current SOC 2 report and the subprocessor list.

Days 6 to 15: parallel pilot

• Pick three repositories: a typical service, a legacy one, and one with a messy dependency tree.
• Run the candidate beside Jit. With Safeguard, the CLI and local runner scan on your machine and send only encrypted results, and the CI integration uses a shell step such as safeguard ci scan --wait --fail-on-gate all.
• Record for each repository: findings by type, true positives after a human check, false positives, time to a merged fix.

Days 10 to 20: map the layers

Days 15 to 25: decide on evidence

• Compare true positives, false positives and time to fix, not feature lists.
• Ask developers which tool they would keep if they chose.
• Estimate total cost with the same repository scope in each quote.

Days 25 to 30: cutover or renewal

• If staying: sign with the commitments you asked for, and keep the portable fallback maintained.
• If moving: run both for one release cycle, then retire Jit workflows one category at a time, secrets before static analysis, and keep exception history exported.

Frequently asked questions

Did Torq acquire Jit?

Yes. Torq announced the acquisition on 19 May 2026, per its own press release and coverage by SiliconANGLE, Calcalist and BankInfoSecurity. The price was not disclosed. Press estimates range from $50 million to $70 million and are not confirmed.

Is Jit still available as a standalone product?

The coverage we read does not say. Torq's blog says its context graph adds to its platform "without adding a separate product line for teams to adopt," and Jit's site was still marketing product security agents and Security Plans in the comparisons we found, dated 30 September 2026. Ask Jit or Torq in writing.

Will my Jit contract change?

We found no public statement. Contracts are between you and the legal entity that signed them, so read the assignment and termination clauses and ask which entity holds the agreement.

What is Jit's context graph?

Jit describes a company knowledge graph that ties code repositories to cloud infrastructure, ownership and business priorities, which its agents use to rank and act on findings. Torq describes the AI Context Graph as mapping relationships among users, devices, identities, privileges and data sensitivity, and plans to use it for alert triage and investigations in its SOC platform.

What scanners does Jit actually run?

Per its docs scanner summary as read on 28 October 2026, plans use Semgrep for static analysis, Gitleaks and TruffleHog for secrets, Trivy for Dockerfiles, Gosec for Go, OSV-Scanner for dependencies and, in an earlier docs version, KICS for infrastructure as code, with OWASP ZAP mentioned on marketing pages. Jit's AWS Marketplace listing describes broader coverage, so confirm anything you depend on in a trial.

Can I leave Jit without losing my security checks?

Mostly yes, because the detection engines are open source. You keep the rules and configuration in version control, export SBOMs and exception history, and recreate policies in the next platform. What you rebuild is orchestration, pull request experience, and any agent workflows you relied on.

How does Safeguard differ from Jit?

Jit orchestrates open source scanners through security plans and adds agents on a context graph. Safeguard is a supply chain platform with its own engines: reachability, tested fix pull requests, SBOMs, a registry of rebuilt components and compliance evidence, deployable from SaaS to air-gapped. Jit is stronger as a quick, plan driven baseline over named open source tools. Safeguard is stronger when the problem is dependencies, fixes and evidence. See the longer comparison.

Is Safeguard SOC 2 audited?

Safeguard is SOC 2 Type I and Type II audited, with reports available on request, and its architecture is designed for FedRAMP High. Ask every vendor, Jit and Torq included, for current reports under NDA.

How does Safeguard handle a vulnerability with no upstream fix?

It first works to get a fix accepted upstream. If the issue is severe or upstream will not move, it builds a fork, fixes the vulnerability there and publishes a hardened Gold build. You can also request a compatibility tested build of a specific package. Ask which packages are covered before you plan around it.

Where to go next

The cheapest way to test our side is one repository: the CLI and local runner scan on your machine, reachability and auto-fix are documented in detail, and Gold is free to browse. Related reading: what is security as code, what is policy as code, consolidating AppSec tools with an ASPM platform, what is application security posture management and SCA with reachability: a buyer's guide. The full source list, accessed on 28 October 2026, is in this post's metadata.

Third party facts were checked against public pages on 28 October 2026 and can change. If something here is out of date or wrong, tell us and we will fix it. Jit, Torq, Semgrep, Gitleaks, TruffleHog, Trivy, Gosec, OSV-Scanner, KICS, OWASP ZAP, Syft, Grype, GitHub, AWS, Drata and Vanta are trademarks of their owners, used here in plain text for comparison with no implied partnership or endorsement.