GitHub gate that quarantines new OSS packages in AI-written PRs until security gets provenance, safer substitutes, and approval.

1. A $60 million Series C at a $1 billion valuation signals that dependency security has crossed from optional tooling into an enterprise budget category.
2. AI-native software companies are already reference buyers, which means the first beachhead customers can point to peers rather than making a speculative purchase.
3. AI-generated code increases the volume of third-party packages entering repos, making manual approval workflows fail exactly when teams are moving fastest.
4. A six-minute detection example shows the review window is now shorter than a normal security handoff, so the approval control must sit inside the pull-request workflow instead of after merge.

Catalyst. The cluster shows that AI-driven development is accelerating dependency risk, enterprise buyers are already paying for developer-first supply-chain tooling, and the decision window can be as short as six minutes — forcing teams to move package approval upstream into the PR itself.

The product plugs into GitHub, GitLab, or Bitbucket and watches manifest and lockfile diffs for first-time dependency additions across the organization. When a PR introduces a new package, it automatically builds a reviewer brief with maintainer history, publish cadence anomalies, obfuscation or install-script risk, internal usage context, and one or more approved alternatives already present inside the company. Security teams can approve once for the whole org, reject with rationale, or sandbox the dependency in a temporary quarantine branch for deeper testing. The workflow is designed for small platform-security teams: instead of triaging every package from scratch, they maintain policy templates and an internal trusted catalog that compounds with each decision. Over time, the same brief can be surfaced back to Cursor, Copilot, and internal coding agents so developers see safe package recommendations before they even open a PR.

What's different. Socket, Snyk, and similar products are strongest as scanning and alerting systems; this idea is a workflow system for deciding whether a net-new package should enter the codebase at all. Its moat comes from compounding internal decision data: every approval creates a reusable package catalog, substitute graph, and org-specific policy memory that gets more valuable as AI-generated code increases package churn. If executed well, it becomes the control plane between coding agents and the universe of third-party code, not just another red-yellow-green scanner.

Jobs to be done

flowchart LR
  Buyer[Platform Security Lead] --> Pain[Too many AI-generated package additions]
  Pain --> Product[Dependency Intake Gate]
  Product --> Outcome[Fewer risky packages reach main]

Executive takeaways

• The pain is moving upstream from fixing vulnerable packages after adoption to governing whether new packages should enter the repo at all.
• Incumbents validate budget and urgency, but most still emphasize detection and remediation more than approval workflow memory.
• A credible wedge exists if the product becomes the policy memory and substitute engine inside the PR, not just another scanner.

Market definition

Developer-security workflow software for governing first-time open-source dependency adoption at pull-request time, especially in AI-assisted software teams.

Customer and buyer

Primary users are platform-security and staff platform-engineering teams at AI-native SaaS companies with small security teams and frequent net-new package additions. Economic buyers are VP Engineering and product-security leaders who already own AppSec and secure SDLC budgets.

Buying triggers

• Formal AI coding rollouts increase dependency churn while developers remain skeptical of AI output quality, which makes package review a visible control gap. [112][23][45][115]
• Rising malicious-package volume and real-time supply-chain attacks make post-merge review feel too late for security teams. [111][77][106]
• Compliance and procurement programs increasingly ask for auditable OSS controls, sanctioned repositories, and lifecycle vulnerability handling. [46][47][48][19]

Willingness to pay

Buyers already accept per-developer security spend: GitHub Code Security is $30 per active committer per month and Snyk Team starts from $25 per contributing developer per month, so a narrower dependency-intake workflow can be budgeted if it demonstrably reduces manual review time and blocks risky package introductions earlier. [22][87]

Category dynamics

Growth signal 13.2% CAGR

Validation signals

• Socket’s 2026 financing and customer list show that AI-native software teams already budget for supply-chain-specific tooling.
• Developer AI-tool adoption is mainstream, but trust and debugging pain remain high enough to justify guardrails around dependency suggestions.
• GitHub and GitLab already expose PR-stage dependency workflows, which lowers technical distribution risk for a narrowly scoped gate.
• npm and PyPI provenance systems make it increasingly feasible to auto-generate reviewer briefs instead of relying on manual package research.

Regulatory & technical constraints

• A blocking intake gate must integrate cleanly with SCM status checks and protected-branch or ruleset models or teams will bypass it.
• Provenance and attestations improve traceability but do not prove a package is non-malicious, so reviewers still need policy and judgment.
• Private registries, transitive dependencies, and package-manager differences complicate accurate first-time package detection.
• Compliance guidance raises urgency but does not mandate a specific vendor category, so procurement may still be slower than product urgency suggests.

Competition is crowded but uneven. GitHub and GitLab own the merge surface, broad AppSec suites own budget lines, and supply-chain specialists own malware and reachability narratives. The proposed startup is strongest if it focuses on a narrow approval workflow: first-time package intake, substitute suggestions, and reusable policy memory.

Why incumbents do not win by default

• SCM platforms. GitHub and GitLab already sit in the pull-request path, but their current dependency features center on visibility, status checks, and policy primitives rather than deep org-specific package procurement decisions.
• Broad AppSec suites. Snyk wins on platform breadth and consolidation, which makes it attractive to buyers standardizing AppSec, but that breadth also makes first-time package approval a sub-workflow rather than the core product.
• Supply-chain specialists. Socket and Endor Labs are closest to the threat thesis, but both still lead with package intelligence, malware blocking, reachability, or firewalling more than PR-native approval memory and substitute guidance.
• Provenance and attestation tooling. npm provenance and PyPI attestations improve integrity evidence, but they do not decide whether a given package should be adopted inside a specific engineering organization.

This company should start as a GitHub-native dependency intake gate for AI-assisted software teams, not as a broad software composition analysis or runtime supply-chain platform. The first customer is a Series B-D AI-native B2B SaaS company with 150-600 engineers, a shared monorepo, formal Cursor or Copilot rollout, and only 1-3 platform-security engineers who currently approve unfamiliar packages in Slack or PR comments. The buying trigger is usually an AI coding rollout review, a near miss involving an unfamiliar package, or executive pressure to show auditable OSS controls before the next procurement or compliance review. Research supports a focused market with an estimated $168.0M TAM, $38.4M SAM, and a reachable $4.8M year-3 SOM if the company can convert roughly 100 beachhead customers at the modeled per-developer spend. The product should begin in advisory mode on GitHub for npm and PyPI dependencies, prove that it shortens first-time package review while steering developers toward approved substitutes, and only then expand into blocking policies, more ecosystems, and broader OSS procurement controls. The deliberate tradeoff is to own the first-time package approval decision inside the PR instead of competing head-on with GitHub, Snyk, Socket, and Endor on full-spectrum scanning breadth. The biggest disconfirming risks are that target teams do not add enough net-new packages each month to justify a standalone workflow product, or that GitHub and specialist incumbents add "good enough" approval memory before this startup builds meaningful policy data. The inputs do not quantify real package-intake volume per target engineering team, so pilot design must test that pain directly before the company scales hiring or spend.

Problem

• AI coding tools increase the number of unfamiliar open-source packages proposed in pull requests faster than small platform-security teams can review them.
• Existing scanners and manual Slack approvals usually act after a package is already in the repo, leaving no reusable, auditable approval memory at the moment of first adoption.

Solution

• Detect every first-time npm and PyPI dependency introduced in a GitHub pull request, generate a provenance and behavior brief, and route the decision to the right policy owner before merge.
• Build an internal catalog of approved packages, rejected packages, and safer substitutes so future PRs resolve faster and developers are nudged toward known-good options.

Why we win

• The wedge is narrower than broad SCA platforms and maps directly to the first package-adoption decision where urgency, buyer ownership, and measurable workflow ROI are clearest.
• Approval history compounds into org-specific policy memory and substitute recommendations that incumbents do not yet appear to center as the core workflow.
• Starting inside GitHub PRs matches how the beachhead customer already reviews AI-written code, which lowers change-management burden relative to a separate security console.

Milestones

flowchart LR
  Wedge[GitHub first-time package intake wedge] --> MVP[GitHub npm and PyPI advisory gate]
  MVP --> Proof[Faster documented package decisions and approved catalog]
  Proof --> Expansion[Blocking policies, more ecosystems, and OSS procurement controls]

Founding team

Experiment roadmap

Risk assessment

What must be true

• Target customers must experience enough first-time npm or PyPI package additions each month to justify a standalone approval workflow.
• Advisory-mode deployment must reduce median package review time to under one business day without creating developer backlash.
• At least half of pilots must convert because reusable package memory and substitute guidance are valued beyond what GitHub or existing scanners already provide.
• A protected-engineer pricing model around the researched benchmark must fit existing AppSec or engineering budgets without heavy services work.
• GitHub-first design partners must provide enough policy data to build a defensible substitute and approval memory before incumbents close the feature gap.

Open diligence questions

• How many net-new npm and PyPI package approvals does the target customer actually process per month after an AI rollout?
• What percent of target buyers will start in advisory mode versus demanding immediate blocking on unknown packages?
• In live evaluations, which package-review steps are still unresolved by GitHub dependency review, Socket, Snyk, or Endor Labs?
• How often can the product recommend an already approved substitute instead of approving a new external package?
• What level of false positives or review latency causes engineering teams to bypass the workflow?

Model sanity

• Revenue engine. Base-case revenue is driven by growing from 12 customers at Q4Y2 to 65 at Q4Y3 while expanding ACV from roughly $54K to roughly $82K through broader repo coverage and automation tiers.
• Must go right. The company must convert pilots to annual subscriptions on roughly a 90-day cycle and start getting partner-sourced pipeline by Y3 to support the modeled logo ramp.
• Model breaks if. If package-intake volume is too low to justify 300-plus protected seats or sales cycles stretch to 120 days, cash trends toward the downside case and Y3 profitability disappears.
• Next-round proof. Hitting 10-12 production customers with advisory-to-blocking adoption by Q4Y2 is the milestone that should justify the next financing.

Scenarios

Sensitivity

flowchart LR
  Leads --> Pilots
  Pilots --> ProductionCustomers
  ProductionCustomers --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: The base case still requires a sharp acceleration from 12 customers at Q4Y2 to 65 at Q4Y3, so partner-channel execution is the single biggest forecasting risk. · The model assumes customers eventually cover more than the 250-seat SOM cross-check because multi-repo expansion and automation tiers lift ACV; if buyers resist that expansion, Y3 revenue will undershoot. · Real package-intake volume per target engineering team remains unproven in the source material, so retention and expansion depend on pilot evidence that recurring review volume is actually high enough.

• Incumbent bundling. Existing dependency-security vendors could add a basic PR approval workflow and compress the wedge before the company builds brand. Mitigation: Win on workflow depth, substitute recommendations, and internal catalog compounding rather than on raw scanning alone, then lock in design partners early.
• Review friction backlash. If the gate slows merges or creates noisy false positives, engineers and buyers will bypass it or reduce policies to audit-only mode. Mitigation: Launch with advisory mode, one-click approvals, and tight SLAs on review generation, then expand blocking rules only after trust is earned.
• Weak urgency outside AI-native teams. Traditional software teams may not yet feel enough package-intake pain to buy a new control layer before a visible incident. Mitigation: Focus the first two years on AI-native software companies with formal coding-assistant rollouts and use their package-volume metrics to prove ROI.