Fix GitLab CI Dependency Scanning Failures (2026)

Dependency Scanning failed because the GitLab Runner could not reach the GitLab instance to download dependencies or upload results.

Common Causes and Fixes

1. Network Connectivity Issues:

Diagnosis: From the GitLab Runner’s host, try to curl the GitLab instance’s domain.
```
curl -v https://your.gitlab.instance.com
```
Look for connection refused, timeout, or certificate errors.
Fix: Ensure the Runner host has a direct network path to the GitLab instance. If using a firewall, open outbound TCP ports 443 (for HTTPS) to your GitLab instance’s IP address(es).
Why it works: This directly addresses the most fundamental requirement: the Runner needs to talk to GitLab over the network.

2. Incorrect Runner Registration or Configuration:

Diagnosis: Check the runner’s config.toml file (typically at /etc/gitlab-runner/config.toml or ~/.gitlab-runner/config.toml). Verify the url parameter points to the correct GitLab instance.

concurrent = 1
check_interval = 0
[session_server]
  session_timeout = 1800
[[runners]]
  name = "my-runner"
  url = "https://your.gitlab.instance.com/"
  token = "xxxxxxxxxxxxxxxxxxxx"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "docker:stable"
    privileged = true
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

Fix: Update the url parameter in config.toml to the correct GitLab instance URL and restart the GitLab Runner service:
```
sudo systemctl restart gitlab-runner
```
Why it works: The runner uses this URL to communicate with the GitLab API for job assignments and result uploads. An incorrect URL means it’s trying to connect to the wrong place.

3. SSL Certificate Verification Failures:

Diagnosis: If your GitLab instance uses a self-signed or internally-signed SSL certificate, the Runner might not trust it by default. Check the runner logs for errors like x509: certificate signed by unknown authority.
Fix:
- Option A (Recommended for internal networks): Add the CA certificate that signed your GitLab instance’s certificate to the Runner’s trust store. On Linux, this usually involves placing the .crt file in /etc/gitlab-runner/certs/ and ensuring the runner user can read it, or adding it to the system’s trust store (update-ca-certificates on Debian/Ubuntu).
- Option B (Less secure, for testing/internal): In config.toml, set tls_verify = false under the [[runners]] section. This is not recommended for production environments.
```
[[runners]]
  # ... other settings
  tls_verify = false
```
Restart the runner after making changes.
Why it works: SSL/TLS ensures secure communication. If the runner can’t verify the identity of the GitLab server through its certificate, it will refuse to connect to prevent man-in-the-middle attacks.

4. DNS Resolution Problems:

Diagnosis: From the Runner’s host, try to ping or nslookup your GitLab instance’s domain name.
```
ping your.gitlab.instance.com
nslookup your.gitlab.instance.com
```
If these fail or resolve to an incorrect IP address, DNS is the issue.
Fix: Ensure the Runner host’s DNS servers are correctly configured and can resolve the GitLab instance’s domain name. This might involve updating /etc/resolv.conf on Linux or checking network adapter settings.
Why it works: DNS translates human-readable domain names into machine-readable IP addresses. Without correct DNS resolution, the Runner won’t know where to send its network requests.

5. Proxy Server Interference:

Diagnosis: If the Runner host is behind an HTTP/HTTPS proxy, check if the proxy is blocking or misinterpreting the traffic to your GitLab instance. Examine proxy logs for blocked requests.
Fix: Configure the Runner to use the proxy. This is typically done by setting HTTP_PROXY and HTTPS_PROXY environment variables for the GitLab Runner service. For systemd, you might edit the service file (/etc/systemd/system/gitlab-runner.service.d/http-proxy.conf):
```
[Service]
Environment="HTTP_PROXY=http://your.proxy.server:8080"
Environment="HTTPS_PROXY=http://your.proxy.server:8080"
```
Then reload systemd and restart the runner:
```
sudo systemctl daemon-reload
sudo systemctl restart gitlab-runner
```
Why it works: Proxies act as intermediaries. If they aren’t configured to allow traffic to your GitLab instance, or if they interfere with SSL inspection, connections will fail.

6. Runner Not Tagged Correctly for the Job:

Diagnosis: In your .gitlab-ci.yml file, check the tags for the dependency scanning job. Ensure these tags match the tags configured for your active GitLab Runner in config.toml.

dependency_scanning:
  stage: test
  image: registry.gitlab.com/security-products/dependency-scanning:latest
  script: []
  artifacts:
    reports:
      dependency_scanning: gl-dependency-scanning-report.json
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUEST
  tags:
    - your-runner-tag # <-- Check this tag

In config.toml:

[[runners]]
  name = "my-runner"
  url = "https://your.gitlab.instance.com/"
  token = "xxxxxxxxxxxxxxxxxxxx"
  executor = "docker"
  tags = ["your-runner-tag", "docker"] # <-- Ensure tag is present

Fix: Add the required tag to the runner’s configuration in config.toml or change the job’s tag in .gitlab-ci.yml to match an existing runner tag. Restart the runner.
Why it works: Tags are used to select specific runners for specific jobs. If a job has a tag that no active runner possesses, the job will remain pending, and the runner won’t even attempt to download the job, let alone the dependency scanning image or artifacts.

After fixing these, you’ll likely encounter a "Job exceeded time limit" error if the dependency scanning job itself is configured with a time limit that’s too short for the analysis to complete.