WAF++ WAF++
Back to WAF++ Homepage

Scope (Security)

The WAF-SEC controls are specifically aimed at IaC-managed cloud infrastructure. This section defines precisely what is in scope – and what has been deliberately excluded.

In Scope

IaC-Managed Infrastructure

All resources managed via Terraform, OpenTofu, Pulumi or comparable IaC tools are fully within scope of all WAF-SEC controls.

This includes:

  • Compute: EC2, ECS, EKS, Lambda, Azure VMs, GCP Compute

  • Storage: S3, EBS, RDS, DynamoDB, Azure Blob, GCS

  • Network: VPC, security groups, NACLs, load balancers, Route 53, CloudFront

  • IAM: IAM roles, policies, instance profiles, OIDC configurations

  • Secrets: AWS Secrets Manager, Parameter Store, Azure Key Vault, GCP Secret Manager

  • Monitoring: CloudTrail, CloudWatch, GuardDuty, Security Hub, Azure Monitor

Cloud Workloads (Production and Non-Production)

All environments are in scope – not just production:

  • Production environments: full controls scope

  • Staging/pre-production: full controls scope (as they are often connected to production data or services)

  • Development: reduced scope (critical controls like WAF-SEC-010, WAF-SEC-060 always apply)

  • Feature branch environments: minimum requirements (WAF-SEC-010, WAF-SEC-060)

CI/CD Pipelines

CI/CD pipelines are one of the most critical attack surfaces in modern cloud environments. In scope:

  • GitHub Actions, GitLab CI, Jenkins, CircleCI, AWS CodePipeline

  • Use of secrets in pipelines (WAF-SEC-060)

  • OIDC-based AWS access instead of static keys (WAF-SEC-010)

  • Container image scanning before push (WAF-SEC-070)

  • Policy-as-Code as pipeline gate (WAF-SEC-090)

Container Workloads

Containers bring specific security requirements. In scope:

  • Container images in ECR, Azure Container Registry, GCR, Docker Hub

  • Kubernetes clusters (EKS, AKS, GKE)

  • ECS tasks and Fargate workloads

  • Container scanning, SBOM generation, image signing

Third-Party Integrations (IaC-Managed)

Third-party resources managed via IaC providers:

  • Monitoring integrations (Datadog provider in Terraform)

  • DNS providers (Route53, Cloudflare)

  • External secret stores (HashiCorp Vault via Vault provider)

Not in Scope

Application Security (OWASP Top 10)

WAF++ addresses infrastructure security, not application security. The following is deliberately excluded:

  • SQL injection, XSS, CSRF and other application vulnerabilities

  • Input validation logic in applications

  • Authentication implementation in application code

  • API design security

For application security, WAF++ recommends the OWASP Application Security Verification Standard (ASVS) and corresponding SAST/DAST tools.

Physical Security

Physical security is entirely within the shared responsibility area of the cloud provider:

  • Data center access control

  • Hardware security

  • Physical destruction of data carriers

Endpoint Security

Client-side security is not in scope:

  • Laptop/desktop security, EDR, MDM

  • Browser security

  • VPN client configurations of end users

BYOD policies and endpoint security standards are the responsibility of the Information Security Management System (ISMS), not cloud infrastructure controls.

Manually Created Resources

Resources created manually in the cloud console cannot be automatically checked by WAF-SEC controls. WAF++ recommends:

  • SCPs (Service Control Policies) or Azure Policies that prevent manual deployments

  • Drift detection tools that detect manual changes

  • A policy that no production resources may be created manually

Non-Cloud Infrastructure

  • On-premises servers not managed via IaC

  • Legacy systems without cloud API

  • Network hardware (switches, physical firewalls)

Provider Coverage

Provider Coverage Level Note

AWS

Primary (complete)

All 10 WAF-SEC controls with AWS-specific checks

Azure

Partial

Core controls (IAM, encryption, network) with Azure-equivalent checks

GCP

Limited

Selected controls; expansion planned

HashiCorp Vault

Integrated

WAF-SEC-060 (Secrets) with Vault-specific checks

Kubernetes

Partial

Via Helm/Terraform; security contexts, RBAC, network policies

Brownfield vs. Greenfield

Greenfield (New Platform)

For new cloud platforms we recommend implementing all WAF-SEC controls from the start. The order:

  1. WAF-SEC-010 + WAF-SEC-020 (IAM baseline and least privilege)

  2. WAF-SEC-060 (Secrets management – never start with hardcoded credentials)

  3. WAF-SEC-050 (Secure network design from the beginning)

  4. WAF-SEC-030 + WAF-SEC-040 (Encryption from day 1)

  5. WAF-SEC-080 + WAF-SEC-090 + WAF-SEC-100 (Monitoring and response)

  6. WAF-SEC-070 (Integrate vulnerability management in CI/CD)

Brownfield (Existing Platform)

For existing platforms a risk-based prioritization is necessary. Recommended approach:

  1. Assessment: Run WAF++ checker against existing IaC → findings list

  2. Prioritization: Critical findings first (WAF-SEC-010, WAF-SEC-020, WAF-SEC-060)

  3. Incremental migration: Address 1-2 controls per sprint

  4. IaC capture: Migrate manually created resources to IaC (Terraform import)

For brownfield platforms: never remove all permissions at once. Introduce least privilege (WAF-SEC-020) incrementally to avoid production disruption.

Applicability Table by Workload Type

Control Web App Batch/ETL Data Platform Microservices Serverless

WAF-SEC-010 IAM Baseline

Yes

Yes

Yes

Yes

Yes

WAF-SEC-020 Least Privilege

Yes

Yes

Yes

Yes

Yes

WAF-SEC-030 Encryption at Rest

Yes

Yes

Yes (critical)

Yes

Conditional

WAF-SEC-040 TLS Enforcement

Yes (critical)

Conditional

Yes

Yes (critical)

Yes

WAF-SEC-050 Network Segmentation

Yes

Yes

Yes

Yes (critical)

Conditional

WAF-SEC-060 Secrets Management

Yes (critical)

Yes (critical)

Yes (critical)

Yes (critical)

Yes (critical)

WAF-SEC-070 Vulnerability Mgmt

Yes

Yes

Yes

Yes

Yes

WAF-SEC-080 Security Monitoring

Yes

Yes

Yes

Yes

Yes

WAF-SEC-090 Policy-as-Code

Yes

Yes

Yes

Yes

Yes

WAF-SEC-100 Incident Response

Yes

Conditional

Yes

Yes

Conditional

Legend: Yes = fully applicable | Conditional = partially applicable, adapted implementation | (critical) = particularly high priority for this workload type