Turn GitLab security findings into secure-coding training

Overview

Security scanners find the vulnerability. They do not teach the developer how to avoid the next one. This component closes that gap inside GitLab: when a scanner flags a finding on a merge request, the developer who introduced it gets a short lesson on the exact class of bug, on the merge request, while the code is still fresh.

It is a GitLab CI/CD Catalog component, so adoption is one include line and three variables:

• Reads your SAST, Secret, Dependency, and Container reports
• Matches each finding to a secure-coding module
• Posts the lesson on the merge request
• Stateless, in your own GitLab boundary

How it works

The component is a job in your merge request pipeline that runs after your security scanners. It never talks to your source; it reads the reports the scanners already produce and acts on them.

1. Your GitLab scanners run and write their gl-*-report.json artifacts. The component reads them and iterates the findings.

2. For each finding it takes the CWE and OWASP identifiers and matches them to the secure-coding module that teaches the fix. A SQL injection maps to injection, a hard-coded secret to secrets handling, a vulnerable dependency to dependency hygiene.

3. It works out the responsible developer from the commit author and posts the module link as a single note on the merge request, deduplicated so a re-run never spams it.

4. When the developer finishes the module, the completion is recorded back on the merge request as a signed note, so the review shows the lesson was assigned and done.

Add it to your pipeline

The component is published in the GitLab CI/CD Catalog. Add it to your .gitlab-ci.yml after the jobs that produce your security reports:

Then set three masked CI/CD variables from your RansomLeak install:

Permissions and data handling

The integration is stateless and runs inside your own GitLab boundary. It reads the scanner reports the pipeline already produced, and it talks to GitLab with a token you own and can revoke.

• Runs in your GitLab, with your token
• No per-developer rows, no completion storage
• Revoke the token and it stops, cleanly

Frequently asked questions

Does RansomLeak integrate with GitLab?

Yes. RansomLeak publishes a GitLab CI/CD Catalog component that turns a security finding into secure-coding training for the developer who introduced it. It runs after your security scanners in a merge request pipeline, reads their reports, and posts a short, matched lesson on the merge request. Completion is recorded back on the same merge request.

How does a GitLab finding become training?

The component runs in the merge request pipeline, after your scanners produce their gl-*-report.json artifacts. For each finding it reads the CWE and OWASP identifiers, matches them to a secure-coding micro-module, works out the responsible developer from the commit author, and posts the module link as a note on the merge request. Finishing the module records completion back on the merge request.

Which scanners does it read?

GitLab SAST, Secret Detection, Dependency Scanning, and Container Scanning. Each finding is matched by its CWE and OWASP identifiers, so a SQL injection, a hard-coded secret, or a vulnerable dependency each map to the lesson that teaches the fix.

What developer data does RansomLeak store?

None. The component runs inside your own GitLab, calling your GitLab with a token you control. The org-level install holds only a signing key, the enabled-module list, and your API token. There are no per-developer rows and no completion storage on our side. The completion is a signed note on your merge request; GitLab holds it, and we do not.

How do I add it?

Add one include line to your .gitlab-ci.yml from the CI/CD Catalog, set three masked CI/CD variables from your RansomLeak install, and it runs on the next merge request. There is no agent to deploy and nothing to host.

Does it block the merge?

By default it posts the training on the merge request as a prompt, not a blocking gate, so it fits your existing review flow without stopping it. Completion is recorded back on the merge request, so a reviewer can see the lesson was assigned and finished.