CI/CD Pipeline Setup
From commit to production in minutes — with security gates at every stage. SAST, SCA, container scanning, secret detection, SBOM, SLSA supply chain security, and zero-downtime deployments.
Full pipeline — 8 stages
Every stage we implement, what it covers, and why it matters.
Source & Trigger
- Branch protection rules & required reviewers
- Conventional commit enforcement
- Pre-commit hooks (lint, format, secret scan)
- Merge request / pull request templates
- Protected branches: main, release/*
Build & Package
- Multi-stage Dockerfile (build → test → runtime)
- Non-root user, minimal base image (distroless / alpine)
- Layer cache via registry or BuildKit
- Reproducible builds (pinned deps, lockfiles)
- SBOM generation (Syft / CycloneDX / SPDX)
- Image signing (Cosign / Sigstore)
Test & Quality
- Unit tests with coverage threshold (≥ 80%)
- Integration tests against real services
- E2E tests (Playwright / Cypress)
- API contract testing (Pact)
- Performance regression tests
- Database migration dry-run
Security Gates
- SAST — Semgrep, SonarQube, CodeQL
- SCA — Dependency audit, OWASP Dependency-Check
- Container scan — Trivy, Grype (block on CRITICAL)
- Secret detection — Gitleaks, Trufflehog
- IaC scan — Checkov, tfsec, tflint
- DAST — OWASP ZAP on staging environment
- License compliance check
- SLSA provenance attestation
Deploy Staging
- Auto-deploy on merge to main
- Helm upgrade with --atomic rollback
- Smoke tests + healthcheck validation
- DB migration via init container
- Notify team via Slack / PagerDuty
- Environment drift detection
Production Gate
- Manual approval or scheduled release window
- Change freeze enforcement
- Pre-production canary (5% → 25% → 100%)
- Rollback trigger on error rate SLO breach
- Deployment audit log (who, what, when)
Deploy Production
- Blue/green or canary via Argo Rollouts
- Zero-downtime: maxUnavailable=0
- Readiness probe gate before traffic shift
- Automatic rollback on failed healthcheck
- Post-deploy synthetic monitoring
Observe & Notify
- Deploy marker in Grafana / Datadog
- Error rate & latency delta alert
- Slack deploy summary (image, changelog, who)
- DORA metrics tracking (lead time, MTTR)
- Automated rollback notification
Security standards
We follow OWASP, NIST SSDF, and SLSA guidelines. Security is a gate — not an afterthought.
SAST (Static Analysis)
Semgrep rules for OWASP Top 10, SonarQube quality gates, CodeQL for GitHub repos. Block merge on HIGH/CRITICAL findings.
SCA (Software Composition)
Audit all direct and transitive dependencies. OWASP Dependency-Check, npm audit, pip-audit. Block on known exploited CVEs (CISA KEV).
Container Security
Scan every image layer for CVEs before push. Enforce base image freshness policy. No root user, read-only filesystem.
Secret Detection
Scan every commit and PR for leaked API keys, tokens, certificates. Pre-commit + CI gate. Gitleaks with custom regex for internal patterns.
IaC Security
Every Terraform, Helm, and Kubernetes manifest scanned for misconfigurations before apply. Block on CIS benchmark violations.
Supply Chain (SLSA)
SBOM generated on every build. Image signed with Cosign + Sigstore. SLSA Level 2 provenance attestation. Admission webhook enforces signed images only.
Full technology stack
We work with the tools you already use, or recommend the right ones for your context.
CI Platforms
Build & Package
SAST
Container & SCA
Secret Scanning
IaC Scanning
Supply Chain
Deployment
Secrets Management
Quality & Testing
Versioning & Release
Notifications & DORA
What you get
We measure success with DORA metrics
Industry-standard engineering performance indicators — not vanity metrics.
Deployment Frequency
Multiple times/day
How often you ship to production
Lead Time for Changes
< 1 hour
Commit to production time
Change Failure Rate
< 5%
% deploys causing incidents
MTTR
< 1 hour
Time to restore after incident
Questions
GitLab CI vs GitHub Actions — which one?
Depends on where your code lives. GitLab CI is deeply integrated with GitLab and has native secret management, SAST, and container scanning built-in (no extra plugins). GitHub Actions has a larger marketplace ecosystem. We work with both and won't push you to switch — the best pipeline is the one your team actually uses.
Our pipeline takes 30+ minutes. How fast can you get it?
Most 30+ minute pipelines can be cut to under 8 minutes. The usual culprits: no Docker layer caching, sequential jobs that should be parallel, running all tests even when only one service changed, and bloated base images. We've cut pipelines from 45min to 3min.
How do you handle secrets — no hardcoded credentials?
Correct. Secrets never live in code, CI variables in plaintext, or Docker layers. We integrate HashiCorp Vault (dynamic credentials), AWS Secrets Manager, or External Secrets Operator depending on your stack. Each pipeline job gets least-privilege, short-lived credentials only for what it needs.
What is SLSA and do we need it?
SLSA (Supply chain Levels for Software Artifacts) is a security framework for build integrity. At Level 2, every build produces a signed provenance attestation — proof of what code was built, on what system, by which pipeline. It protects against supply chain attacks (like SolarWinds). We recommend it for any team deploying to production.
Do you support monorepos?
Yes. We configure change-detection so only affected services are rebuilt and redeployed. Works with Nx, Turborepo, Bazel, or custom shell-based change detection. A change in service-A doesn't trigger a rebuild of service-B.
What security gates block the pipeline vs just warn?
CRITICAL CVEs in container images: block. HIGH/CRITICAL SAST findings: block. Leaked secrets: block, alert security team. MEDIUM findings and below: warn, don't block — to avoid alert fatigue. All thresholds are configurable and tuned to your risk tolerance.
Let's build a pipeline your team trusts
Tell us your current setup. We'll show you exactly what we'd change and why.
Book Discovery Call30 min · Free · No commitment