How to secure your CI/CD pipeline against supply chain attacks

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

The pipeline is a high-value target

Supply chain attacks are no longer theoretical. The SolarWinds breach, the Codecov bash uploader compromise, and the ua-parser-js npm hijack all followed the same pattern: attackers compromised a trusted component in the build or deployment pipeline, injecting malicious code that rode the legitimate release process into production.

For Nigerian fintechs, the pipeline is especially critical. It deploys code that handles real money — payment processing, wallet crediting, KYC verification. A compromised pipeline can inject a backdoor into your payment service, exfiltrate secrets to an external server, or modify transaction logic. During our penetration tests, we evaluate CI/CD configurations as part of the attack surface because it is often the easiest path to production access.

GitHub Actions: the attack surface you overlook

GitHub Actions is the most common CI platform for Nigerian fintech teams, and it is the most commonly misconfigured. The convenience of the marketplace — thousands of pre-built actions — is also its biggest risk.

GITHUB_TOKEN permissions

By default, GITHUB_TOKEN has write access to your repository contents, pull requests, and packages. If a malicious action or a compromised dependency runs in your workflow, it inherits those permissions. Set the default to read-only at the repository or organization level, then grant write permissions only to specific jobs that need them.

Pin actions by SHA, not tag

Using actions/checkout@v4 means you trust the action author not to push malicious code to the v4 tag. Tags are mutable — they can be moved to point to different commits. Pin actions to full commit SHAs: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11. Use Dependabot or Renovate to update these hashes when the action releases legitimate updates.

Secrets in CI: containment and rotation

CI secrets — database credentials, API keys, deployment tokens — are the crown jewels of your pipeline. If a workflow can read a secret, so can any code that workflow executes, including compromised dependencies.

• Use environment-scoped secrets. GitHub Actions supports environment protection rules with required reviewers and deployment branches. Your production secrets should only be accessible in workflows triggered from the main branch.
• Never log secrets. Mask values in workflow logs. Audit your workflows for echo commands or debug steps that might inadvertently print secret values.
• Rotate secrets on a schedule. If a secret was available to a CI job 90 days ago, and that job's logs are still accessible, the window for exposure is three months wide.
• Use OIDC federation instead of long-lived cloud credentials. GitHub Actions can exchange a short-lived token for temporary AWS, GCP, or Azure credentials via OIDC — no static access keys needed.

SAST and DAST integration

Static Application Security Testing (SAST) analyses your source code for vulnerabilities before it ships. Dynamic Application Security Testing (DAST) attacks the running application to find runtime issues. Both belong in your pipeline.

Run SAST tools (Semgrep, CodeQL, SonarQube) on every pull request. Block merges on high and critical severity findings. Run DAST tools (OWASP ZAP, Nuclei) against staging environments after deployment, feeding results back into your issue tracker. The key is making security findings impossible to ignore — not a report that sits in a shared drive.

For fintech-specific rules, configure Semgrep with custom rules that detect insecure payment patterns: missing webhook signature verification, hardcoded secret keys, SQL injection in transaction queries. We publish OWASP-aligned testing patterns in our OWASP fintech guide.

Dependency scanning and SBOMs

Your application is 80% third-party code. Every npm install, pip install, or go get pulls in a dependency tree that you implicitly trust. A single malicious or vulnerable package in that tree can compromise your application.

• Enable Dependabot or Renovate for automated vulnerability alerts and update PRs.
• Use lockfiles (package-lock.json, pnpm-lock.yaml) and verify their integrity in CI.
• Audit dependencies regularly with npm audit, pip-audit, or govulncheck.
• Generate SBOMs (Software Bill of Materials) using tools like Syft or CycloneDX. When a new CVE drops, you need to know in minutes whether your production systems are affected.

Signed commits and artifact verification

Without commit signing, anyone with repository write access can impersonate another developer in the Git history. Enforce GPG or SSH commit signing across your organisation and require signature verification in your branch protection rules.

For build artifacts — container images, deployment packages — use Cosign (from the Sigstore project) to sign images after they are built and verify signatures before deployment. This creates a chain of trust: only images built by your CI pipeline, from signed commits, are allowed to run in production.

Pipeline hardening checklist

• Set GITHUB_TOKEN permissions to read-only by default.
• Pin all third-party actions to full commit SHAs.
• Scope secrets to specific environments with branch restrictions.
• Use OIDC federation for cloud credentials — eliminate static keys.
• Run SAST on every PR and DAST against staging after deployment.
• Enable dependency vulnerability scanning and use lockfiles.
• Enforce signed commits and verify signatures in branch protection.
• Sign container images with Cosign and verify before deployment.
• Never curl | bash — vendor scripts and verify checksums.

For a comprehensive view of security controls before launching a fintech product, see our security before fundraising guide — investors increasingly ask about supply chain security during due diligence.

Related reading

Blog: Security culture in fintech engineering · Third-party vendor risk · Cloud security checklist

Guides: OWASP for fintech · Pentest tools and methodology · Security before fundraising

Services: Penetration testing · Secure architecture review · API security