REQPROOF // TRUST · SECURITY // LEGAL // DISCLOSURE
PUBLISHED POSTURE · REVIEWED 29 JULY 2026
PUBLISHED DEFAULTS, NOT PER-DEAL TERMS
reqproof
§1 Security · legal · disclosure

Everything a vendor review asks, in one document.

Proof is an audit firm. We read source code inside a scope you declare and hand back evidence that lives in your repository. We don't run your production systems and we don't process your customers' data. This page carries the whole review: the data flow and the subprocessors by name, the contract and IP posture, and how we handle disclosure.

PUBLISHED POSTURE · REVIEWED 29 JULY 2026 NOT NEGOTIATED PER DEAL

Published defaults

Source

Read-only, least-privilege access to the scoped repository, or the gate runs on your own CI runners and no source leaves your perimeter.

Models

Named providers, commercial API terms, your code never used for training.

Findings

Private by default; publication requires written approval.

Exit

You revoke access, we delete clones, written confirmation on request.

§2 How to route this page

Three readers, one document.

Split across three pages, these answers have to be reviewed together every time one of them changes, and the version that contradicts the other two is the one your reviewer finds. So it is one page. Send the anchor that matches the reader.

for security review
Data flow, subprocessors, CI option

What we clone, where it lands, which providers see it, what we never touch, and the mode where nothing leaves your infrastructure.

for counsel and procurement
SOC 2, IP, contracts, continuity

The SOC 2 answer without hedging, who owns the deliverable, the contract set, and why the artifacts do not depend on us.

for maintainers and reporters
Coordinated disclosure

How security findings are handled, who is told first, how embargoes are set, and how to report something in reqproof.com itself.

§3 For security review

Where your source code goes.

Two access modes, and you pick. Either you grant read-only access to the scoped repository and we clone it on our side, or the audit gate runs on your CI runners and the source never leaves your perimeter. Everything below describes the first mode, because it is the one that needs the disclosure. The second mode is the next section.

What we clone

Only the repository, branch, or archive named in the SOW, at an agreed commit. No sibling repositories, no infrastructure, no data stores, and no production access.

Where it lands

Reviewer workstations under our control, with full-disk encryption and MFA on every account that can reach the code. No personal devices, no shared logins, no removable media. If an engagement needs a dedicated cloud instance for a long build or fuzz run, we name the provider and the region in the SOW before it is created.

Jurisdiction

We state the storage location and the contracting entity's jurisdiction in writing before you grant access, and we will accept a contractual restriction on both. If your policy needs that fixed before a technical call, ask for it first.

Third-party CI

None. Your code does not enter a hosted build service, a cloud sandbox, or a code-search product of ours. The only CI it touches is yours.

Source access

Use the narrowest practical access mode: public source, read-only private repo access, exported archive, specific branch, or customer-provided artifact bundle.

Credentials

Read-only and least-privilege: a named account or a scoped token limited to the audit path, issued by you and revocable by you at any time. We do not ask for organization-wide access, an owner role, write permission, or CI secrets.

Secrets

Customers should not share production secrets. Proof scopes review around source, tests, configs, traces, and reproducible fixtures.

Retention while running

For continuous coverage we keep only what the gate needs to rerun: the approved requirements, the known-issue register, and one reproducer per finding. All of that already lives in your repository.

Deletion at exit

You revoke access on the last day of the engagement. Working clones and analysis artifacts are deleted within 30 days of final delivery, or immediately if you ask, and we send written confirmation of deletion on request.

You hold the off switch. We'd rather you cut the credential than take our word that we stopped using it. Every access mode above is built so that revoking it costs you one action, and so that an early revocation ends the work cleanly instead of leaving anything of yours on our side.

§4 For security review

The audit can run entirely on your runners.

The gate is a binary plus a corpus of plain YAML and tests. Both run in your CI, under your credentials, on your infrastructure. In this mode we work from gate output, diffs, and evidence you publish to us; there is no clone on our side, no token of yours on our machines, and nothing for us to delete at the end.

  • This mode falls out of how the deliverable already works. Every fixed finding becomes a regression test that fails your build the day the defect tries to come back, so the gate has to run where your build runs.
  • What we need from you: a runner, visibility into gate output and diffs, and a channel for questions about specific code paths.
  • What we do not need: a clone, read access to your source, or a credential of yours on our side.
  • The tradeoff is real and we'll say it plainly. Reviewing from evidence you publish is slower per question than reviewing with the tree in front of us, and some classes of work still need a scoped clone. If your policy rules out vendor-side access, we scope for that from the start rather than discovering it in week two.
# .github/workflows/correctness-gate.yml
# your runners, your credentials
jobs:
  correctness:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: proof audit --fail-level warn

# The corpus the gate reads is in your repo:
specs/          approved requirements, plain YAML
.proof/issues/  known-issue register
tests/          one reproducer per finding
fig · the gate resolving, check by check
§5 For security review

Who else touches the code, by name.

Proof is expert-signed and machine-verified: tooling carries the breadth of the reading and a named reviewer carries the judgment. That puts model providers in the data flow, so they belong on this page by name instead of in a negotiation.

SubprocessorWhat it seesStanding default
Anthropic, OpenAI
model inference
Code, tests, and configuration inside the declared audit scope, when the audit runs on our side. Nothing at all in runs-in-your-CI mode. Commercial API terms only. Your code is not used to train models. No consumer or free-tier product, no chat surface, no third-party plugins. Zero-retention terms are the default for engagement work, and we confirm the configuration in writing before you grant access.
Cloudflare
website
reqproof.com hosting and website form submissions: the fields you submit, a timestamp, the source page, and approximate country. No customer source code. Website only. Nothing from an engagement is stored or processed here.
Your code host and CI
your tenancy
A read-only clone of the scoped repository, or the gate running on your runners. Your tenancy, your audit log, your revocation. We add no repository host of our own and we never mirror your code to one.

This site makes no third-party request at all. Type is set in the reader's own system monospace stack, so no webfont is fetched. No analytics, no cookie banner, no tracking scripts, no session storage. Check the page source.

Not on this list, and not added without telling you first: hosted build services, cloud sandboxes, code-search or indexing products, offshore contractors, analytics on engagement artifacts, and any warehouse or backup service. The exact providers and models for your engagement are named in the SOW. If a new subprocessor would touch your code, you get written notice before it does, and you can refuse it.

§7 Continuity and ownership

No vendor dependency.

Everything we produce lands in your repository: the requirements your architects approved, the known-issue register, one runnable reproducer per finding, the regression tests, and the gate that runs them. Plain YAML and tests in git, executed by your CI on your runners.

  • The artifacts and the gate outlive the engagement. If the work stops, whatever the reason, your team keeps a corpus it can read, rerun, and extend without us.
  • There is no Proof account to lose, no export to request, and no proprietary format to reverse-engineer. What ends is the ongoing review.
  • We take a limited number of engagements each quarter, so the calendar is a real constraint on when work can start. It puts no constraint on anything you already hold.

Who owns what.

You own everything delivered: requirements, register, reproducers, regression tests, reports. Yours to keep, extend, publish, or delete, with no license back to us and no attribution required.

  • The engine stays ours. Our tooling, internal signal packs, scoring, and private corpora are not part of the deliverable and are not licensed to you.
  • Nothing you receive depends on seeing them. Each finding is delivered with its reproducer, its severity rationale, the affected surface, and the retest result, and it reruns in your CI.

Plain version: Proof's engine is private. The evidence you receive should not be a black box.

§8 For counsel and procurement

Contract posture.

Mutual NDA

We countersign yours, and we'd rather sign before the technical conversation than after. We never ask for repository access without one in place.

MSA and SOW

An MSA plus a one-page SOW per engagement, with a liability cap stated in the MSA. We can work on your paper.

Scope and fee

Engagements are fixed-fee and scoped to a named component before work starts, so the SOW states what is in scope and what is excluded. Remediation work is scoped separately and never bundled into an audit.

Data processing

DPA available on request. In most engagements there is no personal data for it to cover, because we read source, tests, and fixtures rather than production data. Where the scoped repository does carry personal data, it goes in scope.

Procurement packet

Before access: contracting entity, jurisdiction, tax forms, and your security questionnaire. Tell us which insurance limits and which forms your process requires, and we will confirm in writing what is in place before you grant anything.

Stated bound

Assurance is bounded: within a declared scope, for declared behaviors, with evidence commensurate to the consequence of failure. That bound goes in the agreement, along with our refusal to claim that any software is free of defects.

§9 Severity provenance

Where a severity rating comes from.

Severity is our own assessment, weighted by reachability and impact, and it is offered as a starting point for your triage. It is not a CVSS score and not a vendor determination.

If you disagree with a rating, the reproducer under it is still the fact, and the rating is the part we'll argue about with you.

Reports also publish their own triage boundary: the candidates we investigated and dismissed, and the reason for each. The five gates a finding clears before delivery are on the methodology page, published so a reviewer on your side can hold a delivered finding against them.

§10 Disclosure, naming, and lead data

Security findings are coordinated.

  • Findings are shared with the customer or authorized maintainer first.
  • Publication, third-party notification, and advisory language require approval.
  • Embargo timing, CVE/advisory support, and maintainer coordination are agreed per finding.
  • Reports distinguish correctness impact, security impact, exploitability, preconditions, confidence, and remediation status.

Reporting something in reqproof.com itself, or in anything we shipped: email [email protected]. Good-faith reports get a reply within two business days and an embargo window agreed with you rather than imposed on you.

No public naming without approval.

  • Customer name, repository, source code, findings, and evidence artifacts are private by default.
  • Public field notes, case studies, or sanitized reports require written customer approval.
  • Coordinated vulnerability disclosure, embargoes, advisories, and CVE support are handled case by case.
  • Proof does not publish customer-specific intelligence as marketing material without approval.

Form data is used for scoping.

  • Contact forms collect the fields submitted, timestamp, source page, and approximate country from Cloudflare request metadata.
  • Form data is used to reply, qualify fit, and prepare a scoping conversation.
  • To request deletion of a lead record, email [email protected].
  • Do not submit secrets or private source code through the website form.
§11 Routing and standing

One address, three subjects.

Everything on this page routes through [email protected]. Put security review, contracts, or disclosure in the subject line so it routes correctly. Questionnaires, NDAs, and a written data-flow summary for your file are all handled before you grant access.

If your reviewer wants the engagement shape alongside the terms, that's on the audit page, and the method it runs is on the methodology page.

This page is the published posture, reviewed 29 July 2026. When a default changes, this page changes and the date changes with it. Nothing here is negotiated per deal; anything stated as available on request is a commitment we will put in the agreement.

Commercial identity

  • Proof is built and operated by ProbeLabs.
  • Contracting entity, jurisdiction, tax details, and insurance posture are confirmed in writing before you grant access.
  • Security, legal, and vendor questionnaires route through [email protected].

Signatory

Leonid Bugaev

Leonid Bugaev · Founder, Proof. Author of GoReplay and jsonparser. Every finding is validated by a named reviewer before it reaches you.