Cloud Security Maturity Model 2.0
Browse Cloud Security...
WKL-05.2: Serverless/FaaS functions are continuously monitored, tracked and assessed for misconfigurations and code-level security issues
WKL-05.2: Functions are continuously assessed for misconfigurations such as being directly exposed to the internet, storing sensitive secrets in environment variables and keeping older vulnerable versions that can be potentially deployed. They should also be scanned for code-level security vulnerabilities in the pipeline, which overlaps with the Application Security category. To achieve Level 5 maturity requires automation using CSPM, CNAPP or other tooling; either third-party or from your cloud provider (if supported). Code scanning may be automatically assessed when using a cloud provider's assessment service or when included as a feature in the assessment tooling.
  • Control automation: Automated
  • AWS control specification: * Lambda functions are not publicly accessible
  • Lambda functions do not store secrets in environment variables
  • OPTIONAL: Code scanning with Inspector for Lambda functions is enabled
  • Lambda function versions older than six months are not detected
  • Azure control specification: none
  • GCP control specification: none
  • Third-party (CSPM/CNAPP) control specification: The CSPM includes the checks identified in each provider's section
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: Automated
  • AWS control specification: * Lambda functions are not publicly accessible
  • Lambda functions do not store secrets in environment variables
  • OPTIONAL: Code scanning with Inspector for Lambda functions is enabled
  • Lambda function versions older than six months are not detected
  • Azure control specification: none
  • GCP control specification: none
  • Third-party (CSPM/CNAPP) control specification: The CSPM includes the checks identified in each provider's section