Skip to content
winfunc
Security audit
Available

Audit the code paths that define your real attack surface.

Winfunc reviews an authorized repository revision with application context, follows relevant source-to-sink paths, and persists the evidence behind each conclusion. Findings keep validation status, assumptions, and remediation context attached so your team can inspect the reasoning before acting.

How it works
  1. acme
  2. /billing-api
  3. /Vulnerabilities
  4. /WF-1042
Critical
Sourceroutes/invoices.ts:18
req.params.invoiceId
Sourceroutes/pdf.ts:31
req.query.invoice
1
Passed to the service without the caller's tenantinvoices.get(id)services/invoices.ts:42
2
Repository looks the invoice up by id alonerepo.findInvoice(id)repo/invoices.ts:71
Sinkrepo/invoices.ts:77
db.query("SELECT * FROM invoices WHERE id = $1", [id])

Cross-tenant invoice read through an unscoped lookup

CriticalCVSS 9.1
Weakness
CWE-639 · Authorization bypass
Confidence
97
Validation
Exploitable
Proof
Tenant A read tenant B's invoice in the sandbox
Finding · source to sinkIllustrative data
  1. Every place attacker-controlled input enters.
  2. Each hop is recorded with the code that carried the value.
  3. The dangerous operation, with no check on the path.
  4. Reproduced in an isolated sandbox before it reached you.
The problem

Security work should end in a decision, not another queue.

A useful audit needs more than a scanner result. Engineers need the exact revision, the path from attacker-controlled input to a vulnerable operation, the controls that were checked, and a clear line between observed evidence and inference.

  1. Authorized scope
  2. evidence-led investigation
  3. report and review
How it works

From scope to an engineering decision.

Define the repositories, application boundaries, revision, permissions, and security questions that should guide the assessment. Where runtime validation is useful, agree on a suitable test environment and explicit testing boundaries.

  1. Scope01

    Agree on the application, questions, and authorized scope

  2. Investigate02

    Map entry points, security boundaries, and high-risk code paths

  3. Investigate03

    Validate candidates against reachable code and existing controls

  4. Review04

    Review version-bound findings and suggested changes with your team

Deliverables

What your team gets.

  1. 01Reviewed scope and revision
  2. 02Source-to-sink findings with supporting evidence
  3. 03Validation status and fixes for engineering review
  • A clear record of the reviewed scope and revision
  • Findings tied to affected code, trigger paths, and vulnerable operations
  • Validation outcomes with checked controls, assumptions, and open questions
  • Reproduction guidance or proof material where feasible and authorized
  • Severity rationale, limitations, and recommended next steps
  • Suggested remediation or an approval-gated fix workflow where appropriate
Why it matters

Give your team a concrete security baseline without making engineers reconstruct the evidence behind every alert.

Measure it

Compare investigation time, supported findings, time to an engineering decision, and remediation lead time against a similar previous assessment.

Scope and limits

An audit covers the agreed code, revision, context, and testing boundaries. It does not guarantee that every vulnerability is found, and untested impact is identified as inference rather than observed behavior.

Explore connected capabilities

Continuous codebase securityAvailable nowThreat modelingAvailable nowCloud securityAvailable now
Start with one repository

Bring us your hardest codebase.
We'll bring the proof.

Scope a first audit with our security engineers. You get findings with traces, reproduction evidence, and patches ready for review.

Scoped with you. Delivered with evidence.