CI/CD & DevSecOps

Pipeline design, IaC quality, secrets management, SAST / DAST / SCA integration, image signing, and the trust boundary between your build system and production. Shift-left without the theater.

Audit category · 05 of 08

Scope

What this audit covers

The CI/CD & DevSecOps category treats the build system as a production system — because for practical purposes it is. A compromise of the pipeline is a compromise of everything it can deploy.

Pipeline architecture

GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI, Buildkite. Runner isolation, job permissions, workflow trigger hygiene, third-party action / plugin provenance.

Secrets management

Where build-time secrets live, how they reach jobs, rotation cadence, exposure to forked-PR workflows, access-log coverage. Vault / Secrets Manager / Key Vault integration.

Identity & trust

OIDC-to-cloud trust policies, subject-condition narrowing, service-principal scopes, long-lived key usage, branch-protection enforcement.

Static analysis

SAST (Semgrep, SonarQube, CodeQL), secrets scanning (gitleaks, trufflehog), SCA (Snyk, Dependabot, Renovate), IaC scanning (tfsec, checkov, kics).

Artifact & supply chain

Container image signing (cosign), SBOM generation (syft, cyclonedx), provenance (SLSA), private registry controls, base-image hygiene.

Deployment strategy

Canary / blue-green / progressive delivery, manual-approval gates for prod, rollback paths, environment separation, production-code drift detection.

Why it matters

The pipeline is the new perimeter

SolarWinds, Codecov, the 3CX incident, and a long tail of open-source attacks have turned build-system compromise from an exotic threat into a boardroom concern. At the same time, most engineering teams have inherited a CI/CD setup that was scaffolded for speed, not security.

The goal of this audit is not to slow the pipeline down. It is to make the shortest path the safe path — so that the fast option and the secure option are the same option, and security does not depend on engineer vigilance.

Method

How we assess it

Assessment has three angles.

Angle A

Configuration review

Pipeline definitions, workflow files, IaC for runners, branch-protection rules, cloud trust relationships. Static, repo-side review.

Angle B

Runtime observation

Actual pipeline runs with access logs. What secrets flow where, what tokens are minted, what external services are contacted, what artifacts are produced.

Angle C

Supply-chain mapping

Every third-party action, plugin, base image, and package ingested by the pipeline. Pinning, provenance, and revocation paths.

We benchmark against SLSA (Supply-chain Levels for Software Artifacts), OWASP Top 10 CI/CD Security Risks, and the CIS Software Supply Chain Security Guide. Findings cite back to specific controls.

Deliverables

What you get

Pipeline threat model — trust boundaries drawn, attack paths enumerated, compensating controls mapped.
SLSA level assessment — current level per pipeline, gap list to reach the next level, recommended target.
Secrets inventory — every build-time secret, its scope, its rotation status, its exposure surface.
Third-party dependency register — every external action / plugin / base image, pinned-version status, maintainer health.
Tool-integration plan — where SAST, DAST, SCA, and IaC scanning belong in the pipeline, realistic noise/signal expectations, triage workflow design.
Remediation roadmap — sprint-sized work packages, sequenced so each increment is independently shippable.

Patterns

Common findings

Secrets as CI environment variables, lifetime forever.

Long-lived AWS / Azure / GCP credentials pasted into repository secrets, never rotated, shared across dozens of workflows. Replace with OIDC federation — short-lived, scoped per workflow.

Over-scoped OIDC trust policies.

A cloud role trust policy that grants any workflow in the organization. Subject conditions should pin to repo + branch + environment.

Unpinned third-party actions / plugins.

`uses: some-org/action@v2` instead of a commit SHA. A compromised tag silently propagates. Pin to full-length SHA, audit the pinning regularly.

pull_request_target used with checkout of untrusted PR code.

The classic GitHub Actions footgun — runs privileged with the fork's code. Either drop pull_request_target or refuse to check out the fork.

No image signing, no SBOM.

Containers are built, pushed, and deployed with no cryptographic chain of custody. Cosign + syft + a policy engine (Kyverno, OPA, Ratify) closes this gap with a week of platform work.

SAST / SCA enabled but not triaged.

Thousands of findings in Snyk / Semgrep / Dependabot, nobody assigned. Tools are installed; outcomes are zero. We redesign the triage pipeline so every finding has an owner and a SLA.

Prod deploys from developer laptops in emergencies.

Emergency break-glass path bypasses every control in the pipeline. Worth keeping; worth auditing; must be logged, approved, and rare.

FAQ

Questions we get asked

We are already using Snyk / Dependabot / GitHub Advanced Security. Do we need this? +

Tool adoption is not posture. We assess whether the tools you have are integrated at the right pipeline stages, tuned to your codebase, actually triaged, and covering the gaps they are meant to cover. Most teams discover that some of their tooling is running effectively unattended.

Will the recommendations slow our deploys? +

No, if implemented thoughtfully. Most controls (image signing, SBOM generation, OIDC federation) add seconds, not minutes. Security gates that block deploys go on async paths with fast-fail SLAs.

Do you recommend build tools we do not already use? +

We prefer to work with what you have. A tool recommendation only makes the deliverables when there is a coverage gap that cannot be closed with existing tooling.

What does SLSA level 3 realistically require? +

Hosted build platform, non-falsifiable provenance, isolated build environment. For GitHub Actions or GitLab SaaS with signed provenance, it is achievable in weeks — not the multi-quarter project it sometimes sounds like.

Can this be combined with a general code review? +

Yes. We bundle secure code review (CloudCheck 360° §3 overlap) into the engagement on request — usually a two-week extension.

Benchmarks: SLSA, OWASP Top 10 CI/CD Risks. See also Security Posture, VAPT, and Monitoring & Observability.

Start with a free Cloud Health Check.

A scoped-down CloudCheck 360° of your current environment. Delivered in five business days, no commitment.

Book a Health Check See engagement packages