Module 8: Capstone The Andes Cargo Pipeline
6. The security this guide didn't build
Description
Lesson 5 traced the boundary of what this guide showed but couldn't execute because of a specific technical act limitation. This lesson traces a different, deliberately broader boundary: what this guide, by design, never set out to build, because it belongs to a complete domain with its own dedicated guide in this ecosystem. It isn't a to-do list or an admission that time ran out — it's the same declared-boundary discipline you already saw, at specific points, with OIDC in Module 4 and conftest in Module 6, consolidated here in one place before closing the complete guide.
Connection to the module
This lesson executes nothing — it's, along with lesson 7, the honesty map that closes the complete guide. It revisits, in more depth and without repeating them word for word, the boundaries Module 4 (OIDC) and Module 6 (conftest, branch protection) already named, and adds three pieces this guide never mentioned in detail because they're completely outside its scope: SAST/DAST, the software supply chain (SBOM, image signing, vulnerability scanning), and policies as a system.
Analogy: the building's security booth, versus the complete security system
Module 6's guardrail is, precisely, a security booth with a single, very specific instruction: check whether someone tries to take a specific object out through a specific door. A real building's security system has, besides that booth, cameras in every hallway, access control at every door, an identity verification protocol for every person who enters, and a periodic audit of who had access to what. This lesson builds no new camera — it precisely names each piece of the complete system a real production building would need, and where each one gets installed.
The four pieces, in order of how far they are from what you already built
1. End-to-end OIDC, against a real AWS account
Module 4, lesson 5, already named it in full: the complete YAML, the IAM trust policy, the Identity Provider, explained step by step, without executing it for two cited technical reasons (act doesn't issue OIDC tokens; LocalStack doesn't validate them). This is the piece closest to what you already built — the secrets mechanism (secrets.AWS_ACCESS_KEY_ID) you really did migrate in Module 4, lesson 7, is the intermediate step toward this, not a permanent alternative.
2. SAST and DAST
SAST (Static Application Security Testing, static analysis) scans source code —or, in this guide's case, HCL— looking for insecure configuration patterns before applying: an unencrypted S3 bucket, an overly permissive IAM policy, a security group open to 0.0.0.0/0. Tools like tfsec or checkov (named, not installed in this guide) do exactly this on .tf files, as an additional ci.yml step that would run alongside terraform validate. DAST (Dynamic Application Security Testing) tests an already-deployed, running system, looking for vulnerabilities exploitable from outside — it makes far more sense for an application with an exposed API than for declarative infrastructure like Andes Cargo's, but it's named here for completeness, because it shows up alongside SAST in any serious pipeline security discussion.
Neither one ran in this guide. Module 6's guardrail is, in spirit, a tiny, hand-crafted cousin of a SAST scanner —it checks one specific pattern on a plan—, but it doesn't replace the broad, maintained coverage a dedicated tool provides.
3. Software supply chain: SBOM, image signing, vulnerability scanning
This piece doesn't directly apply to Andes Cargo as this guide left it —there's no container image or binary artifact the pipeline builds and deploys—, but it's one of the most-cited CI/CD security pieces in the real market, and it's worth naming precisely, since cloud-security-and-guardrails-guide does build it:
- SBOM (Software Bill of Materials, dependency inventory): an automatically generated document listing every library and its exact version inside an artifact —the software equivalent of a packaged product's ingredient list—.
- Image signing with
cosign/Sigstore: cryptographically guarantees a container image running in production is, bit for bit, the one the pipeline built — not one substituted along the way. - Vulnerability scanning with Trivy (or another equivalent tool): checks every layer of a container image against public databases of known vulnerabilities (CVEs), before that image reaches production.
4. Policies as a system: Sentinel/OPA, beyond conftest
Module 6, lesson 6, already named conftest as the real system that replaces the guardrail's hand-crafted grep — a Rego policy, evaluated against the plan's complete data structure, with no dependence on where each character falls within a line of text. This lesson adds the names of two enterprise-level systems that solve the same problem at greater scale: Sentinel (HashiCorp's own policy engine, natively integrated into Terraform Cloud/Enterprise) and OPA (Open Policy Agent, the open-source policy engine conftest is built on). The difference against conftest isn't the policy language —Rego, in both cases— but the scale: a real policy system manages dozens of rules, versioned, with its own test cycle, applied centrally across multiple repositories — not a single hand-crafted guardrail, written to protect one resource.
The complete boundary table
| Piece | This guide | cloud-security-and-guardrails-guide |
|---|---|---|
| Credentials | secrets.AWS_ACCESS_KEY_ID (Module 4) | Complete, end-to-end OIDC, against a real account |
| Configuration analysis | A hand-crafted grep (Module 6) | SAST (tfsec/checkov) integrated as a standard step |
| Running application | Doesn't apply (no exposed API) | DAST |
| Container artifacts | Doesn't apply (no images) | SBOM, signing with cosign, scanning with Trivy |
| Policies | A grep over a single resource | conftest/OPA/Sentinel as a system, with multiple versioned rules |
Each row in the right column is, literally, a complete, dedicated guide's content — not a loose lesson. This table isn't a criticism of what you built: it's proof this guide's boundary was a conscious design decision, documented in DISENO.md before the first lesson was written, not a limit discovered along the way.
Why this boundary isn't a gap
It's worth saying with the same clarity Module 4 already used about OIDC: every piece in this lesson requires, at minimum, one of these three things this guide deliberately doesn't have — a real AWS account (OIDC, SAST/DAST against live infrastructure), a real container registry (SBOM, cosign, Trivy), or a centralized policy management system, usually paid or with its own infrastructure (Sentinel, OPA at scale). Building any of the three would have broken the $0, locally reproducible commitment that held throughout every lesson in this guide since Module 1 — the same commitment that made it possible for you to run every workflow, without exception, on your own machine, spending not a cent and depending on no external account.
Common mistakes
Concluding that Andes Cargo, as this guide left it, "isn't secure" (conceptual, the most common mistake from reading this lesson too fast). What happens: someone, after seeing the complete table of missing pieces, describes the pipeline built in this guide as insecure or incomplete in a real interview. How to fix it: the pipeline built here is genuinely more secure than Module 1's starting point —no pipeline at all, with a manual apply from a personal laptop, with potentially long-lived credentials and no record of who approved what—. "It's missing end-to-end OIDC and SAST" isn't the same as "it has no security at all" — it's the difference between a system with a solid foundation and explicit controls, and one with a dedicated security team's full maturity level.
Trying to build one of these four pieces inside andes-cargo-infra/, "to complete the guide" (scope-based). What happens: someone, motivated by this lesson, installs tfsec or checkov as a new ci.yml step, outside this guide's flow. How to fix it: there's nothing technically wrong with experimenting with these tools on your own —in fact, it's a good way to get ahead of cloud-security-and-guardrails-guide—, but this guide, as designed, doesn't assume you did it, and no later lesson depends on it. If you want to genuinely go deeper, with the same execution rigor you already know, the right path is that sister guide, not an improvised extension of this one.
Confusing SAST with Module 6's guardrail, treating them as the same thing (conceptual). What happens: someone, in a technical conversation, describes this guide's guardrail as "a homemade SAST" with no nuance about the difference. How to fix it: the guardrail checks a single pattern, on a single resource, inside the calculated plan — SAST checks the complete source code (or the complete HCL) against a broad, maintained base of insecure configuration rules, typically dozens or hundreds of checks, updated by a team dedicated to tracking new vulnerabilities. It's a scale difference just as large as the one Module 6 already named between the grep and conftest — it's worth being able to explain it precisely.
Exercises
Exercise 1 — Classify the four pieces by closeness to what's already built. Without looking at this lesson, order the four pieces (OIDC, SAST/DAST, supply chain, policies as a system) from closest to farthest from what you already built, and justify the order.
See solution
A reasonable order, closest to farthest: (1) OIDC — you already have the intermediate step (secrets.*) genuinely working, and the complete YAML shown; only a real account is missing. (2) Policies as a system — you already have a hand-crafted guardrail working, with the exact same logic conftest would formalize; the mechanism needs scaling, not inventing. (3) SAST/DAST — the guardrail is, in spirit, a tiny cousin of SAST, but SAST covers a much broader domain this guide never touched. (4) Supply chain — doesn't apply at all to Andes Cargo as this guide left it, because there's no container artifact to sign or scan; it's the most distant of the four.
Exercise 2 — Explain why the supply chain "doesn't apply" to this specific project. A colleague asks why this lesson gives less space to SBOM/cosign/Trivy than the other three pieces. Answer them precisely.
See solution
Andes Cargo, as this guide left it, builds and deploys no container image at all — its only compute artifact is a Lambda function packaged as a .zip (process-shipment-manifest), not a Docker image. SBOM, signing with cosign, and scanning with Trivy are pieces designed specifically to secure the container image build chain — they make far more sense for a project using kubernetes-and-eks-in-production-guide or aws-serverless-and-containers-guide, where containers to build and deploy actually exist. They're named here for the CI/CD security landscape's completeness, not because Andes Cargo needs them today.
Exercise 3 — Design the first concrete step if you had to add SAST to ci.yml tomorrow. Without installing anything, describe in two or three sentences exactly where, inside the ci.yml you built, you'd add a tfsec or checkov step, and why that specific order.
See solution
A reasonable answer: the step would go after Terraform validate and before Terraform plan —the same "cheap before expensive" logic that already organized ci.yml's order since Module 3—, because an insecure-configuration scan needs no calculated plan or LocalStack connection at all, just valid HCL. Placing it there means a configuration security problem —like an unencrypted bucket— gets detected and blocks the job before spending time calculating a complete plan, exactly the same efficiency principle you already applied to fmt/validate running before any network check.
Summary and next step
In this lesson you consolidated this guide's complete security boundary: end-to-end OIDC against a real account, SAST/DAST, the software supply chain (SBOM, cosign, Trivy), and policies as a system (Sentinel/OPA beyond conftest) — four pieces, each belonging entirely to cloud-security-and-guardrails-guide, none built here by a conscious design decision, not for lack of time. You saw the complete table of what this guide has versus what a production pipeline with mature security would have, and why that distance doesn't invalidate what you did build.
Before moving on you should be able to: name this lesson's four pieces unaided, ordered by closeness to what you already built; explain why the supply chain doesn't directly apply to Andes Cargo today; and precisely describe where you'd add a SAST step if you had to do it tomorrow.
Lesson 7 closes the boundary map with a different view: not the missing security, but the rest of the operational lifecycle Andes Cargo still needs —compute at scale, incident observability, and cost control.
Resources
- OWASP — SAST vs. DAST — general overview of static and dynamic security analysis, a neutral reference not tied to any commercial tool.
- Sigstore — cosign — official documentation for container image signing, the most-cited supply chain piece in today's market.
- Open Policy Agent — Documentation — the open-source policy engine
conftestis built on, already named in Module 6. cloud-security-and-guardrails-guide(NIEVA) — the guide that builds, end-to-end, each of the four pieces named in this lesson.