5.4.6. Securing the ML and AI Supply Chain and Access to Foundation Models
💡 First Principle: An ML system is only as secure as the code and images that built it and the credentials that call it. A vulnerable library in a training or inference image ships into production with the model. A long-lived key pasted into a notebook gives anyone who finds it the ability to spend your FM budget. Supply-chain scanning and credential choice are the two controls that close those doors.
Scanning code and images in CI/CD (4.3.1).
| Control | What it checks | Where it runs |
|---|---|---|
| Amazon Inspector, Amazon ECR scanning (enhanced scanning) | OS and programming-language package vulnerabilities in container images | On push, and continuously when a new relevant CVE is published |
| Amazon Inspector CI/CD integration | Vulnerabilities in a container image before it is pushed | A build step: the Inspector SBOM Generator creates a CycloneDX SBOM and the Inspector Scan API assesses it. Plugins exist for Jenkins, TeamCity and GitHub Actions, with further integrations for CodePipeline and GitLab, or a custom integration |
| Amazon Inspector Code Security | First-party code (SAST), dependencies (SCA) and infrastructure as code (IaC) | Connected GitHub and GitLab repositories, on pull requests, commits or a schedule |
| Amazon Inspector for Lambda | Software vulnerabilities in Lambda functions and their dependencies | Continuous, after deployment |
| Amazon CodeGuru Reviewer | Code quality and security recommendations on pull requests | Existing repository associations only — see below |
Amazon CodeGuru is named in the exam guide for this skill. Be aware that since 7 November 2025, CodeGuru Reviewer does not accept new repository associations, and CodeGuru Security was discontinued on 20 November 2025; AWS points to Amazon Inspector Code Security (and code review in Amazon Q Developer) for repositories that were not already associated. For a pipeline being built today, Inspector is the durable answer. A pipeline gate then fails the build when findings exceed a severity threshold, and Inspector findings flow to EventBridge for automated routing.
Scanning complements, and does not replace, the pipeline controls from 5.3.4: scoped IAM roles per stage, CodeBuild in a VPC, and signed or checksummed artifacts.
Choosing a credential type for FMs (4.3.8). Amazon Bedrock accepts two kinds of credentials: standard IAM credentials (SigV4-signed, ideally temporary credentials from an assumed role) and Amazon Bedrock API keys, which are bearer tokens sent in an Authorization: Bearer header or read from the AWS_BEARER_TOKEN_BEDROCK environment variable.
| Credential | Lifetime | Permissions | Use for |
|---|---|---|---|
| IAM role credentials (temporary, via STS) | Session-based, rotated automatically | Any AWS service the role allows | Production workloads on AWS compute; anything that also calls S3, Knowledge Bases, Agents or other services |
| Short-term Bedrock API key | Up to 12 hours, or the generating session's duration if shorter; valid only in the Region where it was generated | Inherits the permissions of the principal that generated it | Production tools or clients that need a bearer token rather than SigV4 |
| Long-term Bedrock API key | Until the configured expiry | Tied to an IAM user created for the key | Exploration and prototyping only |
Scope facts that decide exam questions:
- Bedrock API keys work only for Amazon Bedrock and Amazon Bedrock Runtime actions. They cannot call Agents for Amazon Bedrock (Agents Classic), Bedrock Data Automation or
InvokeModelWithBidirectionalStream, and they cannot call other services at all. - Governance is through IAM:
iam:CreateServiceSpecificCredentialcontrols who can create long-term keys (withiam:ServiceSpecificCredentialAgeDaysto cap the expiry), andbedrock:CallWithBearerTokencontrols who can use a key; thebedrock:bearerTokenTypecondition key distinguishesSHORT_TERMfromLONG_TERM. A deny onbedrock:CallWithBearerTokenblocks API key use for an identity, and the same statement in an SCP applies it organisation-wide. Calls through thebedrock-mantleendpoint are governed by the separatebedrock-mantle:CallWithBearerTokenaction (withbedrock-mantle:bearerTokenType), so a complete block denies both. - API calls are still logged in CloudTrail; the key itself is not logged. A compromised long-term key is deactivated, reset or deleted; a compromised short-term key is handled by invalidating the session that created it or denying
CallWithBearerToken.
⚠️ Exam Trap: A long-term Bedrock API key is the convenient answer and almost never the secure one. AWS recommends long-term keys for exploration only. For an application on EC2, Lambda, ECS or SageMaker AI, the answer is the IAM execution role; for a client that needs a bearer token, a short-term key.
⚠️ Exam Trap: "Use CodeGuru Reviewer to scan the new repository" is stale for a repository that was never associated. Amazon Inspector Code Security covers SAST, SCA and IaC for GitHub and GitLab repositories; Inspector ECR scanning covers the images.
