Build a CI/CD pipeline with SAST, SCA and image signing
This lesson builds the capstone's foundation: a CI/CD pipeline combining the hardening from Lesson 7, the SAST and SCA gates from Lesson 8, and the image signing from Lesson 9 into one working workflow. By the end, you will have a pipeline that builds a container image, blocks on serious source or dependency flaws, and signs the resulting image so nothing unverified can reach deployment, exactly the chain Module 2 built piece by piece.
Analogy🏏Cricket
🎵 Think of it like music: a band's first full rehearsal, where parts practiced alone — rhythm, melody, harmony — finally play together in time. The drummer's hardening lays the tempo, the SAST and SCA gates are the sections that refuse to continue if someone plays a wrong note, and image signing is the final chord that seals the take. Individually each part was already learned back in Module 2; the value now is that they lock into one continuous performance rather than separate warm-ups. This reveals why the lesson frames the pipeline as one working workflow rather than four independent controls.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Step 1 — Scaffold the hardened workflow shell. Start from a minimal pipeline with least-privilege permissions set explicitly, all third-party actions pinned to full commit SHAs, and an ephemeral runner per job, applying Lesson 7's hardening and Lesson 11's isolation guidance before any scanning logic is added, so the foundation itself is not the weakest link in the chain you are about to build on top of it.
Analogy🏏Cricket
📷 Think of it like photography: locking the tripod, setting exposure, and cleaning the lens before you ever press the shutter, because no amount of editing rescues a shot taken on an unstable, mis-configured rig. The hardened workflow shell is that setup — least-privilege permissions, SHA-pinned actions, ephemeral runners — established before a single scanning step exists. Photographers who skip the setup chase problems in every frame afterward; those who prepare it shoot cleanly. This reveals why the foundation is hardened first, so it is never the weakest link in the chain built on top of it.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Step 2 — Add the SAST and SCA gates. Insert a source-code scan and a dependency scan as required steps that fail the build on high-severity findings, following Lesson 8's pattern. Confirm both gates actually work by testing them against a deliberately flawed branch, then removing the flaw once you have confirmed the pipeline correctly blocks it, exactly as the earlier Module 2 exercise verified each control individually.
Analogy🏏Cricket
🎮 Think of it like gaming: a level with a locked gate that only opens once the game confirms you genuinely cleared the room, and you test that gate by deliberately triggering the fail state to prove it actually stops you. The SAST and SCA steps are those gates, set to block on high-severity findings; pushing a deliberately flawed branch is walking into the trap on purpose to confirm it springs. A gate you never tested is one you only hope works. This reveals why the exercise verifies each control against a known-bad input before trusting it on real code.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Step 3 — Sign the image and require verification. Once the image passes both scans, sign its digest with Cosign as the final build step, following Lesson 9. Configure your deployment step, or a policy check standing in for an admission controller, to verify that signature before proceeding, so an unsigned or tampered image is rejected regardless of how it might otherwise have reached the deployment stage.
Analogy🏏Cricket
💰 Think of it like finance: a wire transfer that clears only when the signature on the instruction matches the one held on file, so a forged or altered order is rejected before any money moves. Cosign signing the image digest is that authenticated signature, and the deployment's verification step is the bank clerk refusing to release funds without it. It does not matter how a tampered image reached the counter; without a valid signature it never proceeds. This reveals why verification is enforced at the deploy gate rather than trusting that only good images could possibly have arrived.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Step 4 — Confirm the full chain end to end. Run the complete pipeline against clean code and confirm it succeeds, builds, scans, signs, and verifies without manual intervention. This working pipeline is what Lesson 33 will attach centralised logging and detection to, so take a moment to note where application logs are emitted, since that output becomes the input for the next lesson's Sigma rule and SIEM alert.
Analogy🏏Cricket
🏏 Think of it like cricket: a full dress-rehearsal match where the whole side — openers, bowlers, and fielders — plays a complete innings end to end without the coach stepping onto the pitch. Running the pipeline on clean code is that uninterrupted innings: it builds, scans, signs, and verifies on its own, proving the drilled skills hold together under live conditions rather than only in the nets. And just as an analyst notes where every run was scored, you mark where the application emits its logs. This reveals why that output matters — it becomes the raw material the next lesson's detection feeds on.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
This lesson assembles Module 2's hardening, SAST, SCA, and signing controls into one pipeline.
Step 1: scaffold a least-privilege, ephemeral-runner workflow shell first.
Step 2: add and test SAST and SCA gates against a deliberately flawed branch.
Step 3: sign the verified image and require signature verification before deploy.
Step 4: confirm the full chain works end to end on clean code before moving on.