Cracken + GitLab

Connecting GitLab

Connect with

A GitLab personal, project or group access token with the read_api scope, the instance Base URL (https://gitlab.com or your self-managed URL), and the Verify SSL setting. The token inherits its owner's project membership, so it needs at least the role that can view the target projects and their vulnerability reports.

Cadence

Queried live during an operation — a direct connector, not a scheduled sync.

Requires

GitLab Ultimate and a completed security scan in each project whose vulnerabilities Cracken should read; membership in every project or group to be read. For a self-managed instance with a private CA, install the CA in the Cracken deployment's trust store rather than disabling Verify SSL.

What Cracken gets from GitLab

• 01

  Projects with path_with_namespace, visibility, description, default_branch, open_issues_count, updated_at and web_url

• 02

  Issues with iid, title, state, labels[], author username and created_at

• 03

  Merge requests with iid, title, state, source_branch, target_branch, author username, created_at and merged_at

• 04

  Vulnerability findings with uuid, name, severity, state, report_type, the scanner name that produced them, identifiers[] and a location object

• 05

  In the Cybergraph: a URL node per project, a Finding node per issue / merge request / vulnerability, and a cve: Vulnerability node for every identifier starting with CVE-

What GitLab does not do

Vulnerability findings require GitLab Ultimate and a security scan that has already run; on any other project nothing comes back and Cracken tells you why. The connection is read-only, so Cracken never opens an issue, comments on a merge request, or changes a vulnerability's state in GitLab.

How Cracken uses GitLab

1. 01

   Connect GitLab with a read_api token

2. 02

   Let Cracken query projects mid-operation

3. 03

   Attack what the findings point at

4. 04

   Confirm it connected