Catch risky MRs in the GitLab thread.

Why security review belongs in the merge request

Security issues are cheapest to fix at the point of introduction. A vulnerability caught in a merge request costs a developer ten minutes to fix. The same issue found in a quarterly pentest or, worse, a production incident, costs orders of magnitude more — in remediation time, in risk exposure, and in the audit evidence you now have to reconstruct retroactively.

Most teams already have code review in the merge request. Adding security review to the same workflow — same thread, same tooling, same feedback loop — keeps the fix context-fresh and removes the friction of context-switching to a separate security dashboard.

How the GitLab integration works

Connect

Navigate to the Integrations page in your CodeGuards.io workspace and paste a GitLab personal access token with api scope. Specify the GitLab host — gitlab.com or your self-hosted instance URL. No OAuth dance, no admin-level permissions, no full clone of your codebase.

Select repositories

Choose which projects you want reviewed. CodeGuards.io registers a webhook on each selected project. The webhook fires on push and merge_request events. You can add or remove repositories at any time without reconfiguring the token.

Scan

When a developer pushes a commit or opens a merge request, the webhook delivers the event to CodeGuards.io. The platform retrieves the diff from your GitLab instance and runs the security review. The median time from push to findings posted is around 9 seconds.

Read findings in the MR

CodeGuards.io posts a structured review comment on the merge request thread. The comment lists all findings grouped by severity, with each finding showing the affected file and line, a plain-English explanation of the risk, and a ready-to-apply fix. The same findings are available in the CodeGuards.io dashboard and in scan reports.

Example MR review comment

▸ CodeGuards.io review — MR !214 · feature/api-v2
# 3 files changed · 91 lines · 2 findings

CRITICAL  Broken Access Control — missing ownership check
  File: app/Http/Controllers/Api/DocumentController.php:41
  - $doc = Document::find($request->doc_id);
  + $doc = Document::where('user_id', auth()->id())->findOrFail($request->doc_id);
  CWE-639 · OWASP A01:2021

HIGH      Sensitive field written to application log
  File: app/Services/ApiKeyService.php:88
  - Log::debug('key created', ['key' => $rawKey]);
  + Log::debug('key created', ['key_id' => $keyRecord->id]);
  CWE-532 · OWASP A09:2021

GitLab.com and self-hosted — both first-class

CodeGuards.io was built to work with self-hosted GitLab from the start, not as an afterthought. The integration pattern is identical: paste a token, specify the host, select projects. Whether you are on gitlab.com or running a private instance behind a VPN, the workflow is the same.

Supported versions: GitLab 14.0 and above. Both GitLab Community Edition (CE) and Enterprise Edition (EE) are supported. No GitLab Runner is required — CodeGuards.io is purely webhook-driven.

For self-hosted instances, CodeGuards.io needs outbound network access to your GitLab API endpoint to retrieve diffs. Your GitLab instance does not need to be publicly reachable — you configure a token that CodeGuards.io uses to pull the diff on demand.

Optional: GitLab CI integration

The webhook integration handles everything automatically. If you also want CodeGuards.io to block a CI pipeline on critical findings, you can add a one-step job to your .gitlab-ci.yml:

codeguards-review:
  stage: security
  variables:
    GIT_DEPTH: "0"
    CODEGUARDS_API_URL: "$CG_URL/ci/reviews"
    CODEGUARDS_PRODUCTS: "review,security"
  script:
    - vendor/bin/codeguards-review
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
# The webhook already posts findings on push.
# Add this job only when you need CI to fail on critical findings.

The CI call returns a non-zero exit code when critical findings are present, failing the pipeline stage. Info and medium findings do not block CI by default; this threshold is configurable per project.

Handling false positives and project-specific patterns

Not every finding will be an issue that requires immediate action. For patterns that are intentional in your codebase — internal conventions, known trade-offs, or issues covered by a compensating control — CodeGuards.io lets you mark a finding as accepted with a short policy note directly from the scan report.

The acceptance decision is scoped to that repo. The same pattern in any other project continues to be reported. Accepted findings are visible in the audit trail with author, timestamp, and rationale — which is useful evidence for reviewers asking why a specific finding was not remediated.

Audit trail for SOC 2 and compliance

Every scan CodeGuards.io performs on a GitLab merge request produces a timestamped, immutable record: the project, the commit SHA, the review verdict, every finding, and any acceptance decisions. This record is available for export from the dashboard and maps directly to:

• SOC 2 CC7.1 (Change management controls) and CC8.1 (Change request process)
• ISO 27001 A.14.2 (Security in development and support processes)
• PCI-DSS 6.3 (Security of development processes)

Teams preparing for a first audit typically find that six months of CodeGuards.io scan history gives them exactly the change-review evidence their auditor is looking for — without any retroactive documentation effort.

Frequently asked questions

What GitLab token permissions does CodeGuards.io need?

Managed GitLab setup uses an administrator token with api and admin_mode so CodeGuards can create its bot account and register webhooks. If you cannot store a GitLab token in CodeGuards, use the CI runner mode instead: the GitLab token stays inside your pipeline or relay.

Does CodeGuards.io work with GitLab group webhooks or project webhooks?

CodeGuards.io registers per-project webhooks when you select repositories during setup. Group-level webhooks are not currently used, but all projects in a group can be connected individually.

What events trigger a review?

Reviews are triggered by push events (any branch) and merge_request events (open, update, reopen). You can also trigger a scan manually from the dashboard or via the CI API endpoint without waiting for a webhook event.

Will CodeGuards.io review draft merge requests?

Yes. Draft MRs receive the same review as regular MRs. If you prefer to exclude drafts, you can configure that per project in the review settings.

Does CodeGuards.io work with GitLab merge request approvals?

CodeGuards.io posts findings as a review comment but does not integrate with GitLab's native approval workflow. Some teams add a policy requiring that any CodeGuards.io Critical findings be addressed before an MR can be merged, enforced through protected branch rules and pipeline status.