How merge request scanning works

Socket for GitLab scans a project on every push and comments on merge requests. It reads only supported manifest files and lockfiles, and it doesn't build your project.

Push scans

When you push to any branch, the app clones that commit, uploads its manifest files and lockfiles to Socket, and creates a scan on the Scans page of the Socket dashboard. Scans of the default branch keep the Alerts and Dependencies pages up to date.

Merge request comments

When a merge request is opened or updated, the app compares the source branch with the target branch and posts up to two comments, under the name of the GitLab token it uses. Each comment has its own setting:

The settings apply to every project in the group. To turn a comment off for one project, use the gitlabApp keys in socket.yml for GitLab. To stop merge request scans in one project, set gitlabApp.enabled: false. Pushes to that project still create scans.

The Socket Security commit status

When you turn on merge checks, the app also posts a Socket Security commit status on each merge request. The status fails when the change brings in an alert set to Block. See Require the Socket check before merging.

In the Socket dashboard

Each GitLab project gets a Socket repository named after the project. Projects in a subgroup land in a Socket workspace named after the subgroup. Merge request scans carry their merge request number.

Scan the full dependency tree

Commit lockfiles such as package-lock.json, yarn.lock, and pnpm-lock.yaml. With a lockfile in the repository, the scan covers the full dependency tree. Without one, it covers only direct dependencies.

Related topics

• What to do when you receive an alert
• socket.yml for GitLab