Security scans and code review using repository context, historical decisions, accepted suppressions, and architecture expectations.
Detect vulnerabilities, broken fixes, architecture regressions, and quality issues before merge.
Accumulated project knowledge per repo — suppressions, conventions, fixes and exceptions your team already decided. CodeGuards applies that history on the next diff.
Traditional tools search for signatures. CodeGuards reasons about repository context.
CodeGuards covers a pull request from two different angles. Same workspace, same audit trail, separate verdicts. Take whichever side you need or run both side-by-side.
Vulnerabilities, secrets, exploitability across files. The audit-evidence side.
verdicts: pass · warn · fail
Style, structure, missing tests, error handling. The day-to-day reviewer side.
verdicts: clean · remarks
Most tools run the same checks on every project.
CodeGuards is a repository-aware reviewer: it builds context per connected repo.
It understands your structure, layer boundaries, accepted risks, and conventions — then applies repository-specific reasoning to each diff.
Autonomous code review evaluates how a change behaves in that context — security, architecture, and quality — not generic signature matches.
No generic noise. Just relevant findings.
Security and architecture regressions show up in small diffs. Five steps to repository-aware review on every merge request. No agent install.
Reviews run on each change in repository context. Verdicts land on the merge request and in the dashboard — where your team already works.
Diff-only reviews on each change. No historical backlog when you connect a repository.
Risks, regressions and broken fixes surface before merge — with repository-specific reasoning your team can act on.
Clear findings on the merge request and in the dashboard. Integrate directly into CI/CD for merge gates.
Traditional tools run whole-tree checks.
CodeGuards is a diff-focused repository-aware reviewer on what actually changed.
Instead of flooding you with irrelevant issues, it focuses on the risk introduced in each commit.
And over time, it adapts to the codebase — learning what matters and what doesn't.
Accepted-risk notes stay scoped to that repo. You avoid generic noise without flattening the bar across every codebase.
CodeGuards detects not only vulnerabilities, but broken or incomplete fixes that look secure and still leave exploitable risk.
A patch can move validation to the wrong layer, sanitize a sink too late, or pass only on the happy path.
CodeGuards reasons through the fix and checks whether the hole is closed.
User-controlled data reaches a raw query without parameterization. Traditional rule-based tools flag the line and stop there.
Input is now escaped — but the escape function is applied after the query is constructed. The patch looks correct. The risk remains. CodeGuards catches this.
In internal broken-fix benchmarks, CodeGuards detected every tested case where a patch looked safe but left the vulnerability open.
No heavy rollout. CodeGuards reviews changes in repository context from day one — before regressions reach production.
It fits GitLab and your delivery process.
Add a token for cloud or self-hosted GitLab. We register the webhook; reviews start on the next push.
Each merge request and push builds repository context — structure, conventions, and historical decisions — before the first finding.
Security scans and code review run against your rulebook and repository memory — architecture, quality and conventions, not a generic checklist.
Findings land on the diff with severity, file and line, and plain-language rationale. Fix suggestions ship with the report.
Optional CI gate on critical findings. Teams fix or accept with a logged rationale — suppressions stay in repository memory.
Traditional tools match signatures and predefined rules.
CodeGuards applies repository-specific reasoning across a change: data flow, fix soundness, architecture boundaries, and real-world exploitability.
It does that before it flags a finding.
Taint follows user-controlled data across file and function boundaries — not just within a single file.
If input enters through a controller and reaches a sink three layers deep, CodeGuards traces the full path.
Not every vulnerability is reachable or exploitable in context.
CodeGuards evaluates authentication gates, input sanitization, and control flow to assess real-world risk — not theoretical exposure.
Broken fixes take many shapes: symptom-only patches, sanitizers after the sink, validation on the wrong layer.
CodeGuards checks whether the security fix closes the vulnerability.
CodeGuards checks layered control failures: missing input validation, absent output encoding, insufficient authorization.
It evaluates them independently and in combination — not only the pattern that triggered the rule.
Repository-aware review on every diff — not whole-tree signature matching.
Traditional tools close the alert when the original line changes. CodeGuards validates whether the vulnerability, architecture boundary, or quality regression is actually resolved.
Before shipping, CodeGuards was put through adversarial testing against purpose-built security benchmarks — not self-reported metrics or cherry-picked examples.
Benchmarks were run against purpose-built adversarial test suites covering broken fixes, incomplete patches, cross-file taint flows, and high-noise rule-matching scenarios. Results reflect controlled evaluation, not production aggregate data.
Real findings from merge requests — security, broken fixes, architecture, and quality regressions.
VerifyJwt now runs after the controller route is matched on /api/admin/*. Tokens are parsed but not enforced before handler execution.addslashes() after the query string is built. The MR resolves the SAST line match; second-order injection via stored value remains.BillingService now imports InvoiceRepository from Infrastructure while Invoice layer already depends on Billing — violates the project's bounded-context dependency rule.User::find($id)->update($request->all()) on a route that accepts unauthenticated profile updates. Role and is_admin are fillable.The reasoning model draws on real-world vulnerabilities, CVE patches, and post-mortems.
Each connected repo keeps its own memory. When a finding is acceptable for your codebase — placeholder, convention, or trade-off — mark it once with a short policy note.
CodeGuards remembers, recomputes verdicts, and skips that pattern on future reviews for this repo. No more chasing the same triage on every pull request.
From the review report, mark a finding as "matches our internal policy" with a short note. CodeGuards.io records the reason for the audit trail and the rest of the team sees why it was accepted.
Suppressions stay on that repo. The same pattern in another project still gets reported — accepting a placeholder here does not lower the bar for the next service.
When you accept a finding, historical verdicts are recomputed and dashboards stop nagging about it. New reviews of the same repo skip it automatically — and you can restore it any time if your policy changes.
CodeGuards.io isn't a certification and doesn't try to be one. But because every change is reviewed for security from day one — not the week before an audit — the kind of paper trail SOC 2 (and similar frameworks) expect just builds itself in the background.
For each review we persist who, what, when, the diff that was checked, the verdict, and the rationale. Exportable for the auditor's spreadsheet — no more reconstructing review history from chat threads.
When a finding is marked as covered by an internal policy, the note is stored with author and timestamp for that project. That is how a control owner records a compensating control.
Continuous code review with a written record is the kind of thing SOC 2 and similar audits like to see. With CodeGuards.io it's already running — not something you have to set up the week before someone asks.
CodeGuards.io isn't a SOC 2 (or ISO 27001, or PCI-DSS) certification — only an auditor can grant that. We just make the road there shorter, because the security-review evidence is already there when you start the conversation.
EU processing, TLS in transit, encryption at rest — and a written trail for every review outcome.
All review data is processed and stored in European Union infrastructure. Your code diffs never leave EU jurisdiction.
Diffs are processed in memory during the review and not persisted. Only findings, verdicts, and acceptance decisions are stored.
All traffic runs over TLS 1.3. Stored data is encrypted at rest with AES-256. Access tokens are never logged.
Every security review produces a timestamped, immutable record: who, what commit, verdict, and any acceptance decisions. Maps to SOC 2 CC7.1, ISO 27001 A.14.2, PCI-DSS 6.3.
We operate as a data processor under GDPR. A Data Processing Agreement is available on request for enterprise customers.
The personal access token only needs read access to MR diffs and write access to MR comments. No admin scope, no repo cloning.
Cloud or self-hosted, setup stays close to how you already ship MRs.
Most vulnerabilities are introduced in small changes.
Connect GitLab: every commit is reviewed in your repository context — no generic rule packs to tune.
Costs less than one missed vulnerability.
Yes. Drop in a PAT for any GitLab instance — version 14.0 and up. CodeGuards.io talks to your GitLab API and registers a webhook on the project.
Review data is processed securely in EU infrastructure. Only findings, verdicts, and acceptance decisions are stored — diffs are not retained after review.
Each connected repo keeps its own context and its own memory.
Mark a finding as accepted once, with a short note about the internal policy it satisfies — CodeGuards.io silences the same pattern there from then on. Every other codebase still gets a full check.
Yes. From any review report, mark the finding as covered by an internal policy with a short note.
The decision is scoped to that repo. Historical verdicts are recomputed; future reviews skip the same pattern automatically. Restore it any time if your policy changes.
Indirectly, yes. Every review leaves a timestamped record of what was checked, the verdict, and any acceptance decisions — exactly the kind of security-review evidence auditors ask for. CodeGuards.io doesn't grant any certification (only an auditor can), but you don't have to build that paper trail from scratch.
Not yet. We're focused on shipping a tight GitLab integration first. GitHub support is on the roadmap; subscribe to the field notes if you want to know when.