CodeGuards v1
security review layer · gitlab-native

Every code change gets a security review before it becomes a problem.

CodeGuards reviews every diff, surfaces real risks, and sends the result back to GitLab and your dashboard. Your team keeps moving, with more confidence in what ships.

Get started See the workflow
// GitLab cloud or self-hosted · fast setup, clean workflow
// security review on every change · helpful when SOC 2 (or similar) comes up
~9s
// typical first feedback
24/7
// review coverage, always on
$0
// vendor lock-in (cancel anytime)
EU
// data stays in european region
// product

Three pieces. No extra process to carry.

CodeGuards stays deliberately simple. Connect a repository, let reviews run on each change, and read the verdict where your team already works.

// 01 { }

Review that fits the repository

Each repository can keep its own review setup, severity preferences, and scan behavior so the output stays relevant.

// 02 ⤿

Diff-only review

CodeGuards stays focused on the change being shipped, so teams can review risk without reopening months of old noise.

// 03 ⛨

Verdicts where work already happens

Findings show up on the merge request, in the dashboard, and in reports leadership can actually read.

// workflow

From repository to report in four steps.

No heavy rollout. No extra ceremony. The workflow fits around GitLab and your existing delivery process.

  1. 01

    Connect GitLab with a token

    Drop a personal access token in. Cloud, self-hosted, dedicated — same form. We register a webhook so MRs are picked up automatically.

  2. 02

    Set the review rules for each repo

    Each repository can keep its own review settings. Adjust severity, mute noise, and keep the output useful for that codebase.

  3. 03

    Code as usual

    Push a commit, open an MR, hit "Scan now" from the UI, or call the CI endpoint from any pipeline. CodeGuards reads only the diff.

  4. 04

    Read the report

    Findings land back on the MR thread and in the dashboard. Severity is grouped, file paths are linked, and teams can keep the signal clean over time.

// vs the usual setup

Traditional scanners create noise. CodeGuards stays focused.

Whole-codebase tools have their place, but they often overload day-to-day delivery. CodeGuards keeps the review centered on the change in front of your team.

// classic SAST / OSS scanners

Whole-tree, fixed rules
  • Scan the entire codebase, every time
  • Often requires extra tuning before teams trust the output
  • Generic CWE labels, vague remediation
  • Results often live far away from the merge request

// codeguards

Change-focused, workflow-friendly
  • Reads only the changed lines — fast and cheap
  • Focused on the actual change being shipped
  • Findings include clear context and a practical next step
  • Posts straight to the merge request your team is already in
// learns from your team

It gets smarter on every repo — your rules, not generic noise.

The detection model already runs on patterns from millions of real merge requests. On top of that, every repository builds its own memory: when a finding is fine for your codebase, mark it once — CodeGuards remembers the decision and silences the same pattern on that repo from then on. No more chasing the same false positive on every MR.

// 01 ✓

One click to mark a finding as accepted

From the scan report, mark a finding as "matches our internal policy" with a short note. CodeGuards records the reason for the audit trail and the rest of the team sees why it was accepted.

// 02 ⌬

The repo learns, not the entire platform

Suppressions are scoped to the repository. The same pattern in another codebase still gets reported — your tolerance for an internal placeholder doesn't lower the bar for the next service.

// 03 ↺

Past verdicts adjust, future scans stay clean

When you accept a finding, historical verdicts are recomputed and dashboards stop nagging about it. New scans of the same repo skip it automatically — and you can restore it any time if your policy changes.

// useful when audits come up

Going for SOC 2 later? You're already doing the boring part.

CodeGuards 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.

// 01 ≡

Evidence on every change

For each scan we persist who, what, when, the diff that was reviewed, the verdict, and the rationale. Exportable for the auditor's spreadsheet — no more reconstructing review history from chat threads.

// 02 ✓

A documented acceptance trail

When a finding is marked as covered by an internal policy, the note is stored against the repository with author and timestamp. That is exactly how a control owner is expected to record a compensating control.

// 03 ⌬

Already doing what reviewers ask about

Continuous code review with a written record is the kind of thing SOC 2 and similar audits like to see. With CodeGuards it's already running — not something you have to set up the week before someone asks.

// honest about it

CodeGuards 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.

// works with

Bring your own GitLab. Same workflow.

Cloud or self-hosted, the setup stays straightforward and close to the repository workflow.

GL
GitLab Cloud
gitlab.com — paste a PAT, done
SH
Self-hosted GitLab
any hostname, any version ≥ 14.0
CI
GitLab CI / pipeline
one curl, fails the job on critical findings

Start with one repo.
See the signal. Expand from there.

Start small, prove the workflow, then roll it out wider when the reports are doing their job. See pricing →

Connect a repo Talk to us
// asked often

Sensible questions.

Q. Does it work with self-hosted GitLab?

Yes. Drop in a PAT for any GitLab instance — version 14.0 and up. CodeGuards talks to your GitLab API and registers a webhook on the project.

Q. Where is the review processed?

Review data is processed securely, and the workspace keeps the findings and reports teams need to act on.

Q. How does CodeGuards stay relevant to different repositories?

Each repository keeps its own review setup and its own memory. Mark a finding as accepted on one repo and leave a short note about the internal policy it satisfies — CodeGuards silences the same pattern there from then on, while still reporting it on every other codebase.

Q. Can we mark a finding as acceptable for our codebase?

Yes. From any scan report, mark the finding as a known false positive with a short note about which internal rule covers it. The decision is scoped to that repository, historical verdicts are recomputed, and future scans skip the same pattern automatically. You can restore it any time if your policy changes.

Q. Does CodeGuards help when we go for SOC 2?

Indirectly, yes. Every scan leaves a timestamped record of what was reviewed, the verdict, and any decisions — exactly the kind of security-review evidence reviewers like to see. CodeGuards doesn't grant any certification (only an auditor can), but you don't have to build that paper trail from scratch.

Q. What about GitHub / Bitbucket?

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.