After Lab 3.4 — Recap

You scanned Terraform infrastructure code with Checkov and found misconfigurations before deploying resources to Azure.

What You Should Understand

Infrastructure-as-Code Security Model

Shift-left for infrastructure: Catch misconfigurations (public storage, weak NSG rules, missing encryption) before provisioning resources in Azure.

Azure-Specific Risk Examples

From your Day 3 infrastructure scan:

Finding	Resource	Risk	Fix
allow_blob_public_access = true	Storage account	Publicly accessible data	Set to false, use managed identity access
https_traffic_only_enabled = false	Storage account	HTTP connections allowed	Set to true, enforce TLS
source_address_prefix = "*"	NSG rule	Unrestricted network access	Restrict to specific IP ranges or service tags
Missing azurerm_monitor_diagnostic_setting	Web app	No audit logs	Add diagnostic settings for Log Analytics

Every finding is a potential breach vector if deployed to production.

---

Reflection Questions

Why scan Terraform instead of using Azure Policy or Azure Security Center after deployment?

Timing:

• Checkov (pre-deployment): Catches issues in code before resources exist — prevents misconfigured resources from ever reaching Azure
• Azure Policy (post-deployment): Enforces compliance on existing resources — useful for drift detection and remediation

Best practice: Use both. Checkov prevents bad deployments, Azure Policy enforces ongoing compliance.

What's the difference between a Checkov finding and a Terraform validation error?

Terraform validation (terraform validate): Syntax and schema correctness

• Example: Invalid resource type, missing required attribute, type mismatch

Checkov policy check: Security and compliance rules

• Example: Valid Terraform but insecure (storage account without encryption is valid syntax, but fails CKV_AZURE_35)

Terraform validation passes, Checkov fails means your code is syntactically correct but insecure.

Should you suppress a Checkov finding for "customer-managed keys not required in dev environment"?

Depends on risk appetite:

Option 1: Suppress with justification

# checkov:skip=CKV_AZURE_43:Customer-managed keys not required for ephemeral dev environment
resource "azurerm_storage_account" "dev_storage" {
  ...
}

Option 2: Use conditional logic

resource "azurerm_storage_account" "storage" {
  customer_managed_key = var.environment == "production" ? {
    key_vault_key_id = var.cmk_key_id
  } : null
}

Recommendation: Use Option 2 for production-critical checks. Keeps prod secure, simplifies dev, avoids suppression sprawl.

---

Common Issues

Issue	Symptom	Cause	Fix
Checkov fails on valid Terraform	CKV_AZURE_X failed but resource is correctly configured	Checkov rule expects different attribute name or version	Check Checkov version, update rule or suppress with justification
Hundreds of findings for Day 1-2 infrastructure	Overwhelming output	Infrastructure wasn't designed with Checkov in mind	Triage by severity: fix Critical/High first, suppress Low/Informational with justification
Checkov reports findings in .terraform/ directory	Scans generated provider code	Default directory scan includes .terraform/	Add --skip-path .terraform/ or configure directory: in .checkov.yml
Suppression comment doesn't work	Finding still reported despite checkov:skip	Comment syntax wrong or indentation	Ensure # checkov:skip=CKV_ID:reason is directly above resource block, no extra spaces

---

Bridge to Lab 3.5

Your infrastructure configuration is secure. Now we test the running application for API security vulnerabilities with OWASP ZAP.