GitLab CI Security Scanning — Dependency Vulnerability Detection Setup

A GitLab pipeline can build, test, and deploy successfully while still shipping a vulnerable package. Passing CI does not always mean the release is safe. It only means the checks you configured passed.

That is why GitLab CI security scanning matters. Dependency scanning, secret detection, and package audits help teams catch vulnerable open source components before they reach production. GitLab Ultimate includes built-in security features, but Free and Premium users can still build strong pipelines with open source tools.

GitLab’s Built-In Security Features — What’s Available on Which Tier

GitLab security scanning includes several features across application security and pipeline security. The availability depends on your GitLab tier and deployment model. GitLab Ultimate users get the strongest built-in experience, including integrated dependency scanning results, vulnerability reports, merge request widgets, and security dashboards.

Free and Premium users can still run security tools inside GitLab CI. The difference is usually where the results appear and how deeply GitLab integrates them into the UI. Open source scanners can publish artifacts, fail pipelines, and generate reports, but some GitLab-native security dashboards and widgets require Ultimate.

Tip: If you are not on GitLab Ultimate, do not skip security scanning. Use Trivy, OWASP Dependency-Check, npm audit, pip-audit, composer audit, cargo audit, or gitleaks inside your pipeline.

Setting Up Built-In Dependency Scanning GitLab Ultimate

GitLab dependency scanning identifies known vulnerabilities in project dependencies, including direct, development, runtime, and transitive packages where supported. For Ultimate users, GitLab provides CI/CD templates that make setup simple.

Add the dependency scanning template to your .gitlab-ci.yml file:

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

A minimal pipeline can look like this:

stages:
  - test
  - security

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

GitLab runs the dependency scanning analyzer during the pipeline and publishes results as security data. In supported projects, results can appear in the merge request security widget, pipeline security tab, vulnerability report, security dashboard, dependency list, and dependency scanning report artifact.

The exact package coverage depends on the analyzer method and supported ecosystems. For modern dependency scanning, always scan resolved dependency files where possible, such as package-lock.json, yarn.lock, composer.lock, poetry.lock, Pipfile.lock, go.sum, Gemfile.lock, and similar lock files.

Warning: Scanning only top-level manifests can miss transitive dependency risk. Lock files and SBOMs give scanners a clearer view of what your application actually installs.

Open Source Alternatives for GitLab Free and Premium

GitLab Free and Premium users can run dependency scanners directly as CI jobs. This is often enough to fail dangerous builds, upload reports, and create a basic security workflow. You may not get the same GitLab-native dashboard experience, but you still get pipeline protection.

The best open source setup depends on your stack. Trivy is a strong general scanner for many teams. OWASP Dependency-Check is useful for broad dependency scanning and report artifacts. Package manager audits are simple and language-specific.

Trivy in GitLab CI

Trivy can scan a repository filesystem for dependency vulnerabilities. It supports many ecosystems and works well in GitLab CI because it can run inside a container image and fail pipelines based on severity.

stages:
  - security

trivy_dependency_scan:
  stage: security
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 --ignore-unfixed .
  allow_failure: false

This job scans the repository and fails the pipeline if Trivy finds high or critical vulnerabilities. For a softer rollout, set allow_failure: true first, fix the existing backlog, then make the job blocking.

You can also publish the scan output as an artifact:

trivy_report:
  stage: security
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy fs --format json --output trivy-report.json .
  artifacts:
    when: always
    paths:
      - trivy-report.json
    expire_in: 7 days

OWASP Dependency-Check

OWASP Dependency-Check detects publicly disclosed vulnerabilities in project dependencies and can generate HTML, JSON, XML, or other reports depending on configuration. It is useful when you want a portable report artifact from GitLab CI.

stages:
  - security

dependency_check:
  stage: security
  image:
    name: owasp/dependency-check:latest
    entrypoint: [""]
  script:
    - mkdir -p dependency-check-report
    - /usr/share/dependency-check/bin/dependency-check.sh
      --project "gitlab-project"
      --scan .
      --format "HTML"
      --out dependency-check-report
      --failOnCVSS 8
  artifacts:
    when: always
    paths:
      - dependency-check-report
    expire_in: 7 days
  allow_failure: false

The --failOnCVSS 8 flag makes the pipeline fail when findings meet or exceed that threshold. Teams with a large backlog may start at 9 or 10, then lower the threshold after cleanup.

Language-Specific Package Manager Audits

Package manager audits are quick to add and easy for developers to understand. They are not a full replacement for multi-ecosystem SCA, but they provide useful coverage for specific stacks.

For Node.js projects:

npm_audit:
  stage: security
  image: node:20
  script:
    - npm ci
    - npm audit --audit-level=critical
  rules:
    - exists:
        - package-lock.json

For Python projects:

pip_audit:
  stage: security
  image: python:3.12
  script:
    - pip install pip-audit
    - pip-audit -r requirements.txt
  rules:
    - exists:
        - requirements.txt

For PHP Composer projects:

composer_audit:
  stage: security
  image: composer:latest
  script:
    - composer install --no-interaction --no-progress
    - composer audit
  rules:
    - exists:
        - composer.lock

For Rust projects:

cargo_audit:
  stage: security
  image: rust:latest
  script:
    - cargo install cargo-audit
    - cargo audit
  rules:
    - exists:
        - Cargo.lock

These jobs can run together in one security stage. Use rules: exists so jobs only run when the relevant files exist.

Secrets Detection in GitLab CI

Secret detection finds credentials committed to the repository. This includes API keys, cloud tokens, private keys, database passwords, OAuth secrets, webhooks, and other sensitive values. A leaked secret can create immediate risk even if the code itself is secure.

GitLab provides a secret detection template. In projects where the feature is available, you can include it like this:

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

For teams using Free or Premium without the built-in workflow they need, gitleaks is a practical alternative:

gitleaks:
  stage: security
  image:
    name: zricethezav/gitleaks:latest
    entrypoint: [""]
  script:
    - gitleaks detect --source . --report-format json --report-path gitleaks-report.json
  artifacts:
    when: always
    paths:
      - gitleaks-report.json
    expire_in: 7 days
  allow_failure: false

If secret scanning finds a real credential, rotate it immediately. Removing the string from the latest commit is not enough because the secret may still exist in Git history, CI logs, forks, or copied environments.

Scheduling Nightly Security Scans

Pull request scans only run when code changes. A dependency can become vulnerable tomorrow even if your repository does not change. That is why scheduled scans are important for GitLab CI security scanning.

GitLab supports pipeline schedules through the UI. Go to Build > Pipeline schedules, create a schedule, choose the target branch, and set the cron timing. A nightly dependency scan is a good default for production applications.

You can keep the CI file simple and let the GitLab schedule trigger the same jobs:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "schedule"

For scheduled-only security jobs, add rules like this:

nightly_trivy_scan:
  stage: security
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

Security Results in Merge Request Widgets

Merge request security widgets help developers see security findings before merge. In GitLab Ultimate, supported security scanners can publish report artifacts that GitLab displays in merge requests, the pipeline security tab, the security dashboard, the project vulnerability report, and the dependency list.

For GitLab-native dependency scanning reports, the artifact type is dependency_scanning. This report format is meant for GitLab security ingestion, not just a downloadable file.

artifacts:
  reports:
    dependency_scanning: gl-dependency-scanning-report.json
  paths:
    - gl-dependency-scanning-report.json
  when: always

For Free and Premium workflows, you can still upload HTML, JSON, or text reports as normal artifacts. Developers can open the report from the pipeline page, even if it does not appear in the GitLab security dashboard.

The best policy is to make critical and high findings visible in merge requests, fail the pipeline only for serious issues, and create tickets for lower-risk findings. This keeps the security signal useful instead of turning every merge request into a noisy blocker.

Continuous Monitoring Beyond Pipeline Scans

CI/CD scans are valuable, but they run only when pipelines run. A new CVE can be disclosed between commits, between release cycles, or during a weekend. If your only protection is a pipeline scan, you may not know about the vulnerability until the next push or scheduled job.

Vulert complements GitLab CI by monitoring open source dependencies continuously. It analyzes manifest files and SBOMs against a database of 458,000+ known CVEs and alerts teams within hours when new CVEs affect their packages.

Vulert supports files such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SPDX/CycloneDX SBOMs.

It also provides fix guidance, exact fixed versions, exact CLI commands where available, CVSS details, Jira ticket creation, vulnerability history, and dependency health grouping. That makes GitLab vulnerability scanning more actionable because developers get the package, version, CVE, and fix path together.

Example Complete GitLab CI Security Pipeline

The following example combines dependency scanning with Trivy, npm audit for Node.js projects, gitleaks secret detection, artifacts, and schedule support.

stages:
  - test
  - security

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "schedule"

trivy_dependency_scan:
  stage: security
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy fs --format json --output trivy-report.json .
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 --ignore-unfixed .
  artifacts:
    when: always
    paths:
      - trivy-report.json
    expire_in: 7 days

npm_audit:
  stage: security
  image: node:20
  script:
    - npm ci
    - npm audit --audit-level=critical
  rules:
    - exists:
        - package-lock.json

gitleaks:
  stage: security
  image:
    name: zricethezav/gitleaks:latest
    entrypoint: [""]
  script:
    - gitleaks detect --source . --report-format json --report-path gitleaks-report.json
  artifacts:
    when: always
    paths:
      - gitleaks-report.json
    expire_in: 7 days
  allow_failure: false

This is a practical starting point. Add Python, Composer, Maven, Go, Rust, or .NET jobs depending on your repository. Keep the security stage small at first, then expand coverage after the team fixes existing issues.

Key Takeaways

• GitLab Ultimate includes built-in dependency scanning and deeper security dashboard integration.
• GitLab Free and Premium users can still run strong open source security scans inside GitLab CI.
• Trivy is a practical general-purpose option for dependency vulnerability scanning in GitLab pipelines.
• Language-specific tools such as npm audit, pip-audit, composer audit, and cargo audit provide quick ecosystem coverage.
• Secret detection should block pipelines when real credentials are found, followed by immediate secret rotation.
• GitLab CI security scanning works best when CI checks are paired with continuous monitoring between pipeline runs.

Frequently Asked Questions

1. Is GitLab dependency scanning free?

GitLab’s built-in dependency scanning is listed as an Ultimate feature. Free and Premium users can still run open source tools such as Trivy, OWASP Dependency-Check, npm audit, pip-audit, composer audit, cargo audit, and gitleaks inside GitLab CI.

2. What’s the best free security scanning option for GitLab?

Trivy is a strong starting point for many teams because it is simple to run in CI and supports multiple ecosystems. For best results, combine it with package-manager audits and secret scanning.

3. Can Vulert integrate with GitLab?

Vulert can support GitLab-based teams by monitoring the same manifest files and SBOMs used in GitLab repositories. CI scans run during pipelines, while Vulert monitors continuously and alerts when new CVEs affect your dependencies.