DevSecOps Pipeline – Build and Test Stage
This domain covers the CI engine itself and the automated test gates attached to it. Questions focus on pipeline hardening, the scan types and what each can and cannot see, artifact integrity, and how to set gates that teams respect.
Core rules
- Harden the build system: ephemeral runners destroyed after each job, least-privilege CI tokens, no long-lived cloud keys (prefer OIDC federation), pinned third-party actions/images by digest, and network egress restricted.
- Scan types and coverage: SAST reads source without executing it (early, but prone to false positives); SCA inspects dependencies against advisory databases including transitive ones; DAST probes a running instance for exploitable behaviour; IAST combines runtime instrumentation with test traffic; container scanning checks OS packages and image layers; IaC scanning checks infrastructure templates.
- SBOM generated at build in SPDX or CycloneDX format, so consumers can map future CVEs to their inventory.
- Artifact integrity: build once, sign (Sigstore/cosign), store in a registry, and promote that same immutable digest through environments. Rebuilding per environment destroys provenance.
- Gate design: fail on critical findings with an available fix; create a tracked ticket with an expiry-dated exception when no fix exists. Thresholds must be published, not negotiated per release.
Worked example
A build reports a critical CVE in a transitive library plus 40 medium findings. Naive responses: fail everything (pipeline halts, team disables scanning) or ignore everything (risk accepted silently). Correct reasoning: the critical has a fixed version one minor release up, is reachable from an internet-facing request path, and the service handles card data - fail the build, bump the dependency, rerun. The 40 mediums are triaged by reachability and severity; those on the external path get 30-day SLAs, the rest get backlog items. The gate is defensible because it is risk-based and documented.
Traps that cost marks
- Running DAST against production without written authorization and a scoped window.
- Scanning only at release time, which makes findings expensive and late.
- Rebuilding the artifact per environment, breaking the chain from tested binary to deployed binary.
- Ignoring transitive dependencies or scanning only the application layer of an image.
- Measuring programme success by finding count rather than mean time to remediate.
- Sharing a single CI service account with admin rights across all repositories.