Exams / SCS-C03 / Study guide / Finding vulnerabilities in code and pipelines (Inspector code security, Amazon Q Developer)
Finding vulnerabilities in code and pipelines (Inspector code security, Amazon Q Developer): SCS-C03 study notes and practice questions
What to know about Finding vulnerabilities in code and pipelines (Inspector code security, Amazon Q Developer) for the SCS-C03 exam, from the Infrastructure Security domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a development team that ships quickly and needs security checks inside its pipeline, such as a vulnerable library, a hardcoded secret or an image with critical CVEs. You choose the control that finds the flaw at the right stage and keeps long-lived credentials out of the build.
Scan code, dependencies and images
Amazon Inspector code security scans connected source repositories for flaws in your own code (static analysis), vulnerable third-party dependencies and insecure infrastructure as code, and reports the findings in Inspector. Read the code security guide for how repositories are connected.
Inspector also scans the code and dependencies of Lambda functions for software vulnerabilities, and ECR images through enhanced scanning as they are pushed.
Amazon Q Developer security scans in the IDE can flag issues before a developer commits.
AWS Signer signs code and images. A Lambda code signing configuration can warn about or block unsigned code at deployment. See the Lambda code signing guide.
Secure the pipeline itself
Use OIDC federation from the CI system to an IAM role. Scope the role’s trust policy to the repository and branch, so no long-lived access key lives in the pipeline.
Reference secrets from Secrets Manager or Systems Manager Parameter Store in the build project. Plain-text environment variables show up in build logs and the console.
Put the scan in a gate. Fail the build on critical findings, and scan images again at push time.
How to choose
Scenario wording
Pick
Find code flaws in connected source repositories
Inspector code security
Find vulnerable dependencies in a Lambda function
Inspector Lambda code scanning
Scan container images as they are pushed to a registry
Inspector enhanced scanning for ECR
Developers want a flag before they commit
Amazon Q Developer security scan in the IDE
Block unsigned Lambda code at deployment
Lambda code signing configuration with Signer
The pipeline needs AWS access with no stored keys
OIDC federation to a scoped IAM role
Common traps
Amazon CodeGuru Security, which ended on November 20, 2025. Use Inspector code security or Amazon Q Developer instead.
Access keys stored in the pipeline for deployments. Use OIDC with a scoped role.
Scanning only after deployment, when the flaw is already live.
Plain-text secrets in environment variables that appear in build logs.
A SaaS startup keeps its application code, its Terraform infrastructure code and its dependency lock files in Git repositories. Two recent problems were found only after deployment. A vulnerable library came in through a lock file, and a Terraform change opened a database port to the internet.
The security team wants source code, dependencies and infrastructure code scanned before deployment, with the findings shown beside its other Amazon Inspector findings. Developers should not have to install and run a scanner themselves.
Which solution meets these requirements?
Choose one answer.
AA. Turn on Inspector EC2 scanning on the build servers, so that the packages installed on them are checked for vulnerabilities each day.
BB. Add an open-source scanner to every build script, and store its reports in an S3 bucket that the security team reviews each week for new problems.
CC. Run Amazon Inspector only on container images in Amazon ECR after each push, so that the code and its libraries are checked when the image is built.
DD. Connect the Git repositories to Amazon Inspector code security, so that code, dependencies and infrastructure as code are scanned and reported in Inspector.
Show the answer and explanation
Answer: D
A. Wrong: EC2 scanning checks operating system packages and software on running instances. It does not check the source code, lock files or Terraform in the repositories, so both problems would still reach production.
B. Wrong: A build script scanner can work, but developers must maintain it, and a weekly review is too late for these problems. Reports in S3 also sit outside the Inspector findings the team already uses.
C. Wrong: Image scanning finds vulnerable packages inside an image, but it does not check the Terraform or the source code itself. The open database port would not be found by this scan.
D. Right: Correct. Code security scans the repositories directly for code flaws, vulnerable dependencies and infrastructure as code problems. Findings appear in Inspector beside the other findings, and developers need no scanner of their own. Learn more: Amazon Inspector Code Security (opens in a new tab)
Explanation
Inspector code security scans the repositories themselves, covering code, dependencies and infrastructure as code, and it reports into Inspector. Scanning running instances, reviewing reports weekly and scanning only images each miss one of the stated problems.
Want more on Finding vulnerabilities in code and pipelines (Inspector code security, Amazon Q Developer)? The 5 full-length practice sets have 5 more Finding vulnerabilities in code and pipelines (Inspector code security, Amazon Q Developer) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Finding vulnerabilities in code and pipelines (Inspector code security, Amazon Q Developer)