Code-to-cloud graph that tells AppSec teams which findings can reach prod data and when safe auto-remediation is possible.

1. A frontline SOC platform just bought context-graph technology, which signals that this layer has crossed from experimental enrichment into urgent operating infrastructure.
2. Buyers now expect one model that links code, privileges, identities, and runtime behavior, because that is the minimum context needed to let an agent investigate or act safely.
3. Jit's pivot away from a pure DevSecOps workflow product suggests that static workflow automation is no longer enough; customers want dynamic graph context that stays current as systems change.
4. Autonomous security operations are increasing the cost of missing internal context, because every gap now blocks safe remediation or creates the risk of an unsafe automated action.

Catalyst. Torq's acquisition of Jit validates that autonomous security operations now require graph-grounded context spanning code, identities, privileges, and runtime behavior.

Build a continuously updated graph from GitHub, CI, IaC, cloud control planes, Kubernetes, identity providers, and ticket metadata for each internet-facing service. The entry product converts every new scanner finding into a fix packet that shows affected service, owning team, reachable privilege chain, customer-data exposure, deployment dependency, and a safe remediation playbook. AppSec can push one prioritized Jira or Slack workflow instead of forwarding five raw tool alerts. As trust builds, the platform becomes the guardrail for autonomous remediation by auto-executing low-risk fixes and escalating ambiguous cases with a full reasoning trail.

What's different. Incumbent scanner, CNAPP, and SIEM vendors each own part of the picture, but they rarely produce a fix-ready graph that combines service ownership, privilege reachability, runtime exposure, and remediation safety in one decision object. This startup wins by being purpose-built for the moment between detection and action, where teams decide whether to suppress, ticket, or auto-fix. Because the graph is optimized for safe execution rather than generic analytics, it can become the authorization layer for autonomous security tools across the stack.

Jobs to be done

flowchart LR
  Scanner[Scanner finding] --> Graph[Code to cloud context graph]
  Graph --> Fix[Fix packet with owner and safe action]
  Fix --> Outcome[Faster remediation and safer automation]

Executive takeaways

• Torq buying Jit validates context graphs as a real control layer, but the space is already crowded by ASPM, CNAPP, and asset-graph vendors.
• The unmet wedge is narrower than generic ASPM: turn one internet-facing finding into a blast-radius-aware fix packet with owner, privilege path, runtime reachability, and safe-action guidance.
• The first credible product must win on trust and time-to-value, not detector breadth; buyers will only automate once graph coverage and approval logic are auditable.

Market definition

Workflow software for AppSec and platform teams that correlates code, cloud, identity, and runtime context to prioritize and safely remediate internet-facing software risk. It sits adjacent to ASPM, CNAPP, and CTEM, but the wedge is the decision object between detection and action.

Customer and buyer

Primary users are product security and platform security engineers at cloud-native B2B SaaS companies. The economic buyer is usually the Head of Product Security, VP Engineering, or CISO who wants faster remediation without giving autonomous tooling an uncontrolled path into production.

Buying triggers

• A recent incident, audit, or customer review exposed that proving real blast radius for a software or cloud finding still takes hours of manual stitching across tools. [61][62]
• AI-assisted development and faster deployment cadence increase code volume and change velocity faster than AppSec headcount, making backlog triage intolerable. [59][60]
• Leaders want to adopt agentic or autonomous security operations, but they need organization-specific context and approval guardrails before allowing automated remediation. [5][64][1]

Willingness to pay

Budget already exists in adjacent platform categories. Public packaging spans per-developer plans (Snyk), tiered AppSec bundles (Endor Labs), asset-and-integration pricing (JupiterOne), and modular workload-based pricing (Wiz), which suggests buyers will fund a standalone product if it consolidates triage and measurably reduces remediation labor or breach risk. [16][18][31][35][62]

Category dynamics

Growth signal 25% YoY growth in total GitHub projects (ecosystem proxy)

Validation signals

• Torq acquired Jit specifically to add an AI context graph to security operations, signaling that context has become a frontline control layer rather than enrichment metadata.
• Jit says it deployed thousands of AI security agents across nearly 100 enterprise customers, indicating real demand for grounded autonomous security workflows.
• Adjacent vendors now market exploitability-led prioritization and code-to-cloud context as core product value, not optional reporting.
• Public packaging from Snyk, Endor Labs, JupiterOne, and Wiz shows enterprise budget already exists for adjacent prioritization and graph-oriented security platforms.

Regulatory & technical constraints

• Autonomous remediation decisions need explainable controls and governance because AI risk frameworks explicitly push for trustworthy, well-managed AI use in critical workflows.
• Secure software development expectations increasingly reward evidenceable remediation practices and shared vocabulary during procurement.
• European software suppliers face stronger risk-management, secure-by-design, and reporting pressure under NIS2 and the Cyber Resilience Act.
• Technically, entitlement and reachability facts are fragmented across IAM policies, network paths, Kubernetes authorization, and identity logs, so graph accuracy is a real product risk.

Competition converges from three directions: developer-first AppSec platforms that want better prioritization, code-to-cloud CNAPP vendors that already model exploitability, and cyber-asset/CTEM graph platforms that map relationships across environments. A new entrant must position below the broad platform layer and above raw scanners: not another dashboard, but the action layer that converts a single finding into a safe, owner-ready remediation decision.

Why incumbents do not win by default

• Cloud platforms. GitHub, AWS, Kubernetes, and Okta already expose the raw ownership, IAM, event, and policy primitives the startup needs, but each platform only sees one slice of the problem and none produces a cross-domain remediation packet by default.
• CNAPP and code-to-cloud platforms. Wiz and Prisma Cloud validate exploitability-led prioritization, but they optimize for broad exposure management across the stack rather than the narrow moment when AppSec must assign a safe change before the next release.
• Developer-first AppSec scanners. Snyk and Jit prove buyers want prioritization tied to business context, yet scanner-centric products still depend on external runtime, identity, and ownership data to prove whether a finding truly matters.
• Asset graph and CTEM platforms. JupiterOne shows the value of relationship graphs and attack-path context, but remediation ownership, release constraints, and safe-action policy remain downstream work for the customer.
• SOAR and AI SOC vendors. Torq demonstrates how valuable an execution layer can be, but AppSec remediation still needs repo-level owner and release context that a SOC-first platform does not win by default.

This company should start as a blast-radius decision layer for internet-facing remediation at cloud-native B2B SaaS companies, not as a broad ASPM, CNAPP, or autonomous SOC platform. The first customer is a Series B-D SaaS company with 75-300 engineers, weekly releases, GitHub, AWS, Kubernetes, and Okta, plus a small product-security team that still spends hours proving which finding can reach production data and who can safely fix it. The immediate buying trigger is usually a recent incident, audit, enterprise security review, or board push toward autonomous security operations that exposes slow and manual blast-radius analysis. Research supports a focused but credible market with a modeled $700.0M TAM, $156.0M SAM, and $2.7M year-3 SOM if the company can land a narrow set of design-partner accounts at six-figure ACVs. The product should begin by converting one scanner finding into an owner-ready fix packet with service ownership, privilege path, runtime reachability, customer-data exposure, and approval-gated remediation guidance, then add low-risk automation only after graph confidence is proven. The deliberate tradeoff is to win the detection-to-action handoff for one service portfolio faster than broader platform vendors, even if that means deferring SOC, compliance, and identity governance expansion. The biggest disconfirming risks are that buyers may view Wiz, Snyk, Prisma Cloud, or JupiterOne as good enough, or that graph completeness is too weak to support trusted recommendations inside 30 days. Exact standalone budget behavior and the minimum graph-confidence threshold for auto-approval remain assumptions that must be validated early.

Problem

• AppSec teams receive findings from code, cloud, identity, and runtime tools, but still reconstruct blast radius manually before they can assign a credible remediation owner.
• Weekly release cadence and AI-assisted development increase change volume faster than security headcount, so backlog triage becomes a production-risk bottleneck.
• Broad scanners and exposure platforms highlight risk, but they do not reliably produce a fix-ready decision object that says what can safely be changed before the next release.

Solution

• Build a continuously refreshed code-to-cloud graph across GitHub, CI, IaC, AWS, Kubernetes, Okta, and ticketing metadata for one internet-facing service portfolio first.
• Convert each new high-priority finding into a fix packet that shows owner, privilege path, runtime reachability, production-data exposure, release dependency, confidence score, and recommended action.
• Add approval-gated automation only for low-risk fixes after the product proves graph accuracy, rollback awareness, and audit-ready reasoning on advisory workflows.

Why we win

• The wedge targets the exact moment between detection and action, where buyer pain, budget urgency, and measurable ROI are sharper than in another broad security dashboard.
• Cross-domain entity resolution across repos, cloud assets, identities, and runtime context is technically harder to copy than adding another prioritization view inside a scanner.
• Approval history and remediation outcomes can compound into a proprietary policy layer for which fixes are safe to auto-execute and which must stay human-approved.

Milestones

flowchart LR
  Wedge[Internet-facing remediation wedge] --> MVP[Blast-radius graph MVP]
  MVP --> Proof[Owner-ready fix packets and trust signals]
  Proof --> Expansion[Policy-gated automation and adjacent control workflows]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least half of qualified buyers must treat blast-radius proof and owner assignment for internet-facing findings as a funded problem inside existing AppSec or platform-security budget.
• The core GitHub, AWS, Kubernetes, and Okta stack must produce useful fix packets in under 30 days for at least 3 early pilots.
• Customers must accept owner-ready fix packets inside Jira or Slack without requiring analysts to reopen multiple external tools on most covered findings.
• At least several target buyers must say Wiz, Snyk, Prisma Cloud, and JupiterOne do not already solve the final remediation-decision workflow well enough.
• Low-risk fixes must be definable with approval rules that avoid rollback incidents before autonomous remediation becomes a meaningful expansion driver.

Open diligence questions

• Which context source improves buyer trust fastest: service ownership, runtime exposure, IAM entitlements, or customer-data sensitivity?
• How often does budget unlock because of an incident or audit versus a broader autonomous-security initiative?
• What graph-confidence threshold is required before a VP Engineering or CISO allows low-risk auto-remediation?
• In live evaluations, where do Wiz, Snyk, Prisma Cloud, and JupiterOne still fail the owner-ready remediation workflow?
• How much deployment work is required when a prospect deviates from the core GitHub, AWS, Kubernetes, and Okta stack?

Model sanity

• Revenue engine. Base-case revenue comes from reaching 12 production customers by Q4Y2 and 18 by Q4Y3 while expanding blended ARR per account to 180K.
• Must go right. The model needs pilot-to-production conversion to stay at or above the plan and the standard GitHub plus AWS plus Kubernetes plus Okta deployment to stay under 30 days.
• Model breaks if. A slower sales cycle or weaker ARPU expansion is the fastest path to cash pressure because cash turns negative in Y3 even before any major hiring miss.
• Next-round proof. The next financing is justified once the company shows roughly 8-12 production customers, sub-21-day deployment, and one approved low-risk automation policy on the standard stack.

Scenarios

Sensitivity

flowchart LR
  Leads[Founder-led outbound] --> Pilots[Paid pilots]
  Pilots --> Customers[Production customers]
  Customers --> Revenue[Subscription revenue]
  Revenue --> GrossProfit[75 percent gross profit]
  GrossProfit --> Cash[Runway and financing need]

Flags: The base case still requires a follow-on round before the end of Y3 because modeled cash reaches -$732.7K without new financing. · Revenue concentration is high because the model assumes 18 customers by Y3 and depends on six-figure contracts in a crowded security category. · Gross margin stays at the business-plan target despite graph-heavy workloads, so unexpected cloud or support costs would pressure runway quickly.

• Graph incompleteness. Missing edges or stale ownership data could create false confidence and cause the product to understate real blast radius. Mitigation: Start with a tightly supported stack, expose confidence scores on every recommendation, and require approval gates until graph coverage reaches a verified threshold.
• Incumbent bundling. CNAPP, SIEM, or AppSec vendors may add basic context-graph views and reduce willingness to buy a standalone tool. Mitigation: Own the remediation decision workflow and autonomous-action policy layer, where cross-tool execution and auditability matter more than graph visualization alone.
• Integration fatigue. Security teams may resist another platform if deployment requires months of connector work before value appears. Mitigation: Launch with a 30-day packaged deployment for common GitHub, AWS, Kubernetes, and Okta stacks and prove ROI on one internet-facing service portfolio first.