GitLab project audits without opaque scoring

gitlab-project-audit inspects GitLab project configuration, governance, CI/CD, repository hygiene, variable metadata, pipeline history, and release metadata.

The tool is built around a simple rule: report observable conditions and keep policy explicit. It does not assign a mysterious health score. Each finding has a stable rule ID, severity, status, evidence, and—where appropriate—remediation.

What the project covers

• Project hygiene

  README, licence, topics, description, default branch, archive state, and repository metadata.

• Merge governance

  Protected branches, merge-request controls, pipeline gates, discussion resolution, and approvals.

• CI/CD

  GitLab CI YAML, workflow rules, image tags, includes, artifacts, cache scope, and pipeline settings.

• Security metadata

  CI/CD variable keys and safe metadata without retaining secret values.

• Operational history

  Bounded pipeline status summaries plus recurring failed jobs and stages.

• Release hygiene

  Tags, GitLab releases, release notes, tag consistency, and optional SemVer policy.

Design principles

1. Deterministic output. Stable rule IDs and ordering make results suitable for CI automation.
2. Permission-aware checks. “Unavailable” is not treated as “missing”.
3. Secret-safe boundaries. Variable values are deliberately discarded during collection.
4. Conservative static analysis. Dynamic GitLab CI constructs are reported as unknown when they cannot be proven statically.
5. Policy stays configurable. Teams can select rules, override severity, and document suppressions with reasons and optional expiry dates.

Current command status

The collectors, rule engine, configuration layer, reporting formats, portfolio orchestration, and single-project CLI audit path are implemented. The audit command now executes the complete API → collector → rule → policy → reporting flow.

Start with installation and authentication, then review the rule catalogue.