PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 6 / c6.4
Efficient Vulnerability ManagementSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 🤝 SharedAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c6.4 Security built into the pipeline (DevSecOps)

Integrate secure development practices and automated security testing into the bespoke software lifecycle to prevent common vulnerabilities from the design stage.

Quick Wins
Foundational
Efficient
Optimized
Effort: High Impact: Medium Applies to CDE: Yes

Requirement 6

Develop and Maintain Secure Systems and Software

PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.

6.2 Bespoke and custom software is developed securely
  • 6.2.1 Bespoke/custom software developed securely Covered
  • 6.2.2 Developers trained in software security at least annually Your responsibility
  • 6.2.3 Bespoke/custom software reviewed before release Covered
  • 6.2.3.1 Manual code reviews follow defined requirements Your responsibility
  • 6.2.4 Software engineering techniques prevent common attacks Covered
6.3 Security vulnerabilities are identified and addressed
  • 6.3.1 Security vulnerabilities identified and risk-ranked Covered
  • 6.3.2 Inventory of bespoke/custom software and components maintained Covered
  • 6.3.3 All system components protected via patches (critical within 1 month) Covered

How to implement on AWS

Incorporate SAST, dependency analysis (SCA), and secret scanning into CodePipeline/CodeBuild. Scan ECR images with Inspector before deployment. Train developers in secure coding. Block deployments with critical vulnerabilities.

Practical implementation

How this control is implemented in each reference architecture:

Shift security left: gate the pipeline with SAST, dependency (SCA), and secret scanning, and scan images before deploy so critical vulnerabilities never ship.

  1. Add SAST and secret scanning (e.g. CodeGuru Security) plus dependency (SCA) analysis as CodeBuild stages in the CodePipeline that deploys the app.
    Build/CI CodePipeline CodeBuild CodeGuru
  2. Scan the container image with Amazon Inspector (ECR scan-on-push) before the deploy stage.
    Build/registry Amazon Inspector Amazon ECR
  3. Fail the build on critical/high findings so vulnerable code cannot be promoted, and keep secure-coding training records for developers.
    Build/CI gate CodeBuild

How to validate: The pipeline definition shows the SAST/SCA/secret and image-scan stages, and a build with a planted critical finding is blocked.

Avoid: Scanning after deployment. Findings then live in production; gate the pipeline so critical issues block promotion.

Single-account, 3-tier →

Run one hardened CI/CD platform that deploys into CDE accounts with the same security gates and least-privilege cross-account roles.

  1. Operate a shared, hardened CI/CD platform in a dedicated tooling account with the standard security gates built in.
    Shared services (CI/CD) account CodePipeline CodeBuild CodeGuru
  2. Deploy into CDE accounts via scoped cross-account deploy roles (least privilege), never long-lived credentials.
    CI/CD account → CDE accounts IAM CloudFormation
  3. Enforce the same image scanning (Inspector) and block-on-critical gate for every workload.
    Build/registry Amazon Inspector Amazon ECR

How to validate: Every CDE deployment flows through the shared pipeline with the gates enforced, and the deploy roles are scoped to least privilege.

Avoid: One pipeline per team with inconsistent gates. Standardize on a shared platform so every workload gets the same enforced checks.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineinterview

Testing procedures

  • Examine documented software development procedures to verify bespoke/custom software is developed securely per all elements of the requirement (6.2.1).
  • Examine training records and interview personnel to verify developers received secure-development training relevant to their role and languages (6.2.2.b).
  • Examine evidence of code changes to verify bespoke/custom code is reviewed prior to release per the requirement (6.2.3.b).

Evidence in AWS

  • Pipeline definition with SAST/SCA/secret-scanning stages.
  • CodeBuild/Inspector scan results that block non-compliant deployments.
  • Secure-coding training records for the development team.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 6.2 — Bespoke and custom software is developed in accordance with PCI DSS and secure development processes throughout the software lifecycle.
  • 6.3 — New system and software vulnerabilities that may impact the security of account data are monitored, cataloged, and risk-assessed, and applicable patches are installed within an appropriate time frame.

AWS services

AWS CodePipeline AWS CodeBuild Amazon Inspector Amazon CodeGuru

Learning resources

References

  • AWS Security Maturity Model: Security in the pipeline