Skip to main content
Menu
On this page

Compliance Controls

Plumber checks your CI/CD configuration and project settings against a catalog of controls. The catalog is split per provider: GitLab controls inspect .gitlab-ci.yml and GitLab project settings, GitHub controls inspect .github/workflows/*.yml and GitHub repository settings. Pick the provider tab below to see the relevant catalog.

When a control is not respected, an issue is created. Click the ISSUE-XXX link in any row to see the full description, impact, and remediation for that issue.

Scope

  • All: Plumber Platform and Open Source CLI
  • Platform: Plumber Platform only
  • CLI: Open Source CLI only (not a Platform control)

CI/CD provider

CI/CD Container Images

ScopeControlWhat it checksWhy it matters
AllContainer images must come from authorized sources ISSUE-101Verifies that container images used to run your CI/CD pipelines come from authorized and trusted sources.Helps mitigate security risks introduced by the use of malicious, compromised, or vulnerable images.
AllContainer images must not use forbidden tags ISSUE-102Verifies that container images used to run your CI/CD pipelines rely on authorized tags.Helps mitigate both security and functional risks introduced by the use of unverified, outdated, or compromised image versions.
CLIContainer images must be pinned by digest ISSUE-103Verifies that container images are referenced by their SHA256 digest rather than a mutable tag.Prevents supply chain attacks where a tag is overwritten with a compromised image, guaranteeing exact image content in every pipeline run.

CI/CD Variables

ScopeControlWhat it checksWhy it matters
PlatformCI/CD variables must be protected ISSUE-201Verifies that CI/CD variables used in a project have the protected field enabled.Ensures sensitive values are restricted to protected branches or tags, reducing unauthorized exposure.
PlatformCI/CD variables must be masked ISSUE-202Verifies that CI/CD variables used in a project have the masked field enabled.Prevents variable values from being exposed in pipeline logs, reducing the risk of leaks.
CLIPipeline must not enable debug trace ISSUE-203Verifies that CI_DEBUG_TRACE and CI_DEBUG_SERVICES are not enabled in the pipeline configuration.Prevents exposure of all CI/CD variable values in job logs, including secrets and tokens.
CLIPipeline must not use unsafe variable expansion ISSUE-204Detects user-controlled CI variables expanded in shell re-interpretation contexts (eval, sh -c, bash -c, source).Prevents command injection via crafted branch names, MR titles, or commit messages (OWASP CICD-SEC-1).
CLIPipeline must not override job variables ISSUE-205Detects controlled CI/CD variables redefined in .gitlab-ci.yml that should only be set in GitLab CI/CD Settings.Reduces risk of tampering with scanner settings or other governed variables via pipeline YAML.

CI/CD Secrets

ScopeControlWhat it checksWhy it matters
CLIPipeline must not leak secrets in configuration ISSUE-301Pipes the resolved .gitlab-ci.yml (with all include:s merged) through gitleaks. Any high-confidence match against the built-in or a custom rule set surfaces as a Critical finding with the secret value redacted to first/last 4 chars.Catches the most common credential-leak path (someone pastes a token into the YAML “just to test”). Detection is opt-in because gitleaks must be installed separately; once enabled, redaction guarantees the raw secret never reaches the JSON report.

Pipeline Composition

ScopeControlWhat it checksWhy it matters
AllPipelines must include templates ISSUE-405 ISSUE-406Verifies that the projects contain specific templates. This control can also allow overriding certain variables in the included templates.Ensures pipelines comply with required security and compliance practices.
AllPipelines must include components ISSUE-408 ISSUE-409Verifies that the projects contain specific GitLab components. This control can also allow overriding certain variables in the included components.Ensures pipelines integrate mandatory security and compliance steps.
PlatformPipeline must include required phases ISSUE-407Verifies that the CI/CD pipeline includes a group of job types.Ensures completeness and compliance of the pipeline execution flow.
AllPipeline must not contain hardcoded jobs ISSUE-401Verifies that no hardcoded job is used in CI/CD pipelines.Improves maintainability and ensures compliance with best practices.
AllPipeline must not use forbidden ref in includes ISSUE-404Verifies that the included refs are using specified tags.Prevents reliance on insecure or non-compliant references.
AllPipeline must use only up-to-date includes ISSUE-403Verifies that the included pipelines are up-to-date compared to their source.Reduces risks from outdated or vulnerable templates.
CLISecurity jobs must not be weakened ISSUE-410Detects security scanning jobs (SAST, Secret Detection, Container Scanning, etc.) weakened by allow_failure: true, rules: overrides with when: never / when: manual, or when: manual at job level.Prevents silently neutralized security scans that give a false sense of compliance (OWASP CICD-SEC-4).
CLIPipeline must not execute unverified scripts ISSUE-411Detects jobs that download and immediately execute scripts from the internet (curl | bash, wget | sh, download-then-execute) without integrity verification.Prevents supply chain attacks where a compromised URL serves a modified script that exfiltrates secrets (OWASP CICD-SEC-3, CICD-SEC-8).
CLIPipeline must not use Docker-in-Docker ISSUE-412 ISSUE-413Detects Docker-in-Docker (docker:dind) services and insecure daemon configuration (for example plaintext Docker API).Reduces container escape and lateral movement risk on shared runners; prefer Kaniko or Buildah for image builds.

Access and Authorization

ScopeControlWhat it checksWhy it matters
AllBranch must be protected ISSUE-501 ISSUE-505Verifies that the project configuration respects the protection, push, merge and owner approval on included branch names.Prevents unauthorized modifications and enforces branch protection standards.
PlatformMR approval rules must have at least N approval required ISSUE-502Verifies that the project merge request approval rules that cover all protected branches have a minimum number of approval requirements.Prevents unreviewed code from being merged, reducing security risks.
PlatformMR approval settings must be compliant ISSUE-503Verifies that MR approval settings are properly configured.Ensures compliance with review and security requirements.
PlatformAn MR approval rule must be defined to cover all protected branches ISSUE-504Verifies that the protected branches have at least one approval rule.Ensures protected branches cannot bypass review processes.
PlatformMR settings must be compliant ISSUE-506Verifies that the project’s merge request settings are correct in terms of merge method, resolving differences, squashing, etc.Reduces risk of unauthorized or insecure code changes.
PlatformNumber of project members must respect a quota ISSUE-507Verifies that the project configuration respects the owner, maintainer and developer quotas.Prevents uncontrolled access that could weaken project security.
PlatformNumber of group members must respect a quota ISSUE-508Verifies that the group configuration respects the owner, maintainer and developer quotas.Prevents uncontrolled access at group level, strengthening governance.

Security Source

ScopeControlWhat it checksWhy it matters
PlatformProject must have a security policy source ISSUE-601Verifies if the projects have a specific project as their source of security policy.Ensures compliance with security policy and reduces risk of unmanaged vulnerabilities.