Cloud Security Maturity Model 2.0
Browse Cloud Security...
APP-03.1: Some applications are deployed using CI/CD pipelines
APP-03.1: Applications are built, tested and deployed using CI/CD pipelines. This improves the consistency and reliability of deployments and is needed to implement automated security testing. This control objective may be assessed using automation if the cloud provider's infrastructure-as-code tooling is used, or if a standard tag is applied by third-party IaC tooling. However, that may result in false positives if those tools push manually built updates that don't run through a standard pipeline. We strongly recommend manually validating these results.
  • Control automation: Either
  • AWS control specification: Identify workloads created using CloudFormation by looking for the default tags on the following resource types:
  • EC2 instances
  • Lambda functions
  • RDS databases
  • S3 buckets
  • ECS/EKS container tasks/services

The standard tags are: aws:cloudformation:logical-id aws:cloudformation:stack-id aws:cloudformation:stack-name

Or look for a provided custom tag value (e.g., resource default tagged by Terraform).

NOTE: A lack of these does not indicate a failure, and an organization is at a Level 3 if even only a small number of accounts contain application components managed using CI/CD.

  • Azure control specification: none
  • GCP control specification: none
  • Third-party (CSPM/CNAPP) control specification: none
Not Applicable - Not applicable
Level 1: Initial - Initial. Manually managing policies/procedures, mostly through console. Architectures tend to resemble traditional infrastructure (e.g., low use of serverless and high reliance on network security controls). IAM mostly ad hoc with little-to-no federation.
Level 2: Repeatable - Repeatable. Policy-/checklist-based and relies more on manual or simple tooling. High variability between projects; not coordinated across deployments. Initial use of infrastructure as code (Terraform/CloudFormation), but security not consistently engaged in design/review. Federation on some accounts, but limited use of MFA due to difficulties supporting teams (especially on the command line).
Level 3: Defined - Defined. Policies and central coordination in place. Some initial security automation still executed manually. Some third-party tooling (orchestration with other tools), Federation on most accounts with widespread MFA, but still gaps on consistency. Security starting to review and promote use of CloudFormation/Terraform. CSPM/CNAPP (CSP or third party) in use.
Level 4: Capable - Capable. Strong centralized security management with consistent enforcement. Automation and guardrails across multiple deployments. Expanding library. Big shift from manual management and execution to running security operations with centralized platforms with centralized management and reporting. Consistent use of federation and MFA, with some gaps supporting toolchains.
Level 5: Efficient - Efficient. All major activities centrally managed, covering all of the CSMM domains. Integrated into infrastructure-as-code (IaC) environment. Built into the stack with provisioning automation. Federation and MFA working consistently across toolchains (e.g., command-line support).

Description
  • Control automation: Either
  • AWS control specification: Identify workloads created using CloudFormation by looking for the default tags on the following resource types:
  • EC2 instances
  • Lambda functions
  • RDS databases
  • S3 buckets
  • ECS/EKS container tasks/services

The standard tags are: aws:cloudformation:logical-id aws:cloudformation:stack-id aws:cloudformation:stack-name

Or look for a provided custom tag value (e.g., resource default tagged by Terraform).

NOTE: A lack of these does not indicate a failure, and an organization is at a Level 3 if even only a small number of accounts contain application components managed using CI/CD.

  • Azure control specification: none
  • GCP control specification: none
  • Third-party (CSPM/CNAPP) control specification: none