CI/CD is more than a build: quality gates with GitLab CI and GitHub Actions

In brief: A production CI pipeline turns every merge into reproducible evidence that the source is correct, secure and buildable.

The problem

A green compile job can still ship unformatted generated files, skipped tests, vulnerable dependencies, leaked secrets or an image different from the one reviewed. Slow pipelines encourage bypasses; over-privileged runners turn pull requests into a supply-chain risk.

Why the simple answer is not enough

GitLab CI and GitHub Actions differ in syntax, but the architecture is the same: minimal permissions, isolated jobs, explicit dependencies, immutable artifacts and environment approval.

Security gates must be actionable. Findings need severity policy, owner, expiry for exceptions and a path to update vulnerable dependencies without disabling the scanner.

System flow

Architecture decisions

Fail fast, then go deep

Run formatting, source verification, lint and types first. Start integration tests, build and scans in parallel only after cheap checks pass.

Build once and promote

Create the container or package from the reviewed commit, record its digest and reuse it in staging and production instead of rebuilding.

Separate trust zones

Fork and pull-request jobs use read-only tokens. Signing and deployment run only on protected refs with short-lived workload identity and approved environments.

Going deeper

Source verification catches hidden drift

Check formatting, generated clients, schema output, lockfile consistency and forbidden large or secret files. The working tree must remain clean after generation.

Security exceptions are controlled debt

A temporary waiver records finding, owner, compensating control and expiry. Expired waivers fail the pipeline rather than becoming permanent silence.

Implementation path

1. Validate repository state, lockfiles and generated outputs before expensive jobs.
2. Run lint, type checks, tests and production builds in parallel with explicit quality thresholds.
3. Scan source and artifacts, then sign once and promote the same digest across environments.

Technical example: Equivalent quality-gate stages

verify: format --check; generated-diff; lockfile-policy
quality: lint; typecheck; unit --coverage; integration
build: production-build; migration-check
security: secret-scan; SAST; dependency-audit; image-scan
release: SBOM; sign(digest); attest(provenance)
deploy: promote(the_same_digest)

In GitLab, express ordering with stages and needs; in GitHub Actions, use jobs and needs. Keep the commands in repository scripts so local and CI execution stay identical.

Failure modes to design for

• A cache restores binaries from an untrusted branch.
• A test command exits zero after silently skipping a required project.
• The deployment job rebuilds with a floating base image and produces a new digest.

What to observe

How to validate the design

• Introduce one known lint, test, build, secret and vulnerable-dependency failure and prove each gate blocks.
• Open an untrusted pull request and verify no protected secret or runner is reachable.
• Trace a production digest back to commit, checks, SBOM, signature and approval.

Safe rollout plan

Measure the current pipeline, then add gates in report-only mode to establish noise. Fix deterministic failures, enforce fast checks first, security severity next and artifact signing last. Optimise with dependency caches and parallel jobs without weakening trust boundaries.

Production checklist

• Protected branches require the complete check set and current review.
• Untrusted pull requests cannot read deployment secrets or use privileged runners.
• A failed or cancelled job cannot leave a releasable partial artifact.

Takeaway

CI/CD is a chain of evidence from reviewed source to the exact artifact running in production.