Audit from a single angle and something always slips through. sec-audit reviews your source code through six deliberately different lenses, catching the vulnerabilities one angle misses. Every finding ships with a runnable proof-of-concept (PoC) and a regression test — and the report shows exactly how far the audit reached. The audit is carried out by us, working hand in hand with your team.
Even after a security assessment, these doubts tend to linger.
Reports list only what was found. What wasn't examined — and what risk remains — stays invisible, so there's no real basis for confidence.
Scanners and one-shot AI reviews only catch what their angle is good at. Broken authorization, business-logic flaws and misconfig need a change of perspective.
"Possible XSS" with no steps and no PoC means the dev team can neither start nor verify the fix.
Inconsistent severity makes it hard to know what to fix first — and hard to explain to leadership.
Without a regression test, the same hole comes back in the next release. It never becomes a durable fix.
Outcomes depend on the reviewer's experience. The same code yields different findings depending on when and who looks.
Each class of vulnerability has an angle it shows up best from. Some flaws are only visible when you follow the data flow; some authorization gaps only surface when you trace the business flow; some risks only appear when you comb through config and dependencies. Fix on one angle and its entire blind spot disappears.
sec-audit reviews your codebase independently through six deliberately different lenses, then reconciles what each one found into a single, superior list.
Trace untrusted input from source to dangerous sink.
Apply spoofing / tampering / disclosure threats per trust boundary.
Verdict OWASP ASVS requirements chapter by chapter, building a coverage ledger.
Sweep SQL, command, file and outbound calls by category.
Follow login, authorization and billing flows to catch IDOR and privilege gaps.
A baseline pass across the OWASP Top 10.
Most assessments only show what was found. sec-audit also states how much of the recognised standard was verified and which areas remain unchecked — so confidence rests on numbers and evidence.
Each OWASP ASVS requirement is judged pass / fail / not applicable. A ledger records what was examined and where things were healthy.
Anything static analysis cannot confirm (runtime config, actual values) is flagged as "not yet verified", with the recommended next step (dynamic testing).
Re-audit after fixes to compare coverage and residual risk in numbers. Use it as a continuous quality gate.
Below is an excerpt from an actual audit of a web app. All targets and identifying details are anonymized.
Audited through six lenses. Where a single-angle audit would surface ~10 issues, sec-audit found 30 vulnerabilities.
| Severity | Count | Representative issues |
|---|---|---|
| CRITICAL | 1 | Protected endpoints with authentication effectively disabled |
| HIGH | 13 | SSRF, XSS (×3), plaintext secrets, wildcard CORS, unauthenticated file access (×3), known-CVE dependencies, denial of service (×2), and more |
| MEDIUM | 12 | Path traversal, no account lockout, unvalidated input, log tampering, unbounded upload size, and more |
| LOW | 4 | Timing-based inference, verbose error disclosure, missing external-resource integrity, and more |
Every one of the 30 findings gets a report at this depth. Below are five (all anonymized). Each ships with the offending code, a fix, a proof-of-concept (PoC) and a regression test.
The authentication decorator was written in the wrong order, so on five "auth-required" endpoints authentication was never actually applied. An unauthenticated attacker could freely upload and retrieve files that were meant to be protected.
Impact: theft of sensitive files, arbitrary file upload (a foothold for stored XSS). Fix: swap the order at the 5 sites (5 lines, immediate).
# Before (vulnerable): auth decorator above route → never applied @login_required @app.route('/files/<name>') def download(name): ... # After (fixed): just swap the order @app.route('/files/<name>') @login_required def download(name): ...
A URL-import feature fetched the supplied URL with no scheme validation, host restriction or timeout. An authenticated user could reach internal services and cloud metadata (IAM credentials), enabling internal API scanning and credential theft.
Impact: disclosure of internal APIs and cloud credentials. Fix: validate scheme, block internal IPs, disable redirects and set a timeout.
def is_safe_fetch_url(url): p = urlparse(url) if p.scheme not in {'http','https'}: return False ip = ipaddress.ip_address(socket.gethostbyname(p.hostname)) if ip.is_private or ip.is_loopback or ip.is_link_local: return False # block internal / cloud metadata return True resp = requests.get(url, allow_redirects=False, timeout=10)
Markdown-to-HTML rendering was incompletely sanitized, allowing arbitrary code to run in a viewer's browser. Only an exact <script> match was stripped, so <img onerror=…> slipped through. The bundled DOMPurify was not being used.
Impact: session-cookie theft, account takeover. Fix: sanitize with the already-bundled DOMPurify before rendering.
// Vulnerable: only exact <script> removed → onerror attribute slips through html = html.replace(/<script>/gi, '').replace(/<\/script>/gi, ''); // Fix: use the bundled DOMPurify return DOMPurify.sanitize(html, { FORBID_ATTR: ['onerror','onload','onclick'], FORBID_TAGS: ['script','iframe','object'] });
The config file stored the session key, external API keys, mail credentials and user passwords in plaintext. If that file ends up in the repo or a backup, or is exposed by a misconfig, every credential leaks at once.
Impact: session forgery, takeover of external services, billing abuse. Fix: move to environment variables / a secrets manager and exclude the file from version control.
# config.yaml — secrets stored in plaintext (values hidden) secret_key: "***" # session forgery possible ai_api_key_a: "***" # external AI service billing abuse ai_api_key_b: "***" mail_app_password: "***" # mail account takeover users.*.password: "***" # user credentials # Fix: move to env vars; keep the config file out of version control app.secret_key = os.environ["APP_SECRET_KEY"]
A heavy bulk-processing endpoint had neither authentication nor rate limiting. An unauthenticated attacker could spawn unbounded worker threads just by calling it repeatedly, exhausting CPU, memory and file handles until the service stops.
Impact: full outage (loss of availability). Fix: add authentication, rate limiting and a concurrency guard.
# Vulnerable: no auth, no rate limit, no thread cap @app.route('/bulk-extract') # ← no auth / rate limit def bulk_extract(): threading.Thread(target=extract_all).start() # unbounded spawn # Fix: auth + rate limit + concurrency guard @app.route('/bulk-extract') @login_required @limiter.limit("2 per minute") def bulk_extract(): ...
Alongside the technical report, we attach a one-page summary of business risk (data leakage, outage, credential compromise) and "what to do this week", in language non-technical stakeholders understand.
We don't stop at "found it". You get everything your team needs to fix it directly and prevent regressions.
A consolidated, superior list with severity, CVSS score and fix priority.
One file per vulnerability: CWE class, repro steps, code evidence, before/after fix.
A script that actually triggers the vulnerability — concrete proof the attack works.
Tests that fail on the vulnerable code and pass once fixed. Wire them into CI to block recurrence.
How far the recognised standard was verified, and what remains — the basis for confidence.
Business risk and a remediation roadmap on one page — ready for decisions and reporting.
It combines the coverage visibility and the actionable evidence that a lone scanner or a single review can't provide together.
| Dimension | Manual pentest | Automated scanner (SAST/DAST) | One-shot AI review | sec-audit |
|---|---|---|---|---|
| Multi-angle auditing | reviewer-dependent | ✗ | ✗ | ✔ |
| Coverage made visible | △ | ✗ | ✗ | ✔ |
| PoC attached | ✔ | ✗ | rare | ✔ |
| Regression tests attached | ✗ | ✗ | ✗ | ✔ |
| Standards-based (ASVS/CWE/CVSS) | reviewer-dependent | △ | △ | ✔ |
| Reproducible / consistent | low | high | medium | high |
| Cost / speed | costly | fast | fast | fast |
Not "trust us, it's our own scale" — we audit, classify and score against standards used worldwide, so the results are explainable to third parties.
The de-facto standard for web-app security verification. Used as the pass/fail criteria for what must be satisfied.
Every finding is classified with the standard MITRE CWE taxonomy — a shared vocabulary.
Reproducible, explainable severity scoring that makes prioritization defensible.
Surface vulnerabilities with a coverage trail before you go live. Launch with confidence.
Assess the security health of a target's code assets with a standards-based report.
Re-audit each quarter and track coverage and residual risk in numbers.
Wire the regression tests into CI to mechanically block the same vulnerability from returning.
Audit outsourced code from a third-party angle before acceptance, returning findings with concrete evidence.
After an incident, sweep for similar holes elsewhere from a fresh set of angles.
Code you entrust to us is analyzed by us in an environment isolated per engagement (under NDA; deleted after the work). The audit is primarily static (reading the code) and does not send it externally.
Anything static analysis can't confirm (runtime config, actual values) is stated as "not yet verified" — neither overstated nor understated. We do not guarantee zero residual risk; we raise coverage with our multi-lens method and show how far it reached, in numbers.
Findings we couldn't corroborate are marked "confidence: low". We don't present guesses as certainties.
Because we audit against standards, coverage is consistent whenever it runs.
It documents the design rationale, the evaluation method and the empirical data so third parties can verify the methodology. sec-audit's multi-lens audit is based on this research.
VSAT: Measurable-Completeness Multi-Lens LLM Auditing for Web Application Vulnerabilities
Hirashima, Daishiro (Toyo System Co., Ltd.) · Preprint · 2026 · DOI: 10.5281/zenodo.21402202
The method audits one codebase through several different lenses and, from the overlap structure of what they find, statistically measures "how completely the vulnerabilities were discovered". Across three benchmark apps it achieved 94.7–100% category recall and 2.4–3.4× more vulnerabilities than a single-pass audit.
Major web-app stacks (various server-side languages and frameworks, plus the front end). We tune which lenses to emphasize to the target's makeup. Ask us for specifics.
A pentest mainly attacks a running service from the outside. sec-audit reads the source code from multiple angles; its strengths are coverage visibility and fix-ready PoCs and regression tests. The two are complementary — we recommend dynamic pentesting to corroborate after the important fixes.
The core is static source analysis. If you provide a running URL, triggering some PoCs against the live environment is also under consideration.
No. Coverage honestly reflects how much remains unverified; apps with a broad attack surface naturally leave more margin. It's not danger itself — think of it as a map of "how far we looked / what to look at next".
Yes. Code is handled in an environment isolated per engagement, and deliverables are treated under confidentiality. We explain the specific terms when you get in touch.
From small apps to large codebases. We set a focus scope by size to get the most coverage within the available time.
Pricing is a quote based on the scope and duration of the engagement (a professional-services / quasi-mandate engagement). We estimate it after hearing your codebase size and scope. Please get in touch.
A professional-services (quasi-mandate) engagement. We work alongside your team with due professional care, drawing on your knowledge through interviews to carry out the audit together. It is not a build-to-completion contract; we provide the reports and outputs that emerge through the engagement.
Rather than one-sidedly delivering a finished product, we carry out the audit together with your team, learning your context as we go. We provide professional services with due care — this is not a build-to-completion contract.
Start with a free consultation. Tell us the target and goal, and we'll propose the right audit scope.
Contact us — free consultation