Building a CI/CD Hardening Scorecard You Can Show a Client

Score whether the client's default branch actually requires a passing pipeline and at least one approving review before a merge is allowed, not just whether the setting exists somewhere in the repository configuration. Both GitHub Actions and GitLab CI support this natively through branch protection rules and merge request approval rules; the gap is almost always in enforcement, not availability.

A surprising number of client repositories have the setting configured for their default branch but not for release branches, which is exactly where an attacker with stolen credentials would push a change to avoid review.

Score whether the pipeline actively blocks a merge when it detects a hardcoded credential or a dependency with a known critical vulnerability, rather than just flagging it after the fact. GitHub's secret scanning and dependency review, and GitLab's built-in secret detection and dependency scanning, both do this as pipeline jobs; the difference between clients is almost always whether the finding is configured to fail the build or just log a warning nobody reads.

A warning that doesn't block a merge is close to not existing for the purposes of a security assessment.

Score whether the client can prove that the artifact running in production is the exact one their pipeline built and tested, not something swapped in afterward. Both platforms support signing build artifacts and generating provenance attestations tying an artifact back to its source commit and pipeline run.

Change failure rate is a useful cross-check here too: teams with weak deploy controls tend to see more incidents traced back to changes that shouldn't have shipped¹. If a client can't answer which pipeline run produced a given production artifact, that's usually a sign the rest of the scorecard needs a closer look too.

Present the scorecard as a simple status per row, in place, partial, missing, alongside a specific fix for anything short of in place. Clients respond better to a concrete list of gaps and fixes than to a general statement that their pipeline needs hardening, and it gives you a natural follow-on engagement scoped around closing the gaps you found.

Re-run the scorecard on a schedule rather than treating it as a one-time assessment. Pipelines drift as teams add new repositories and new contributors, and a hardening review from a year ago tells you little about the client's current exposure. Attach a rough remediation timeline to each missing or partial row too, since a client's own leadership usually needs that timeline to prioritize the fix against everything else competing for engineering time.

A client-ready scorecard should include:

• A clear status for each row: in place, partial, or missing.
• A specific fix for every row that falls short of in place.
• A re-run schedule so the scorecard keeps tracking gaps over time.
• A proposed follow-on engagement scoped around closing the gaps you found.

This worksheet focuses on the pipeline itself, not the broader application security program it feeds into. A hardened pipeline still deploys vulnerable application code if nobody's running static analysis or a security review on the code itself; treat CI/CD hardening as one row in a larger security assessment, not the whole assessment.

Similarly, a self-hosted runner introduces its own attack surface that this scorecard doesn't score directly, patch status, network segmentation, and who has access to the machine deserve their own checklist alongside this one. A client who scores well on every row here can still have a poorly patched runner sitting on a flat network, so pair this worksheet with a separate review of the infrastructure the pipeline actually runs on before calling the assessment complete. Selling the two together, pipeline hardening and runner infrastructure review, is usually an easier conversation than presenting a clean pipeline scorecard and a separate, unrelated infrastructure finding weeks apart.