ISSUE-301 Critical Quick CLI CI/CD Secrets

Secret leak in pipeline configuration

Control: Pipeline must not leak secrets in configuration · Config key: pipelineMustNotLeakSecretsInConfig

📋 What is this?

A secret (API key, private key, password, cloud credential) is hardcoded in .gitlab-ci.yml or any included file, making it visible to anyone with repository access. Plumber resolves the full merged pipeline YAML and pipes it through gitleaks at analyze time; any high-confidence match against the built-in rule catalog (or a custom .gitleaks.toml via gitleaksConfigPath) becomes an ISSUE-301 finding. The detected value never leaves the scanner — each finding's preview carries a redacted form with first/last 4 characters visible and the middle replaced with asterisks.

⚠️ Impact

Hardcoded secrets increase the risk of unauthorized access to your systems, data leaks, and resource misuse. For example, if your API key is exposed, attackers could use it to access your cloud services, resulting in high costs or data theft.

🔧 How to fix

Revoke and rotate the exposed secret immediately, remove it from the configuration file, then inject it securely using GitLab CI/CD variables or an external secrets manager.

✗ Before Secrets hardcoded in .gitlab-ci.yml are visible in the repository to all members.

# .gitlab-ci.yml — ❌ Hardcoded secrets (CRITICAL)
deploy:
  stage: deploy
  script:
    - export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
    - export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
    - aws s3 sync . s3://my-bucket

api-call:
  variables:
    API_TOKEN: "ghp_exampleTokenHardcodedHere123"
  script:
    - curl -H "Authorization: token $API_TOKEN" https://api.example.com

✓ After Secrets are stored securely as CI/CD variables, not in the repository.

# .gitlab-ci.yml — ✅ Secrets injected via CI/CD variables
deploy:
  stage: deploy
  script:
    # AWS credentials injected from protected CI/CD variables
    - aws s3 sync . s3://my-bucket

api-call:
  script:
    - curl -H "Authorization: token $API_TOKEN" https://api.example.com

# In GitLab: Settings > CI/CD > Variables
# Add: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, API_TOKEN
# Set Protected: true, Masked: true for each

💡 Tips

If a secret was ever committed, treat it as compromised and rotate it immediately.
Use GitLab's secret detection feature to scan for leaked credentials in your repository history.
For production workloads, consider using an external secrets manager (HashiCorp Vault, AWS Secrets Manager, etc.).
Add secret patterns to .gitignore or use pre-commit hooks to prevent accidental commits.

⚙️ Configuration

This control is configured in .plumber.yaml under the gitlab section:

gitlab:
  controls:
    pipelineMustNotLeakSecretsInConfig:
      enabled: true

See the CLI documentation for the full configuration reference.

📋 What is this?

⚠️ Impact

🔧 How to fix

💡 Tips

⚙️ Configuration

🔗 Related issues