Skip to content

False positive "Password in URL" when password is a template variable

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Secret scanner incorrectly identifies a template {{ variable }} in a URL as password leak.

Steps to reproduce

Use a template variable as password and scan with GitLab secret detection.

In our case the false positives were triggered by Salt templates that included lines akin to this:

- source: https://{{ art_user }}:{{ art_pw }}@{{ api_link }}{{ rancher_ver }}/rancher-{{ rancher_ver }}.tgz

Example Project

I don't have a public project for this (this happens on our company's GitLab Ultimate version), but there are other similar issues:

What is the current bug behavior?

False positive if URL password is a template variable.

What is the expected correct behavior?

Ignore URL passwords if password is a template variable.

Relevant logs and/or screenshots

From the JSON report (removed company details).

{
  "version": "15.1.4",
  "vulnerabilities": [
    {
      "id": "ce0e5b14e22410c1fdfb2181c328cd48d2b0c9368bd69f847b1c8f01ffbd965c",
      "category": "secret_detection",
      "name": "Password in URL",
      "description": "Password in URL",
      "cve": "srv/salt/additional-prometheus.sls:c6031562506df6cb2147add62504dbdb7a5edfc16547b815d743581e5b9aa3a1:Password in URL",
      "severity": "Critical",
      "confidence": "Unknown",
      "raw_source_code_extract": "https://{{art_user }}:{{ art_pw }}@artifactory.devops.company.de/artifactory/access40-generic/access40/hub/vendors/ecp-suse/blackbox/{{",
      "scanner": {
        "id": "gitleaks",
        "name": "Gitleaks"
      },
      "location": {
        "file": "srv/salt/additional-prometheus.sls",
        "commit": {
          "sha": "0000000"
        },
        "start_line": 196
      },
      "identifiers": [
        {
          "type": "gitleaks_rule_id",
          "name": "Gitleaks rule ID Password in URL",
          "value": "Password in URL"
        }
      ],
      "tracking": {
        "type": "source",
        "items": [
          {
            "file": "srv/salt/additional-prometheus.sls",
            "line_start": 196,
            "line_end": 196,
            "signatures": [
              {
                "algorithm": "rule_value",
                "value": "srv/salt/additional-prometheus.sls|password_in_url|c6031562506df6cb2147add62504dbdb7a5edfc16547b815d743581e5b9aa3a1"
              }
            ]
          }
        ]
      }
    },
[...]
  ],
  "dependency_files": null,
  "scan": {
    "analyzer": {
      "id": "secrets",
      "name": "secrets",
      "url": "https://gitlab.com/gitlab-org/security-products/analyzers/secrets",
      "vendor": {
        "name": "GitLab"
      },
      "version": "6.5.0"
    },
    "scanner": {
      "id": "gitleaks",
      "name": "Gitleaks",
      "url": "https://github.com/gitleaks/gitleaks",
      "vendor": {
        "name": "GitLab"
      },
      "version": "8.18.4"
    },
    "type": "secret_detection",
    "start_time": "2024-11-15T13:28:57",
    "end_time": "2024-11-15T13:28:57",
    "status": "success"
  }
}

Results of GitLab environment info

GitLab Enterprise Edition v17.5.2-ee

Possible fixes

I assume this line would have to be updated with some negative lookahead checking whether the "password" is enclosed in { } or {{ }}.

Edited by 🤖 GitLab Bot 🤖