GitLab Ultimate: vulnerability report and policies

Everything on this page needs GitLab Ultimate. It was tried out on gitlab.com on 2026-10-27, in a public test project with a pipeline file full of deliberate findings. The screenshots show GitLab Ultimate, cropped to the part that matters. GitLab only shows the vulnerability report and the security widget to project members, so the screenshots have no link. glsec is an independent project, not affiliated with or endorsed by GitLab.

Findings in the vulnerability report

With --format gitlab-sast, glsec writes a SAST report in GitLab's security report schema. A job uploads it as artifacts:reports:sast (the job and an example report), and every glsec finding on the default branch becomes a vulnerability that can be triaged: confirmed, dismissed or linked to an issue. Error findings are High, warnings Medium, info Low.

GitLab vulnerability report of the test project: 9 development vulnerabilities, 2 High and 7 Medium. The list shows GL001 Mutable image tag and GL011 Download-and-execute pattern in script as High, GL028 artifacts untracked without path restriction and GL080 Sensitive job with no pipeline-source guard as Medium, each with its line in bad/.gitlab-ci.yml, report type SAST, scanner Glsec — The vulnerability report of the test project's default branch. The screenshot is from before glsec 1.25.0, which also lists the CWE as an identifier.

GitLab vulnerability page for GL011: Download-and-execute pattern in script (curl | bash). Remediation: See https://glsec.github.io/rules/GL011/. Report type SAST, scanner glsec, file bad/.gitlab-ci.yml line 5 with the source line curl -fsSL https://example.com/install.sh | sh, the finding's message with the job name, and the identifiers GL011 and CICD-SEC-3. Status Needs triage, severity High — One vulnerability: the source line, glsec's message, and the link to the rule page as remediation.

In the merge request

The merge request's security widget lists the findings the merge request adds, compared with the target branch.

GitLab merge request widget: Security scanning detected 3 new potential vulnerabilities, 0 critical, 1 high, and 2 others, with a View report button — The security widget of a merge request that adds a job with three findings.

GitLab merge request Reports tab, Security scan: SAST detected 3 new potential vulnerabilities. New: High GL060 docker run mounting sensitive host paths, Medium GL054 Docker-in-Docker service implies a privileged runner, Medium GL056 docker run --privileged in CI script — The same merge request's Reports tab, with the three new findings.

One limitation: GitLab matches a finding from one pipeline to the next by file and line. A merge request that adds or removes lines above an unchanged finding shows it as fixed and as new at the same time. A tracking signature in the report didn't change that in the test, so glsec's report has none.

Making glsec mandatory: a pipeline execution policy

A pipeline execution policy runs glsec in every pipeline of the projects it applies to, and the projects can neither remove it nor configure it away. Two files in the security policy project:

.gitlab/security-policies/policy.yml

pipeline_execution_policy:
  - name: glsec
    description: Lint .gitlab-ci.yml with glsec in every pipeline.
    enabled: true
    pipeline_config_strategy: inject_policy
    content:
      include:
        - project: my-group/security-policies   # this policy project
          file: glsec-policy.yml
          ref: main

glsec-policy.yml

include:
  - component: gitlab.com/glsec-io/glsec/glsec@v1.0.27
    inputs:
      version: "1.25.0"
      stage: .pipeline-policy-pre
      no_repo_config: true
      no_ignores: true
      strict: true   # optional: warnings fail the job too

# The policy configuration is evaluated on its own, without the project's
# workflow:rules. A job without rules: then runs only in branch and tag
# pipelines, so without this the merge request pipelines get no scan.
glsec:
  rules:
    - when: always

What it did in the test:

The job runs in the reserved stage .pipeline-policy-pre, before every project job. When it fails, the project's jobs are skipped.
A merge request that adds a .glsec.yml or a # glsec:ignore comment changes nothing: no_repo_config and no_ignores make glsec ignore both, and the job log says note: .glsec.yml is ignored (--no-repo-config).
The component reference needs the v of the tag (@v1.0.27). A reference GitLab can't resolve fails every pipeline of every project the policy applies to.
If a project has its own job named glsec, GitLab renames the policy job to glsec:policy-<id>-0, and both run.
The policy also runs in branch pipelines that the project's workflow:rules don't create, so a push to a merge request branch gets a branch pipeline with only the policy job, next to the merge request pipeline.

To upgrade, bump the component and version in the policy project; the projects don't change. The component README keeps the same example.

Scan execution policies and GL082

GL082 reports variables such as SAST_DISABLED that switch off GitLab's security scans. With a scan execution policy they don't: in the test, a policy running scan: sast on every branch still created its semgrep-sast-0 job after a commit that set SAST_DISABLED: "true", where the template include created no SAST job at all. So a scan execution policy is the way to make a scan mandatory, and GL082 still matters for projects and scans the policy doesn't cover. More in GL082.

Tiers as listed in GitLab's documentation for the vulnerability report, pipeline execution policies and scan execution policies. GitLab is a trademark of GitLab Inc.