Pre-audit: why you should check your product before the expertise

When the official cybersecurity expertise finds vulnerabilities, the process doesn't stop, but it drags on: the report arrives, the team fixes things, the product is resubmitted, and you wait again. Every finding means another round. A pre-audit exists to cut those rounds down.

What a pre-audit is

A pre-audit is an internal or independent review carried out before the official expertise. Its job is to find and close, in advance, the vulnerabilities the expertise is likely to find. A pre-audit does not replace the official check and does not produce any official document. It prepares the product for the check.

A simple analogy: a practice test before an exam doesn't give you the exam grade, but it shows you where you're making mistakes.

Why check it yourself

Most findings are typical

From our own experience: the web expertise of our tax and finance SaaS platform produced 6 findings. None of them was a complex or exotic attack. Open FTP and panel ports, a library sending the full route list to the browser, an app trusting the X-Forwarded-Host header — all of these could have been found in advance with a checklist.

The mobile app told a similar story: no root or jailbreak detection, data stored unencrypted, weak certificate validation. These are requirements spelled out in OWASP MASVS and the Mobile Top 10 (2024).

The developer's blind spot

The team that wrote the code knows it from the angle of "how it is supposed to work." An attacker looks at "how else it can be used." In our case, the "payment successful" page opened even if the payment provider had not yet confirmed the payment. To the developer it was just a return page; to the reviewer it was a business logic flaw.

Time and focus

Every resubmission pulls the team away from its main work: recalling context, fixing, rebuilding, preparing documents. Closing all the typical issues in one go is far cheaper than closing them piece by piece over several rounds.

A pre-audit doesn't make the expertise easier; it starts it earlier, at a time that suits you.

What a pre-audit covers

A good pre-audit mirrors the areas the expertise looks at.

Web applications

• A review against the OWASP Top 10 (2021): access control, injection, misconfiguration, outdated components.
• Business logic: payments, sign-up, password reset, state transitions.
• Information disclosure: error messages, API responses, configuration sent to the browser.
• Server: open ports, services, TLS, security headers, admin panel access.

Mobile applications

• Binary protection: root/jailbreak and emulator detection, protection against dynamic analysis tools such as Frida, integrity checks, obfuscation.
• Data storage: Keystore/Keychain, allowBackup, WebView data.
• Network: certificate pinning, cleartext traffic disabled.
• For submission: MD5, SHA1 and SHA256 checksums.

When to start a pre-audit

The best moment is when the product is functionally complete but not yet submitted for the expertise. Start too early and later changes may bring in new problems. Start too late and there is no time left for fixes, so the team ends up rushing.

In practice, it works well to make the pre-audit a separate stage in the release plan: the code is frozen, the review is done, findings are closed, then a repeat check, and only after that the official submission. This matters especially for mobile apps, because every fix means a new build, a new signature and new checksums.

7 checks you can start with yourself

You can check a lot without hiring anyone:

1. Scan the server from outside with nmap and confirm that only the ports you need are open.
2. Make sure debug mode is off in production and the error page shows no stack trace.
3. Use "View source" and DevTools to see what data goes to the browser in JavaScript: no route lists, keys or internal URLs.
4. Run composer audit or npm audit.
5. Check your site in public header scanners (for example, Mozilla Observatory).
6. Send a request with a foreign host header and make sure that domain does not appear in the response:

curl -s -H "X-Forwarded-Host: example.org" https://your-domain.uz/ | grep example.org

7. Walk step by step through every flow where payments or state change, and tamper with the requests by hand: does the server validate each step itself?

How the Sipar pre-audit works

We run the analysis together: the Claude AI agent and a human specialist. The agent quickly reviews the codebase, configuration and server settings and flags suspicious spots. The specialist verifies every finding by hand, filters out false positives, and either implements the fix or gives your team precise instructions.

What you get:

• A list of findings ranked by severity, with a fix for each.
• Closed holes and the result of a repeat check.
• A submission-ready state: inventory, checksums, a change log.

We do not guarantee the outcome of the expertise in advance — that is the official reviewer's call. Our job is to make sure you arrive there without the known, typical holes.

Summary

A pre-audit is a rehearsal of the official check at a time you control. When typical vulnerabilities are closed in advance, the expertise finishes in fewer rounds and the team stays focused on the product.

Want to start with your own product? Request a security scan — we'll review the main vulnerabilities and suggest the next steps.