Your security principles,
    held in every change,
    from first prompt to merge.

    aws
    Notion
    Slack
    Page 1 · From public pages
    Chairbnb, from the outsideChairbnb runs a marketplace where people rent out chairs, from a reading armchair for an afternoon to a front-row balcony seat for a parade. Hosts list their chairs with photos, a price and an address; guests book, pay and message their host in the app. Event organizers book chairs in bulk through a partner API.
    SellsChair rentals by the afternoon, the weekend or the event, booked and paid in the app
    ServesGuests who rent, hosts who list, event organizers who book in bulk
    Runs onWeb app, iOS and Android apps, a partner API, a host dashboard, internal admin tools
    HoldsIdentities and ID checks, exact chair addresses, host–guest messages, reviews, booking history, host payouts
    ProvesNothing published: no certification or trust center found
    ReportsNo public security contact found
    1 public pagechairbnb.com
    Page 2 · From your code
    Chairbnb, from the inside3 products, 18 apps and the assets they touch, mapped from 81 repositories.
    81 repositoriesgithub.com/chairbnb
    ChairbnbSecurity PrinciplesWhat must always be true, wherever Chairbnb’s code runs.
    Art. IA host only sees a guest’s details for their own bookings.
    Art. IIA chair’s exact address is only revealed to a guest once their booking is confirmed.
    Art. IIIMessages are only visible to the two people in the conversation.
    Art. IVPayment data never leaves the payment provider.
    Art. VA partner’s API key only reaches that partner’s bookings.
    Art. VISupport staff only open an account with a logged reason, and every admin action is recorded.
    ChairbnbSecurity book2 pagesChairbnbSecurity bookKept current by Konvu
    PreventBefore merge
    142pull requests reviewed this week
    •
    Show guest phone on booking cardChecks running
    marketplace #453+9−1
    ×Security Principle brokenHigh
    Art. I A host only sees a guest’s phone for their own bookings.
    + phone: guest.phone BookingCard.tsx:31
    •
    Add host earnings chartChecks running
    host-dashboard #452+64−8
    ×
    Add booking export for hostsCI failed
    marketplace #421+48−3
    ×Security Principle brokenHigh
    Art. I Any host could export every guest’s ID scan.
    + return db.bookings.findAll() export.ts:14
    ✓
    Retry failed partner webhooksMerged
    partner-api #445+31−9
    ✓
    Cache search results for 60sOpen
    web-app #440+22−5
    ×
    Show chair address on listing pageCI failed
    marketplace #438+12−2
    ×Security Principle brokenCritical
    Art. II Exact address visible before the booking is confirmed.
    + <Address value={chair.address} /> Listing.tsx:42
    ✓
    Rename payout status enumMerged
    payouts #436+17−17
    Triage & FixAfter detection
    12,847open findings
    IDServiceVerdict
    CVE-2026-0544partner-apiExploitable
    CVE-2025-3301web-appFalse Positive
    CVE-2025-48734admin-apiReproduced
    CVE-2026-1187payouts-workerFalse Positive
    CVE-2024-38816web-appRemediated
    GHSA-4w8r-3xrw-v25gadmin-apiFalse Positive
    CVE-2026-0412ingressFalse Positive
    CVE-2025-7714host-dashboardFalse Positive
    GHSA-9wx4-h78v-vm56partner-apiFalse Positive
    Your book, anywhere
    Claude CodeCursorGitHub CopilotJiraLinearNotionSlack
    $ konvu book · CLI · MCP · API

    Backed by founders and executives from

    GitHub logoDocker logoCloudflare logoDatadog logoSumo Logic logoVanta logoincident.io logo
    The problem

    Severity is what you were told. Exploitability is what we prove.

    One finding, seen two ways.

    What the scanner said: High severity, Semgrep node-postgres-sqli at src/reports/query.ts:118. Possible SQL injection. User input flows into a raw query string. Reachability: potentially. Exploitable: unknown. Reasoning: none attached.What Konvu proved, false positive: SQL injection in the report query builder (node-postgres-sqli). The interpolated value is a column name, checked against a fixed allowlist two frames up before it reaches the query. No request data reaches the SQL string. Sink reached from a handler: yes, 2 call sites. Value is interpolated raw: yes, no parameterisation. Value comes from the request: no, allowlisted column (decides it).
    Product intro

    The short version

    A finding arrives, gets investigated, and gets closed with the evidence attached to the ticket.

    How it works

    Every step at attacker speed

    1. 01

      Connect

      Keep the scanners you already run. Konvu reads their findings.

      Konvu integrations. Connect the scanners you already run: Snyk, Semgrep, Wiz, Black Duck, Trivy, Checkmarx, and 20 more, each shown installed. Drive it from anywhere: REST API, konvu CLI, MCP server, Konvu Dashboard.
    2. 02

      Enrich

      What each service exposes and what it handles, joined to our vulnerability database, where the conditions that make each CVE exploitable are written down.

      Risk profile for payments-api, a crown jewel. Exposure 100 of 100: Internet exposed, Serves web UI, Internal network reachable. Access 54 of 100: SSO · open enrollment, MFA · not enforced, ACL · none. Stakes 100 of 100: Secrets, Customer data, Cloud credentials. Blast radius 37 of 100: Single tenant, No shared datastore, IAM role · scoped. Attackers 100 of 100: In CISA KEV, Ransomware · active use, Exploit PoC · public. 6 findings here outrank 240 on internal-tools, none of which touch a crown jewel. konvu, 3m 41s, 47 tool calls.
    3. 03

      Prove

      The verdict, with the reasoning trail and the code that decided it. One finding proved exploitable, one proved not, because a verdict only counts if it can come back either way.

      False positive: minimatch: catastrophic backtracking on nested extglobs (CVE-2026-27904). The bug needs a nested *() pattern to build the backtracking regex. Every pattern here is read from config at boot, so the attacker never supplies one. minimatch() on a request path: yes, src/api/files.ts:64. Attacker controls the input: yes, the upload filename. Attacker controls the pattern: no, static from globs.json (decides it). Reasoning trail: the upload filename reaches minimatch() at src/api/files.ts:64, but the pattern is read from globs.json at boot. Dismissed in Dependabot.
    4. 04

      Fix

      Breaking changes found, call sites rewritten, tests re-run until the branch is green. False positives are dismissed straight back in the scanner that raised them.

      Remediation plan: report-kit to 3.0.0, PR #1284 ready, fix/CVE-2021-23337 to main. lodash 4.17.21 blocked: @acme/report-kit pins <4.17.21. report-kit bumped to 3.0.0: one major, per its migration guide. Breaking changes found: 2 call sites use the removed renderSync. Call sites rewritten: src/reports/render.ts, src/api/orders.ts. Test run 1 failed: 3 failing, snapshot expected the old shape. Test run 2 green: 1,284 passed, 0 failed. PR merged, finding closed in the scanner, evidence on the Jira ticket. konvu, 8m 40s, 2 test runs.
    5. 05

      Prevent

      Tenant boundaries and approval flows can break without a dangerous call for a scanner to flag. Konvu checks relevant changes against security principles in coding agents or CI.

      A coding agent terminal. Prompt: add a GET /orders/:id endpoint. Konvu guidance injected: 1 security principle loaded, handlers that load a record by id from the request must assert the caller owns it, selected from your Security Context Graph. The agent updates src/api/orders.ts and adds assertOwnership(req.user, order). Ownership check written, not caught later. Coding agent path shown; Guardrails also runs in CI.
    Why not just Claude?

    Where a frontier model stops

    We build on frontier models and they keep getting better. Four things they still won't do for you.

    1. 01

      The question is narrower than the model

      Is this vulnerability exploitable in this environment? Answering that needs almost none of a frontier model’s breadth. Narrow and deep beats wide and brilliant.

    2. 02

      The conditions were never written down

      Which function has to be called, with what input, under which configuration, in what deployment. For most vulnerabilities nobody ever recorded it, so no model learned it. We maintain a vulnerability database enriched with exploitability conditions, built one vulnerability at a time.

    3. 03

      Models declare victory too early

      A model that says “not exploitable” after an incomplete investigation produces a false negative that looks exactly like a clean verdict. Nobody pushes back, because nobody knows there was more to check. So the supervision lives in the system: bounded tasks, and verdicts that carry their evidence.

    4. 04

      Graded on exploits, not on approval

      Preference training rewards answers people rate highly. An exploitability verdict is right or wrong whether or not anyone liked reading it. We grade against ground truth our own security engineers labelled.

    Customers

    Proof from real deployments

    All three companies are anonymised at their request. The numbers are not. Each one ran Konvu against a live backlog its own team had already been working by hand, so the comparison is against trained security engineers rather than against nothing.

    4%
    exploitable and worth an engineer’s time
    Read the case study
    96%
    assessed as false positives, each with written reasoning
    Read the case study
    4x
    faster remediation on exploitable findings
    Read the case study
    “Engineers love the evidence. They see that, and it ends many conversations.”
    Security lead, Global Fortune 500
    “There is one week a year when we don’t have pressure. That’s Christmas week. For fifty-one weeks a year, we’re dealing with high CVEs.”
    Security lead, Global Fortune 500
    Latio Application Security Supply Chain Innovator 2026 badge

    Recognition

    "The platform delivers two key outcomes: vulnerability prioritization and remediation, and is well positioned to solve both effectively."

    James Berthoty, Founder at Latio

    Read the full report →
    Works where you work

    Fits the stack you already have

    Konvu Agents write verdicts back into your scanners, open PRs in GitHub, and ping your Slack. Drive the whole thing from the REST API, the konvu CLI, or an MCP server your own agents call. No new dashboard. No rip-and-replace.

    • Snyk
    • Semgrep
    • Wiz
    • Black Duck
    • Checkmarx
    • Veracode
    • Mend
    • Contrast
    • Palo Alto Networks
    • GitHub
    • GitLab
    • Azure
    • Dependabot
    • Jira
    • Linear
    • ServiceNow
    All integrations
    Built for enterprise

    You decide what leaves your environment

    Two deployment models. Konvu Cloud, or our Kubernetes controller running inside your own cluster, where Konvu never has access to your code.

    Cloud or self-hosted

    Run on Konvu Cloud, or deploy our Kubernetes controller in your own cluster. In self-hosted, Konvu never has access to your code.

    Fits your toolchain

    Plugs into Snyk, Wiz, Semgrep, and 20+ others you already run. Need one we don't have yet? We'll build it.

    SOC 2 Type II

    Independently audited and certified for security, availability, and confidentiality controls.

    Configurable policies

    Adapt to any workflow and regulatory environment. Define custom rules and enforce them automatically.

    Privacy by design

    Code is never stored by Konvu or model providers. Never used for training. Privacy guaranteed.

    Expert-led support

    From onboarding to deployment at scale, our team works alongside yours to ensure long-term success.

    Point it at your own findings

    Connect a scanner and Konvu works through the backlog the same way it worked through the ones above, with evidence on every decision.