Integrating Managed Service for GitLab with SourceCraft Security

Integrating with SourceCraft Security enables you to verify code security from a Managed Service for GitLab instance. Instance repositories are automatically mirrored to SourceCraft, which runs checks on them and displays the results.

Managed Service for GitLab instances support the full range of SourceCraft Security features:

• Secret scanning: Searching the commit history for API keys, tokens, passwords, and other sensitive data.
• Software composition analysis (SCA): Detecting known vulnerabilities in third-party components and verifying their licenses.
• Static application security testing (SAST): Scanning code for vulnerabilities, errors, and security standard violations without running it.
• AI-powered vulnerability analysis and prioritization: Assessing risks and providing recommendations for fixing identified issues.
• Scan history and security dashboard: Viewing scan runs and results for individual repositories and the entire organization.

How the integration worksHow the integration works

After you enable the integration, SourceCraft Security creates private copies of the instance repositories in SourceCraft and keeps their code synchronized. New instance repositories are also synchronized with SourceCraft. Checks run in mirrored repositories in SourceCraft.

To grant developers access to mirrored repositories, invite them to the SourceCraft organization and assign roles for the relevant repositories or the organization.

Names and addresses of mirrored repositories in SourceCraftNames and addresses of mirrored repositories in SourceCraft

GitLab groups and projects differ from SourceCraft projects. When mirroring a repository, the GitLab repository path is converted into a SourceCraft repository name by concatenating the group name or username, subgroup name, and repository name with hyphens.

Address in GitLab:

https://<instance_domain>/<group_or_user>/<subgroup>/<repository>

Mirrored repository address in SourceCraft:

https://sourcecraft.dev/<organization_slug>/<group_or_user>-<subgroup>-<repository>

The subgroup is optional. If none exists, the relevant path segment is omitted. The organization slug is the organization ID in SourceCraft addresses. You can find it in the organization settings.

Here are some examples of converting GitLab instance repository addresses on the example.gitlab.yandexcloud.net domain in the organization with the my-org slug:

GitLab	https://example.gitlab.yandexcloud.net/test-group/test-subgroup/example-repo
SourceCraft	https://sourcecraft.dev/my-org/test-group-test-subgroup-example-repo

GitLab	https://example.gitlab.yandexcloud.net/example-user/my-project
SourceCraft	https://sourcecraft.dev/my-org/example-user-my-project

GitLab	https://example.gitlab.yandexcloud.net/test-group/test-project
SourceCraft	https://sourcecraft.dev/my-org/test-group-test-project

Useful linksUseful links

• Setting up Managed Service for GitLab integration with SourceCraft Security
• Security in SourceCraft