Security Scanning

Modern applications are built on hundreds of open-source dependencies. Each dependency is a potential vulnerability vector — a CVE in a logging library or a compromised package can affect thousands of applications. Dependency Scanning automatically checks your lockfiles (package-lock.json, go.sum, pom.xml, requirements.txt, etc.) against vulnerability databases and reports any dependencies with known CVEs [citation:3][citation:8].

GitLab's Dependency Scanning uses the Gemnasium analyzer, which maintains its own advisory database. The scanner supports all major package managers: npm, yarn, pnpm, Maven, Gradle, pip, Poetry, Go modules, Composer, and more. For each vulnerable dependency, it reports the CVE ID, severity, affected versions, and the fixed version, making remediation straightforward. Results appear in merge requests, showing newly introduced vulnerabilities alongside existing ones [citation:18].

The scanner is enabled with a single include. You can exclude paths (like test directories) and specific analyzers using variables. For projects with many dependencies, the scan runs quickly because it analyzes lockfiles rather than downloading packages. This makes it practical to run on every commit and merge request, catching vulnerable dependencies before they're merged [citation:8].

Accidentally committed secrets are one of the most common and dangerous security incidents. An API key pushed to a public repository can be exploited within minutes. Even in private repositories, secrets in git history persist forever unless the history is rewritten. Secret Detection scans your commits for patterns that match API keys, tokens, passwords, private keys, and other sensitive values, reporting them as vulnerabilities before they can be exploited [citation:4].

By default, Secret Detection scans the current state of the repository and new commits. This catches secrets as they're introduced. But secrets already in your history — from months or years ago — won't be found unless you run a historic scan. Setting SECRET_DETECTION_HISTORIC_SCAN: "true" scans every branch and commit in the repository, uncovering secrets that were deleted but remain in git history [citation:4]. This is essential for the first scan on an existing repository.

GitLab also offers push protection, which blocks commits containing secrets before they reach the remote. This is a client-side or server-side check that prevents the leak entirely rather than detecting it after the fact. For organizations serious about secret hygiene, combining push protection with pipeline scanning provides defense in depth [citation:4].

Container images bundle your application with its OS libraries, language runtime, and system packages. Every one of those layers can contain known vulnerabilities. Container Scanning inspects the image's OS packages (Alpine apk, Debian dpkg, RHEL rpm) and reports CVEs, severity, and fixed versions. GitLab uses Trivy as the default scanner, which is fast and has a comprehensive vulnerability database [citation:15][citation:20].

The scanner runs after your image is built and pushed to the registry. This ensures you're scanning exactly what will be deployed, not a local build that might differ. You configure it by setting CS_IMAGE to the image reference, and optionally CS_SEVERITY_THRESHOLD to filter findings. By default, the threshold is set to medium starting in GitLab 18.0, meaning low and unknown severity findings are not reported [citation:10].

Container scanning results appear in merge requests, showing newly introduced vulnerabilities compared to the base branch. This is particularly useful for base image updates: when you bump node:18-alpine to a newer patch, the scan shows exactly what changed. For production pipelines, you can set allow_failure: false to block deployment if critical vulnerabilities exist [citation:20].

Here's a complete pipeline that integrates all five scanners with appropriate stages and dependencies.