How the audit actually works

01 You submit your code

The form takes a repo URL: GitHub, GitLab, Bitbucket, public or private (invite [email protected] as a read-only collaborator). If sharing a whole repo isn't an option yet, paste the part you're worried about into the message field: an auth module, a payment flow, that one file everyone is afraid to touch.

Context helps us aim. "We're about to onboard a big customer and I don't trust the billing code" gets you a sharper audit than a bare URL. But a bare URL works too.

02 An engineer reads it, by hand

A senior Webisoft engineer (someone who ships and rescues production systems for our clients) sits down with your code. We use static analysis and dependency scanners the way you'd use a spell checker: as input, not as the answer. The judgment calls are human:

• Security: injection points, unsafe input handling, auth and access-control gaps, session handling.
• Secrets: credentials in the codebase or still alive in git history.
• Dependencies: known CVEs, abandoned packages, and how expensive the upgrade path is getting.
• Code quality & tech debt: error handling that swallows failures, duplication, dead code, the patterns that tax every future change.
• Performance & scale: N+1 queries, missing indexes, synchronous bottlenecks, architectural ceilings.

What we deliberately skip: style opinions, formatting, framework tribalism. If a finding wouldn't change a decision you make, it doesn't go in the report.

03 You get a written findings report

Within a few business days you receive the report by email. Every finding has four parts:

• Severity: high / medium / low, honestly assigned. Not everything is critical, and we say so.
• Location: file and line, so your team can go straight to it.
• Why it matters: the failure mode in plain language: what breaks, who exploits it, what it costs.
• Suggested fix: concrete enough that any competent developer can act on it.

The report is yours. Hand it to your team, your contractor, or your board. There is no watermark-shaped hostage situation.

04 What happens to your code (and to you)

We read your code to audit it; we don't retain it, share it, or train anything on it. If you invited us to a private repo, revoke access after. We won't be offended. NDAs: yes, we sign reasonable ones, mention it in the form.

Afterwards you get exactly one follow-up email: the findings. If you want help fixing them, we'll quote it. If you don't, that's the end of the thread. The business model is simple: enough audited teams eventually need engineers, and by then we've already proven we can read their code. No drip campaign required.