Secure CI/CD pipelines for regulated fintech

A regulated fintech CI/CD pipeline gets visited by three groups:

• The engineering team, who want it fast
• The security team, who want it safe
• The auditor, who wants evidence both are true

Most pipelines I review optimise for the first and have ad-hoc answers for the other two. The seven baseline controls below close that gap.

The seven baseline controls

1. OIDC for cloud + registry auth (no long-lived tokens)

Long-lived API tokens stored as CI secrets are the highest-impact attack vector in a fintech CI/CD setup. Replace with OIDC federated identity:

• GitHub Actions → cloud provider (AWS / Azure / GCP / Cloudflare): use the cloud’s OIDC trust to issue short-lived (≤1 hour) tokens
• Container registry pushes: same pattern (ECR / GAR via OIDC)
• Production deploy steps in pinned environments only

Auditor question this answers: “How long are deploy credentials valid?” Answer: “≤1 hour, scoped to a specific job in a specific environment, audited per use.”

2. SHA-pinned actions + dependency digests

Every uses: <action>@<ref> in your workflows pinned to a 40-char SHA (not a tag). Every Docker FROM pinned to tag + digest. Every npm package locked in pnpm-lock.yaml (or equivalent).

This blocks the supply-chain class of attack where a tag (@v1) gets republished pointing at malicious code.

Renovate / Dependabot keeps the SHAs current with audit trail per bump.

3. Software bill of materials (SBOM) per build

Every build emits an SBOM (CycloneDX or SPDX format) listing every dependency by version + hash. Stored alongside the build artefact.

Auditor question this answers: “What’s in the binary you deployed yesterday?” Answer: “Here’s the SBOM. Cross-reference these package-version hashes against the lockfile from that commit.”

4. SAST + DAST + secrets scanning, blocking on high+

• SAST (Semgrep with p/owasp-top-ten + p/<language> is high-value): runs per PR, blocks on high+ findings.
• DAST against staging deployments (OWASP ZAP or commercial alternative): runs nightly, blocks weekly release if high+.
• Secrets scanning (gitleaks, GitGuardian, or GitHub’s native): runs on every commit, blocks on push.

False-positive triage process documented; suppressions tracked in allow-list with rationale + sign-off.

5. Signed builds + signed deploys

• Signed builds: build artefact signed by the CI system’s ephemeral identity (Sigstore / cosign, or cloud-native equivalent)
• Signed deploys: deploy step verifies the signature before promoting to a production environment

This blocks the class of attack where an attacker who compromises one CI step can’t promote arbitrary artefacts to production without ALSO compromising the signing identity.

6. Mandatory code review with CODEOWNERS

Branch protection on main requires at least one approval. CODEOWNERS enforces topic-expert review on sensitive paths (auth, payments, IAM, infrastructure). For regulated fintech, consider mandatory two-approver review on the CDE (cardholder data environment) paths.

Conventional commits + signed commits give the audit trail.

7. SoC observability — every CI step is a security event

Every CI step writes a structured event (job started, job completed, deploy initiated, signature verified, etc.) to the same observability pipeline as runtime security events. The SoC sees CI activity in the same dashboard as production traffic.

Anomalies (a deploy at 3am from an unusual region; a CI job ending in a signature-verification failure; a sudden spike in CI runs from a single PR) become alerts.

What the auditor wants to see

• Evidence retention: 12 months of build / deploy / signing / scan artefacts, queryable
• Separation of duties: developer doesn’t deploy to prod without approval; CI does the deploy, with a documented approval flow
• Vulnerability triage: SAST / DAST findings have a documented status (open / mitigated / accepted) with owner + due date
• Change record: every prod change traceable to a PR, an approver, a signed commit, and a deploy job
• Incident response: documented playbook for “compromise of a CI credential” — which the OIDC approach in control 1 makes dramatically shorter

What goes wrong

Three patterns from regulated fintech engagements (anonymised):

Failure 1 — long-lived tokens in CI secrets

Often the first thing I find. Fix: OIDC migration in 1-2 sprints. Often unblocks 30+ control gaps in one go.

Failure 2 — SAST blocked on tag-pinned actions

The team’s workflows reference actions/checkout@v4 style. CI guard catches it but the team has 50+ workflow files to update. Fix: scripted mass migration; Renovate config to enforce going forward.

Failure 3 — SBOM exists but isn’t cross-referenced

The build emits SBOM but nobody queries it during incident response or vulnerability assessment. Fix: vulnerability scanner ingests the SBOM and matches against CVE feeds; alerts on new CVEs in deployed versions.

How to know you’re getting it right

Five signals:

• Time from new CVE published to “we know if we’re affected”: minutes, not days
• Time from PR merge to production deploy: minutes (your release cadence)
• Mean number of high+ SAST/DAST findings per release: trending down
• Audit findings on CI/CD: trending down across cycles
• Number of long-lived API tokens in CI secrets: zero

What to do tomorrow morning

If you have one of the seven controls, you have the start of a programme. If you have all seven, you have an audit-ready CI/CD pipeline.

If you have none — start with control 1 (OIDC) and control 2 (SHA pinning + Dependabot/Renovate). Together they take 1-2 sprints and remove the highest-impact class of supply-chain risk.

---

This article is part of our AI Security Guardrails pillar (CI/CD security is foundational to AI agent platforms). For hands-on help redesigning your pipeline, see our DevSecOps and SOC service.