GitLab-CI-Inspektor

Detecting Security Issues in GitLab CI Pipelines

GitLab CI/CD pipelines defined in .gitlab-ci.yml automate build, test, and deployment workflows. Like any automation that executes code and handles secrets, misconfigured pipelines create security vulnerabilities — hardcoded secrets in scripts, Docker-in-Docker with privileged access, insecure base images, and shared runners executing sensitive deployment jobs. The GitLab CI Inspector scans your pipeline definitions to detect these security issues before they are exploited.

Paste your .gitlab-ci.yml content to receive security analysis covering secret exposure in scripts, image security, dangerous allow_failure configurations, Docker-in-Docker privilege escalation, artifact retention policies, and runner trust boundaries. Each finding includes severity classification and specific remediation guidance. All analysis happens entirely in your browser with zero data transmission.

Secret Exposure in Pipeline Scripts

The inspector detects secrets hardcoded or improperly handled in pipeline definitions:

• Secrets in script blocks: API keys, tokens, or passwords appearing directly in script: commands
• Echo of secret variables: echo $SECRET_TOKEN printing secrets to job logs visible to all project members
• Secrets in variables section: Sensitive values defined in the YAML file rather than GitLab CI/CD settings (protected/masked)
• Unmasked variables: Variables containing secrets that are not configured as masked in GitLab settings

Docker-in-Docker and Privilege Escalation

Container-based CI/CD introduces privilege escalation risks:

• Docker-in-Docker (dind): Services using docker:dind require privileged mode, granting full host access to the container
• Docker socket mounting: Mounting /var/run/docker.sock enables sibling container creation with arbitrary capabilities
• Privileged runners: Jobs executing with --privileged flag have unrestricted kernel access
• Untagged runners: Jobs without specific runner tags may execute on shared infrastructure alongside untrusted projects

Pipeline Configuration Safety

Structural pipeline issues that create indirect security risks:

• allow_failure on security jobs: If SAST, DAST, or dependency scanning jobs are configured with allow_failure: true, security findings never block deployment
• Missing artifact expiry: Build artifacts without expire_in accumulate indefinitely, potentially containing sensitive build outputs
• Insecure base images: Using :latest tags or unverified images introduces supply chain risk — images can be replaced with malicious versions
• Deployment on shared runners: Production deployment jobs should only run on protected, organization-controlled runners — not shared infrastructure

The inspector also checks for missing rules: or only: conditions on deployment stages. Without branch restrictions, merge requests from any contributor can trigger production deployments. Best practice requires that deploy jobs include rules: - if: $CI_COMMIT_BRANCH == "main" to restrict execution to protected branches only.

Remediation Guidance and Severity Levels

Each finding includes a severity classification and actionable remediation steps:

• CRITICAL: Immediate action required — secrets in plaintext, privileged execution without justification
• HIGH: Should be fixed before next deployment — Docker socket exposure, untagged runners for sensitive jobs
• WARNING: Best practice violations — mutable image tags, missing artifact expiry, allow_failure on security scans
• INFO: Optimization suggestions — consolidating stages, caching improvements, parallel job opportunities

The inspector maps each issue to GitLab documentation references and provides copy-paste YAML snippets for the corrected configuration. For secret exposure findings, it suggests the specific GitLab CI/CD variable type (file vs variable) and protection level (protected, masked) appropriate for each secret category.

Code Examples

GitLab CI with Security Issues

# .gitlab-ci.yml with issues detected
image: node:latest  # WARN: mutable tag

variables:
  API_KEY: "sk_live_abc123"  # CRITICAL: secret in YAML

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "Building with key $API_KEY"  # HIGH: echoing secret
    - npm run build

security_scan:
  stage: test
  allow_failure: true  # WARN: security scan can't block pipeline
  script:
    - npm audit

deploy:
  stage: deploy
  script:
    - curl -H "Authorization: $DEPLOY_TOKEN" https://deploy.example.com
  # WARN: no runner tag restriction — may run on shared runners

services:
  - docker:24-dind  # HIGH: requires privileged mode