CI/CD audit

What this audit answers

The CI/CD audit asks whether delivery automation exists, is valid, performs meaningful work, protects important transitions, and provides a credible path toward release and deployment. It follows a maturity ladder: runnable commands, valid pipeline configuration, real checks, blocking behavior, complete gate composition, stable feedback, and delivery automation.

A working but inefficient pipeline ranks above an elegant pipeline that does not parse or never runs. Performance and reuse matter only after basic delivery protection is established.

What Guard inspects

Guard reads provider workflow files, shared scripts, build and test commands, package and artifact definitions, container files, deployment manifests, release configuration, environment and rollback documentation, and observable run metadata when access permits. Static validation checks that referenced commands, files, actions, and reusable workflows exist.

Provider API visibility can strengthen conclusions about required checks and recent run health. When that visibility is unavailable, blocking behavior and observable health may be marked unobservable instead of guessed.

The 14 criteria

The scorecard covers CI presence and trigger coverage; configuration validity; meaningful gate composition; blocking behavior; local-to-CI command parity; deterministic tools and references; observable health; workflow and secret hygiene; feedback speed; artifact automation; container integration; deployment automation; release process; and promotion and rollback safety.

Each applicable criterion receives 0–5. A non-deployable docs or configuration repository can be a valid no-op rather than being penalized for not having a production pipeline. Container integration can likewise be not applicable when the repository has no containers.

How the score works

Applicable criterion points are normalized to 0–100. Confirmed findings then reduce the result by 20 for critical, 8 for high, 3 for medium, and 1 for low impact, with total deductions capped at 35.

Evidence-backed caps apply after deductions:

• an active deployable application or service with no CI is capped at 39;
• advisory-only or broadly neutralized primary gates cap the score at 59;
• a missing primary category such as build or tests, when the repository defines it, caps the score at 69;
• materially incomplete observability can cap an otherwise solid result at 79 while lowering confidence.

No CI does not automatically mean zero. Strong deterministic local commands still earn credit inside the capped band and give the improvement workflow a safer foundation.

Limitations and boundaries

The audit is read-only. It does not trigger deployments, publish releases, modify branch protection, rotate secrets, or test rollback against production. Missing provider API access is a limitation, not evidence that gates are non-blocking. Test content belongs to Test quality; dependency acquisition safety belongs to Dependency hygiene; actual leaked credentials belong to Security.

Improvements and reruns

Improvements should climb the maturity ladder without skipping foundations. A repository with no pipeline first needs shared runnable commands and a valid minimal workflow. A working pipeline can then add missing checks, make proven gates blocking, improve determinism and speed, and finally strengthen artifact, release, deployment, promotion, or rollback automation.

Provider-admin changes and production delivery controls usually require owner review and may remain issue-only. Rerun after the workflow or provider setting is in effect, and verify both configuration and observable behavior where access allows it.