Source Code Security Audit
Manual, human review of your codebase — authentication and authorization logic, injection sinks, cryptographic misuse, secrets handling, and business-logic flaws — with tooling assistance, not a resold SAST report.
Selva Ops S.R.L.
A source code security audit is a manual reading of your code by an experienced attacker — not an automated scan with a logo on it. Tools assist coverage and triage, but every finding is a human judgment about how your specific application can be broken.
What manual review finds that testing cannot
Black-box testing observes behavior from outside; some vulnerability classes are nearly invisible from there:
- Authentication and authorization logic — subtle ordering bugs, confused-deputy paths between services, permission checks that exist on the route but not on the job queue.
- Injection sinks — every place user input meets an interpreter, including ones no crawler will ever reach: log pipelines, admin exports, async workers.
- Cryptographic misuse — ECB modes, static IVs, homemade token schemes,
randomwhere it must besecure random, key material in the wrong place. - Secrets handling — credentials in code, in history, in config files that ship to clients.
- Business-logic flaws — negative-quantity refunds, race conditions in balance updates, state machines with skippable states.
- Dependency and supply-chain risk — vulnerable, abandoned, or over-privileged dependencies, install scripts, and CI configuration.
When white-box beats black-box (and when to do both)
If the asset you are protecting is logic — a billing engine, a permissions system, a multi-tenant boundary — reviewing the implementation is more efficient per hour than probing it from outside. If the question is “what can an internet attacker actually reach”, a web application or API penetration test answers it. For high-assurance releases, pairing both gives testing depth that neither achieves alone, and the combined engagement is scoped to avoid duplicated effort.
Open-source project audits
Open-source projects can commission an audit — or have one sponsored — with a publishable report. Published audits help the ecosystem, and they are the most verifiable form of security work a consultancy can show. If you maintain a project that needs review, that conversation is welcome.
What you receive
- A report with file/line references, evidence, and severity ratings for every finding
- Analysis of authentication, authorization, and session-management implementations
- Dependency and supply-chain risk review
- Remediation guidance at the code level, including suggested patterns
- A walkthrough call with your engineers to transfer context
Standards and references
Compliance context
FAQ
- Is this different from running a SAST tool?
- Yes, and the difference is the product. SAST tools flag patterns and drown teams in false positives; they cannot follow an authorization decision across three services or notice that a discount calculation can go negative. This is human review — tooling assists coverage, a person makes every call.
- SAST vs manual code review — do we need both?
- They complement each other. Keep SAST in CI for regressions and known-pattern bugs; use manual review for logic, design, and the vulnerability classes SAST is structurally blind to. If you already run SAST, the review deliberately focuses where your tooling is weakest.
- When should we choose a code audit over a penetration test?
- Choose white-box review when the risk lives in logic and implementation: payment flows, permission systems, crypto, multi-tenant isolation. Choose a pentest when you need to know what an external attacker can reach. High-assurance targets benefit from both — the combination finds what neither finds alone.
- Do you audit open-source projects?
- Yes. Open-source audits are a standing service line, and with the maintainer's agreement the report can be published — which benefits the project's users and adds to the public record of our work.