Code review. Before your
users find the bugs.

SAST is static application security testing — the scanner reads your source code without running it, tracing data flow through functions, flagging dangerous sinks, insecure APIs, and pattern-based vulnerabilities like SQL concatenation or cross-site scripting. Tooling: Semgrep, SonarQube, CodeQL, and Checkmarx for enterprise environments that need compliance reporting.

DAST is dynamic application security testing — the scanner runs against a live, deployed instance of your application and probes it the way an attacker would, using Burp Suite Professional, OWASP ZAP, or Invicti. SAST catches issues earlier and cheaper but produces false positives and cannot see runtime state. DAST catches issues that only appear at runtime — authentication flows, SSRF against cloud metadata, race conditions, misconfigured reverse proxies — but runs late in the cycle and can miss code paths it never reaches.

Both matter. Run SAST in the pull request, DAST in staging before release, and back both with human review for the classes of finding neither scanner will catch.

Yes, as amplifiers — never as the final word. We use AI-assisted review inside every engagement for pattern recognition, consistency checking across large codebases, and first-pass triage on SAST output to separate real findings from pattern-matched noise. AI is good at the first thousand things. It is bad at deciding which of the first thousand things matter, and worse at reasoning about the business logic that defines what matters in context.

Every finding in the final report is confirmed by a human reviewer with hands on the code, and every piece of guidance is written specifically to your stack. If your codebase is sensitive — defense, healthcare, regulated financial work — we can run the engagement without uploading source to external AI services. The model runs locally on reviewer hardware, or on a VM you provide, or we read the code without AI assistance at all. Confirm that preference at scoping and we configure accordingly.

Yes, always, before source ever moves. Our default posture: mutual NDA executed at scoping; source pulled through a secure, audit-logged channel — SSH key deployed for the engagement, signed-URL bundle expiring in seventy-two hours, or direct clone on a client-supplied VDI; source retained only for the duration of the engagement plus a retention window you specify; destruction attested in writing on close-out.

For highly sensitive codebases — defense primes, regulated fintech, healthcare with PHI access in the test path — we run the review on client-supplied VDI, on-site at your facility, or by flying a reviewer to work from your office. Nothing about any of this is unusual; it is the default for any engagement we take on. If you have a custom DPA or a specific data-handling requirement (CUI, ITAR, HIPAA-covered, PCI-scoped), send it during scoping — we match it.

Yes. Monorepos change the tooling, not the discipline. We scope by path — which services, libraries, and packages are in, which are out — and we set SAST rules per-module so you do not get twenty thousand findings from vendored dependencies, generated code, or mock fixtures. Semgrep is particularly good at monorepo scoping via the Registry plus custom path-based configs, and CodeQL supports per-database scoping across very large trees.

We've worked in Bazel, Nx, Turborepo, Yarn workspaces, Go modules, Maven multi-module, Gradle multi-project, and Pants repos. The review report is delivered module-by-module rather than as one monolithic file, and the remediation branch gets opened per-service so your teams can merge independently without waiting on each other. For very large monorepos — say, 500K lines and up — we staff with two to four reviewers in parallel and still deliver a single, consolidated report.

Yes. SAST, SCA, IaC scanning, and secrets scanning all run best as pull-request-time checks — findings land on the PR where the author can fix them in context, not three weeks later in a remediation spreadsheet. We integrate with GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins, CircleCI, Buildkite, and Azure DevOps. For each tool we set a baseline that does not block merges on day one (you will drown in noise), tune rules over two to four sprints, then move to blocking on critical and high severities.

Secrets scanning always blocks from day one. If the scanner flags a credential in a diff, the PR cannot merge until it is resolved — we rotate the credential and strip it from history, then unblock. Quality gates, signed commits, and SBOM generation get wired in during the same engagement if they are not already. DAST is harder to run in-pipeline because of the running-target requirement, but we integrate OWASP ZAP baseline scans into nightly CI runs against a dedicated staging environment whenever the stack supports it.

Every finding in the report carries a CVSS score, reproduction steps, and a written rationale. If your team disagrees — either on severity or on whether the finding is real — we do a thirty-minute triage call with the engineer who raised the objection and the reviewer who wrote the finding. If the reviewer can demonstrate the exploit path and the impact live, the finding stays as written. If the engineer can demonstrate an existing mitigating control the reviewer missed, the finding is downgraded or accepted with the mitigation documented.

If nobody can tell for sure, we build a proof-of-concept together and the PoC decides. We've had plenty of findings downgraded or struck on review; we've never had a reviewer refuse to reconsider an objection. The goal is a report you can stand behind — one that reads accurately six months from now when an auditor picks it up — not a score, not a finding count, and not a defense of the reviewer's ego.

Depends on scope. A single service or microservice — say, ten to thirty thousand lines of code — is five to ten business days from kickoff to draft report. A mid-size application, fifty to a hundred and fifty thousand lines, is two to four weeks. A full monorepo, five hundred thousand lines and up across a dozen services, is six to ten weeks and runs with two to four reviewers in parallel.

Every engagement begins with a thirty-minute scoping call plus a code walk-through with the tech lead, and ends with a sixty-minute read-out to engineering and security leadership. The included re-test runs inside three to seven business days once you tell us the remediation branch has merged. If you need a compressed timeline for a launch, an incoming customer security questionnaire, or an audit date that cannot move, tell us at scoping — we can usually commit to half the standard timeline at a premium rate, as long as your team is available to answer reviewer questions inside the compressed window.

The mainstream server-side and client-side stack: Go, Rust, Python, Java, C#/.NET, TypeScript and JavaScript (Node.js, Deno, Bun, React, Vue, Svelte), Kotlin (Android plus server-side), Swift (iOS plus server-side), C and C++, and Ruby (including Rails). Each is covered with both SAST tooling and reviewers who write the language day-to-day — a reviewer tracing a Go channel deadlock should write Go, not translate from Java.

For rarer languages — Elixir, Erlang, Haskell, OCaml, Clojure, Scala, Zig, Nim — we still take the engagement but with reduced SAST coverage (more manual, fewer pre-built rules) and clearer disclosure of that in scoping. Embedded C, firmware analysis, hardware security, and side-channel work are out of scope for this service line; we refer those engagements out to specialist firms and are happy to introduce you. If your stack is polyglot, that is normal — we staff across languages for the same engagement.

Third-party dependencies are SCA territory — software composition analysis — and they get a dedicated stream inside every engagement. We inventory every direct and transitive dependency, check each against the NVD, GitHub Advisory Database, and vendor-specific sources (OSS-Fuzz advisories, language-specific registries), flag license risks (GPL reach-through, AGPL in a commercial product, unclear or unattributed licenses), and deliver a remediation roadmap prioritized by exploitability, not just CVE presence.

Tooling for the scanning layer: Snyk, Dependabot, Mend (formerly WhiteSource), and GitHub Advanced Security. Deliverable for the audit artifact: an SBOM in CycloneDX or SPDX. The underexamined part of SCA is the supply chain itself — typosquatted packages, compromised maintainers, malicious updates to otherwise-trusted packages — which we flag separately with different tooling and manual review. For high-assurance engagements we verify package signatures, lock transitive versions, and recommend an internal package mirror when the dependency tree is large enough to warrant it.

We don't issue certifications — no code-review firm does, and any firm that claims otherwise is misrepresenting how those audits work. What we do is deliver the evidence and the attestation letters your auditor expects.

PCI-DSS Requirement 6.2 requires development staff to be trained in secure coding; Requirement 6.3 requires secure software-development practices; Requirement 11.3 requires annual testing including code review for applications in the CDE. Our engagement report documents the cadence, the training, and the remediation process — usable directly by your QSA. SOC 2 CC7.1 and CC8.1 cover change management and threat identification; our engagement report, integrated into your evidence package, satisfies both. SOX ITGC on application development requires segregation of duties, change documentation, and control over privileged access to production; our report speaks to the portion of that control set related to code quality and security review.

In every case, we coordinate directly with your auditor — Big Four, Schellman, A-LIGN, or your regional firm — at the start of the engagement to confirm the format, the scope, and the evidence they need. If a custom template is required, send it at scoping and we will match it before delivery.