Supply chain
Supply Chain & CI/CD Security: from commit to production in 2 weeks
A review of everything that turns a commit into a production workload: workflows, runners, registries, manifests, clusters. A pipeline that can neither be hijacked nor used as an entry point.
Context
The CI/CD pipeline has become the shortest path to production, for your teams and for an attacker. A compromised third-party GitHub action, a misunderstood pull_request_target, a GITHUB_TOKEN with write-all, a self-hosted runner shared between public and private repos, a secret in a build log: every year, public incidents remind us that the supply chain is the link nobody audits.
On the deployment side, ArgoCD and Kubernetes add their own surface: an exposed ArgoCD with the local admin enabled, AppProjects with no destination restriction, plaintext secrets in Git, no admission policy, unsigned latest images running in production.
This audit covers the full chain, from repository to cluster, in 2 weeks. The goal: that a compromised developer, dependency or runner does not turn into a compromised production.
Who it’s for
- A team shipping to production via GitHub Actions (or GitLab CI) several times a week
- Kubernetes clusters (EKS, AKS, GKE or self-hosted) deployed via ArgoCD, Flux or Helm
- Self-hosted runners, unpinned third-party actions, secrets shared across environments
- A customer or regulatory requirement on build traceability (SOC2, NIS2, DORA, SLSA)
- Doubt about what a compromised developer, token or dependency could actually do
What’s delivered
Week 1 — Repositories, workflows and runners
- Inventory of repositories, workflows, third-party actions, runners and registries
- GitHub Actions review:
GITHUB_TOKENpermissions, dangerous triggers (pull_request_target,workflow_run), injection via${{ }}, SHA pinning, environments and approvals - Cloud authentication from CI: migrating static keys to OIDC, strict
subconditions, per-environment roles - Runners: isolation, ephemerality, network access, sharing between repos, exposed secrets
- Secrets management: where they live, who reads them, rotation, leaks in logs and Git history
- Branch protection, mandatory reviews, commit signing, merge rules
Week 2 — Artefacts, GitOps and runtime
- Images: vulnerability scanning prioritised by exploitability, base images, root users, SBOM, signing and attestation (Sigstore/cosign)
- Registries: retention policies, tag immutability, pull/push access
- ArgoCD or Flux: exposure, SSO and RBAC,
AppProjects and destinations, secrets (External Secrets, Sealed Secrets, SOPS), drift detection, service account permissions - Kubernetes: RBAC, admission policies (Kyverno, OPA Gatekeeper or Pod Security Admission), network policies, secrets, service accounts and IRSA/Workload Identity
- 30/60/90-day action plan prioritised by exploitability, with corrected workflows, policies and manifests provided as examples
What’s not included
- Full implementation of the recommendations (covered by the retainer or a specialised engagement)
- Application security review of the code itself (in-depth SAST, manual review)
- Overall cloud account posture (IAM, network, data), covered by the Cloud Security Audit
- Migrating from one CI/CD tool to another
Format and timeline
Fixed price set after a 15-minute scoping call, 2 weeks from kick-off to deliverable. The scope is independent of the underlying cloud: AWS, Azure, GCP or on-premise.
Access is read-only on the GitHub organisation, clusters and registries, revoked on the last day.
Why Distribuée
Senior DevSecOps, 10 years of CI/CD and Kubernetes platforms in regulated environments. 6 AWS certifications including DevOps Engineer Professional and Security Specialty. Distribuée’s angle on supply chain: treat the pipeline as a production system in its own right, with the same requirements for identity, traceability and least privilege.
Start the engagement
15 minutes to scope your perimeter.
No commitment. We review your perimeter together, qualify whether the engagement makes sense and set the fixed price.
Book 15 min