Pipeline scanning and GenAI guardrails
Lesson 6 of 6 in Securing Compute Workloads.
The cheapest vulnerability to fix is the one that never merges. A pipeline is a control point in exactly the same sense as a security group: traffic — here, code — passes through it, and you get to say no.
Amazon CodeGuru Security is the service the exam guide names for this. It performs static analysis on your code and reports security findings with remediation guidance: injection flaws, weak cryptography, resource leaks, log injection, insecure deserialization, and hardcoded credentials. It runs from CI — a pipeline stage, a GitHub or GitLab action, a Jenkins step — and the finding carries enough context to fix it rather than merely to file it. Amazon Q Developer is the other named tool and it works a step earlier, in the IDE and on the pull request: it reviews code for security issues and will propose the fix, which is the cheapest moment of all.
Around those two, a pipeline that takes security seriously runs four gates, and each one has to be able to fail the build:
Secrets. Scan the diff and the history for credentials, and keep a policy that no secret is ever a literal — runtime values come from Secrets Manager or Parameter Store. A finding here is not a style issue; it is a credential that must now be rotated. Dependencies. Known-vulnerable libraries are the most common path into an application. Scan the manifest, pin versions, and keep Inspector scanning the built artifact afterwards — ECR images and Lambda packages — because the CVE that matters is often published after you shipped. Inspector's SBOM export is useful evidence here. Infrastructure as code. Templates are code: lint them and evaluate them against policy before deployment, so a public bucket or an open security group is a failed build rather than an incident. The artifact. Sign it, store it immutably, and let nothing deploy that the pipeline did not produce.
A gate that only warns is not a gate. The control is the exit code.
Four gates, each able to stop the build
- IDE / pull request
Amazon Q Developer reviews the change in place and proposes fixes — the earliest and cheapest gate.
- CodeGuru Security static analysis
Injection, weak crypto, insecure deserialization, log injection, hardcoded credentials — with remediation guidance attached to each finding.
- Secret scan of diff and history
A hit means two actions: remove the literal, and rotate the credential — it is already in the repository’s history.
- Dependency and licence scan
Known-vulnerable libraries, pinned versions, and an SBOM retained as evidence for later questions.
- IaC policy evaluation
CloudFormation Guard rules and cfn-lint: a template that opens a security group to the world fails here, not in production.
- Build fails — nothing deploys
The finding goes back to the author with the line number. This is the whole point: the pipeline is a preventive control, not a reporting one.
- Artifact built, signed, pushed to ECR
Immutable tags plus digests, so the thing you scanned is the thing you run.
- Inspector scans the artifact — and keeps scanning
Enhanced ECR scanning and Lambda scanning re-evaluate stored artifacts as new CVEs appear, long after the build is green.
- Deploy
With a deployment gate that refuses images carrying critical, fixable findings.
Now the genuinely new part of C03. The exam guide asks for protections and guardrails for generative-AI applications, explicitly invoking the OWASP Top 10 for Large Language Model Applications — a versioned list (the current edition dates from 2025) that reframes application security for systems whose behaviour is produced rather than programmed.
The mental shift is this: in a classic application, data and instructions live in different places. In an LLM application they arrive in the same channel. A retrieved document, a tool result, an email the agent opens — all of it is text the model may read as instruction. So the five risk classes a security engineer must be able to name and answer are: prompt injection, direct and indirect; sensitive information disclosure, where the model reveals data that was in its context, its training set, or its system prompt; improper output handling, where a completion is passed to a shell, a SQL statement, an HTML page or an eval as if a model were a trusted source; excessive agency, where an over-permissioned tool turns a bad completion into a real action; and supply-chain and poisoning risk in models, adapters, plugins and the documents your knowledge base ingests.
The AWS answers are all controls you already know, pointed at a new target — and the depth version lives in the AIP line's Guarding Inputs and Outputs module, which is worth reading if a generative-AI workload is yours to secure.
Guardrails for a generative-AI workload — build upward, and keep every layer
- Least privilege and blast radius — the layer that decides how bad it can get
Every tool an agent can call runs under its own role, scoped to the one action it needs. An agent that can read a knowledge base and create a support ticket cannot also delete records, no matter what the model is persuaded to emit. This is the answer to excessive agency: assume the model will sometimes be wrong or manipulated, then make sure that being wrong is survivable. High-impact actions get a confirmation step or a human approval, and authorization decisions about who the end user is stay in your code — not in the prompt.
- Private paths and key control — where the data goes, and who can read it
Reach models over interface VPC endpoints so prompts and completions never traverse the internet, keep the knowledge-base source bucket private with KMS encryption, and restrict who may write to it — write access to the corpus is write access to the model’s beliefs, which is the practical face of data poisoning. Model artifacts and adapters get the same treatment as any other build artifact: versioned, access-controlled, provenance known.
- Policy at the boundary — both directions, every turn
Bedrock Guardrails screen the input for prompt attacks, denied topics, profanity and PII, and screen the output for the same plus grounding — the control that answers prompt injection and sensitive information disclosure as policy rather than as prompt text. The indirect-injection move is the one teams miss: run the guardrail over retrieved documents and tool results before they enter the context window, because content you fetched is no more trustworthy than content a user typed.
- Treat every completion as untrusted input — improper output handling, solved the old-fashioned way
A model’s output is a string from the internet. Validate it against a schema, and never hand it to a shell, an
eval, a template renderer, a concatenated SQL statement or raw HTML. Parameterize queries, escape output, allow-list tool names and arguments, and bound what a tool call may contain. If this sounds like 2005 application security, that is because it is — the lesson simply has a new source of hostile strings. - Observe, bound, and rehearse — because the model changes under you
Turn on model invocation logging to CloudWatch Logs or S3 and keep CloudTrail for the control-plane calls, with data-protection policies masking sensitive values in the logs themselves. Bound consumption — throughput quotas, token limits, rate-based rules at the API edge, budget alarms — because unbounded consumption is a denial-of-wallet attack as much as an availability one. Then rehearse: keep an adversarial prompt corpus and replay it on every model, prompt, guardrail or tool change.
| Risk class | What goes wrong | Controls |
|---|---|---|
Prompt injection (direct and indirect) | instructions arrive in the data channel — a user turn, a retrieved PDF, a web page, a tool result — and the model follows them | Guardrails prompt-attack filter on inputs; ApplyGuardrail over retrieved content before it enters context; input tagging so trusted scaffolding is not re-screened; least-privilege tools so a successful injection cannot act |
Sensitive information disclosure | the model repeats PII from its context, secrets from the system prompt, or data the user was not entitled to | PII filters and masking on the output side; no secrets in prompts; authorization enforced in code before retrieval, not by asking the model nicely; CloudWatch Logs data-protection policies on the transcripts |
Improper output handling | a completion is executed, rendered or concatenated into a query as if it were trusted | schema validation, parameterized queries, output escaping, tool-argument allow-lists — ordinary input validation applied to the model’s output |
Excessive agency | an over-permissioned tool turns a bad completion into a real, irreversible action | one scoped execution role per tool, no destructive permissions, confirmation or human approval on high-impact actions, and an audit trail of every tool invocation |
Supply chain and poisoning | an untrusted model, adapter or plugin; or poisoned documents entering the knowledge base | vetted model sources with known provenance; artifacts versioned in KMS-encrypted S3; write access to the corpus restricted to a pipeline role; validation of ingested documents |
Unbounded consumption | prompt floods or runaway agent loops exhaust quota and budget | throughput quotas and provisioned throughput, token and loop limits, WAF rate-based rules on the public endpoint, budget alarms |
Key terms: Amazon CodeGuru Security, OWASP Top 10 for LLM Applications, Amazon Bedrock Guardrails, VPC endpoint (PrivateLink)
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.