#92 rule: extend CI/CD-config protection beyond GitHub Actions (GitLab, Jenkins, CircleCI, Azure Pipelines)

[Anonymous]

Originally created by: fu351

Why

An agent that can silently edit CI/CD config can exfiltrate the secrets CI holds or inject malicious build/deploy steps — a classic supply-chain escalation. Doberman already treats GitHub Actions as sensitive: .github/workflows/** is in DEFAULT_SENSITIVE_GLOBS (src/doberman/engine/rules/paths.py, ~line 87), so writes there step up to AUTH via ProtectedPathRule.

But other major CI systems are unprotected — a grep across src/doberman/ finds zero coverage for:

• .gitlab-ci.yml (GitLab CI)
• Jenkinsfile (Jenkins)
• .circleci/config.yml (CircleCI)
• azure-pipelines.yml (Azure Pipelines)

What to do

Add those globs alongside the existing GitHub entry so they get the same treatment. Keep it raise-only — match to AUTH (sensitive_path_access), mirroring the current .github/workflows/** behavior, not a new hard block (open a discussion if you think one deserves BLOCK).

• Primary spot: DEFAULT_SENSITIVE_GLOBS in engine/rules/paths.py.
• Also check src/doberman/roles/builtin_roles.yaml, where .github/workflows/** appears as a role-boundary pattern — the CI siblings likely belong there too.

Tests (tests/unit, extend the path-rule tests)

• Each new CI path (.gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, azure-pipelines.yml) resolves to AUTH with sensitive_path_access.
• A benign sibling path (e.g. src/gitlab_client.py) stays PASS.
• A ../padded traversal that lands on a CI file still matches (paths are canonicalized before matching — reuse the existing helper).

Done when

• Writing any of the four CI configs steps up to AUTH.
• Tests added and green.
• The README rule summary reflects the broadened CI coverage.

Why this is a good first issue

Additive, tightly scoped, and it mirrors a pattern already in the file — but it closes a real supply-chain gap.

[Anonymous]

Ticket changed by: fu351

• status: open --> closed